portfolio innovapost

⚠️ Due to working under security clearance level 2 during my employment:

Terminology, assets, images, and project details have been either generalized or blurred, and medium to high-fidelity prototypes being redacted⚠️

Application or webpage in need of update or upgrade to a mobile.

I have been very lucky to have a wide variety of projects in my 5+ years at Innovapost and it's sister company Canada Post.

My users ranged from:

  • Depot workers with customized sorting machines worth billions under union restrictions.

  • Innovating a mobile hub for supervisor's duties such as address creation, managing schedules & routes, and maintenance of mailboxes.

  • Keeping delivery agents on time, on route, and given quick, useful information on hardware that can overcome outdoor hazards.

  • Giving post office clerks an intuitive and hardy database that enables them to help with address-related services, general store or mail inquires, and process sales all in one dashboard.

  • And many more!

I've also had the pleasure of being introduced to projects in various states of production so I could stay on my toes and help optimize no matter what stage. This case will represent a typical yet general structure of my involvement and duties during my time as a UX Specialist, UI Designer, and Product Designer.

project case

team

  • 1 UI/UX designer

  • 1 QA tester

  • 3 Developers

  • 1 Project manager

  • 1 Scrum master

timeline

  • Overall: 4-12 weeks

  • Requirements gathering: 1+ weeks

  • Design & testing: 2-8 weeks

  • Revisions: 1+ weeks

PROBLEMS

  • Software or hardware are at end of life or were no longer being supported.

  • New user issues could not be solved in current app.

  • Multiple apps needed to be consolidated.

  • Major updates to branding or design needed to be reflected.

solutions

  • Versioning gave opportunity for long awaited features to relieve major user pain points.

  • Leveraging current cloud solutions to bring app into current OS and design model.

  • Find ways to streamline production time without subverting union contracts.

REQUIREMENTS GATHERING

Depending on a project scope, timeline, cost, and resources; requirements gathering could range from 1-2 weeks.

If time permitted, I would set out to collect project or development documentation, training materials, conducting interviews with product owner/stakeholders, hold team discussions, and contact research department for any related content.

Timing or availability can be scarce so gathering screenshots of the application, finding current processes, assets, or documents containing user/client expectations and pain points are my first priorities. Making sure the appropriate information and features transfer to the new project effectively.

1

Screenshots of application that needed to be upgraded. Along with notes with questions for client, meeting comments not addressed in documentation, or first glance thoughts for improvement

Solution Brief

A great way to:

  • clarify roles

  • identify any potential gaps

  • create clear scope & goals

  • facilitate team discussions & early solutioning

  • makes a great reference for current or potentially new team members

Once everything is laid out in a solution brief, it establishes a baseline for information known and sets up next steps for any additional gathering, interviewing, or testing that needs to done.

2

This template allows for participants in meetings to view and add notes during interviews. Once collected, it can be converted and edited into a useful document to be shared to the team for visibility and focus.

Wireframes & Prototypes

Using Axure or Figma, I translate my first sketches into low-fidelity wireframes. Then, improve them by adding higher fidelity features.

At this point, I share the mock-up with the product owner to gauge if the wireframes warrant stakeholder input. If the mock-up seems to solve all requests, usually high fidelity interactivity is added or converted to a prototype for usability benchmarking.

Once given approval, the final design and branding elements are applied and additional assets created. Then it is handed off to development along with any front end code or notes.

3

Above is a low fidelity wireframe made during a meeting when discussing hierarchy in order to confirm layout and grouping in real time.

Testing

During the requirements gathering phase is usually when the discussion of pre, peri, and post testing opportunities and availability is presented.

In some cases the Canada Post research team would have existing personas, surveys, or feedback documents for reference. This meant that more often testing would be invested in the production or revision stage by a QA tester. The testing I made sure to incorporate organically or informally at minimum were interviews (pre), card sorting (pre), usability testing during design phase.

4

I personally like to use the selected research: 🟣 purple during gathering phase, 🟡 yellow during mock-up phase, and 🟠 orange during production/revisions.

Revisions

There can be many reasons why post-production revisions can be required:

  • updates to software

  • adding more features outside of original scope

  • improve minor user interaction bugs not foreseen

  • changes in requirements (such as accessibility standards)

  • application user base grows in complexity beyond sustainability forecasts

Everyone does their best with what they can, and no one can completely predict the future. Despite all efforts to keep apps functional for as long as possible or 'future-proof', revisions are part of the design process as maintenance. Technology and people change and if early gathering and testing goes well, the post-app maintenance should stay small, easy, and inexpensive.

In times where I could not be made available, I make sure to leave any outstanding notes, features, and current design specs with both business analysts and developers to assure smooth sailing even without me.

5

Keeping my tickets in Miro helps me track of changes across all applications, as well as to use as reference and documentation.

FAQs

How do you decide the design of the applications from scratch?

I don't! I believe in a practical don't try and re-invent the wheel approach. Most of the time, my projects work with existing frameworks with branding being defined already.

In cases where I build new or custom components I usually follow the lead of current UX practices or I will research what apps my users are using in order to keep ease of use. If none of those apps they are using have something similar, I will look into highly rated trends that align with my users that have similar components as a start.

Which part of your process do you enjoy the most?

The feeling of being in sync with the Product Owner (or equivalent).

Having a close relationship with my product owner is very important to me in many regards. We both have a lot in common, usually having to manage business-side expectations, user goals, and communicating with developers. Though their duties may differ, mine brings their hopes to life visually. So I like to see it as either a superhero getting me as a sidekick or even becoming tight-knit like a dynamic duo!

Or solving a pain point. That too.

What part of your process do you believe is your weakest?

Documentation writing. Since I use a lot of concise notes outside of apps and 'call to actions' inside apps, it can be difficult to then create an essay from one. To combat this I tend to keep a few templates and blanket statement paragraphs in case something is needed for a presentation such as a PowerPoint.

Speaking of presentations, I also fall into the 52% of Canadians with a fear of public speaking.