Canada Post’s Snap Ship
Canada Post has a few online tools for small to medium sized businesses to generate parcel shipment orders, but they’re complex to use and intended for customers with large shipping volumes.
The Solutions for Small Business (SfSB) group at Canada Post needed a “light” tool for small business customers who ship less than 50 parcels per month. CP Digital formed an Agile scrum team to build this tool and I was the UI/UX designer on the team.
99.98 % of Snap Ship users work on desktop (with their goal being to print a shipping label for their parcel) — however, we designed and built the tool to be mobile responsive so that if needed, users can set up the shipment and pay for it on a mobile device and then access the label later to print it.
Design a tool that helps small business users to set up a shipping order, pay for it, and print their shipping label quickly and easily.
Researched and wrote a case study on best practices in forms design, including a heuristic audit of Canada Post’s digital forms.
Collaborated with the UX designer to build high fidelity Axure prototypes for usability testing.
Observed and took notes for two rounds of usability testing with 7 users for Round 1 and eight users for Round 2.
Refined typographic patterns and designed new UI patterns for inputs, the progress tracker, buttons and icons.
Created the visual design layouts for all steps of the flow for both desktop and mobile responsive experiences, graphic assets and HTML specs for developers.
Owned UI/UX QA and collaborated with developers to ensure that the product was built as designed.
The user flow is a multi-step process. We decided to chunk the experience into three or four steps, depending on whether users are sending their parcel within Canada or internationally. If the country they’re shipping to is outside of Canada, the tool adds in a Customs step to the journey.
We used a progress tracker to help users know where they are in the process, but deliberately designed it not to be a navigational element because of the logic that builds as users provide info and make choices. Instead, we provide an order summary and users can go back to edit their choices and information if necessary.
Users enter information for where the parcel will be sent. Their business profile information is set as the default for sender information, however they can change this info if necessary.
User testing revealed that users had particular expectations about the order of some of the input fields, thus we made adjustments in the prototype to meet user expectations.
I explored different graphic treatments for the types of packages and we chose to go with flat colour illustrations and a checkmark and outline around the package types for their selected state.
When the user hovers or selects a package type, information for size guidelines and limitations appears dynamically.
The size and weight fields calculate and advise users when they’re over weight limits.
I explored several layouts and patterns for the cards: the limitation was that there could possibly be nine different services on the page, thus arranging the cards vertically emerged as most appropriate.
When users select a card, or if they click Select additional options, the card opens with options listed: when users select options, the price at the top updates dynamically.
From this step forward, a summary of the order appears in the right column.
This component appear when users select their shipping method: a modal opens where they can choose to book a pickup, select a date and a time range, or add this shipment to existing pickups that they’ve already booked.
If users select a destination country other than Canada in Step 1, the flow changes to include the Customs step.
User testing revealed that most people don’t know what many of the Customs terms mean or understand what information they’re supposed to provide. Thus, we tried to simplify things and provide as much contextual help as possible.
The grouping of input fields on this page is very deliberate: required info is at the top left; on the top right, we ask for different numbers if users have them, with help text that explains what each number means.
The lower half of the form takes information about the items being shipped. We included a few helpful interactions:
The tool calculates the weight and number of items and cross references it with the weight the user entered it on Step 1. If users make an error, they can either adjust the weight here to match what they said in Step 1, or click on the Edit button for Shipment details and go back to correct it on that step.
For the Description, the tool automatically remembers and provides a dropdown list with the user’s last five items beneath the input field.
Harmonized System code search tool
Another special component is the built-in Harmonized System (HS) code search tool, which is connected to a database for thousands of goods with their descriptions and used to calculate import/export duties.
We modelled the interaction for the tool on a zoomable tree map structure for data visualization. Users type in the item they’re shipping, and then they just click on the related labels that appear to drill down through layers of commodity descriptions—eventually arriving at the code number they need.
When we tested the tool, several of our test users gave feedback that it’s the clearest, quickest tool they’ve ever used for HS Code search.
Users can enter new credit card information or select from stored credit cards linked to their account.
User testing revealed that users didn’t always notice the final amount they were to be billed in the right column, so it’s in bold at the top of the Order summary and above the Place my order button.
Once payment is complete users receive a confirmation message, with their tracking and order information and the next steps. Users finish the process by printing their shipping label.
A surprising challenge was how to manage an effective system for design QA. The majority of the scrum team was based in Ottawa, so we didn't have the luxury of being in the same room together as they were developing the tool, and thus communication about UX/UI defects was a little tricky.
I compiled an Excel sheet listing all the defects per screen in the flow, however I discovered that this format didn’t match well with the developers’ process of working through tasks on Jira. In fact, they were kind of blind to the defects list. By the time I’d completed my QA process, there were well over a hundred defects—and it wan’t time-efficient to then go in and log them as individual defects in Jira. Fortunately, our product owner helped a lot by grouping the defects by step, or states of steps in Jira in a way that the developers could absorb them. For my part, I bumped up communication by working with developers over the phone/Slack/webex as much as possible to correct the defects and work through solutions together for matching the UI design.
It was a jam that inspired me to consider how I would do things differently in future projects:
Specs in prototyping software like Invision and Marvel are really easy to use and a great tool for communicating visual design details with developers
In the future I would discuss the ideal QA process with developers earlier in the process to understand how they work and their expectations for communication about making changes.
Trello is a great app to keep track of defects: it’s a little lighter in process than Jira, and worth setting up to collaborate and check off these kinds of tasks.