Design sprint – parcel pickup tool
Canada Post has several online tools on its website that allow users (primarily business users) to do different tasks related to shipping parcels. Our project for the sprint was to re-design and test a concept for a parcel pickup tool that would become the starting point for a new team to work from.
Why was the Pickup tool well suited for a design sprint?
It was smaller in scope than many of the company’s projects.
It had fewer technical complications or constraints than other tools, so changes could be easily implemented.
The user experience was known to have a key problem: users thought they had completed their pickup order and awaited their pickup—but when they contacted Canada Post wondering what happened, there was no record of their request. So we also had a mystery to solve!
Chris – Embedded parcel expert
Sarah – UX designer
Emily (me) – UX/UI designer/writer
Ed – Developer
Avi – Facilitator
Faisal – Decider
The sprint process
Formulate our goals, list questions, draw the map, interview experts and create How Might We (HMW) notes, organize and vote on HMW notes
Lightening demos (inspiration, information), sketching
Review sketches: art museum, heat map, critique, straw votes, decisions, storyboard the product
Build the prototype, write content, formulate test plan
Tuesday (after Easter weekend)
The team’s goals, re-written as questions
Can the user complete a pickup request easily?
Is the user as well informed as they need to be?
Can users easily pay for the pickup?
Do users receive appropriate feedback on completing the process?
Can we find ways to help users (ie., save info for repeat users, use default account info)?
Who are our users?
After interviewing parcel operations experts, we determined that our users were small business and commercial customers who ship a larger volume of parcels per month and may have scheduled pickups, who also need to book single on-demand pickups.
As we interviewed the experts and came up with our How Might We notes, one theme that emerged was how to design for different scenarios that pertain to the pickup address:
Whether or not a pickup is available for particular addresses (it depends on the postal code).
Cases when the user’s business address may be different from their pickup address (for example they have a warehouse).
We considered different patterns for using default address info and interactions for changing the address given different scenarios.
Another theme that emerged was how to communicate why we’re asking particular questions. For example, the number of parcels, their weight and if they’re on a shipping pallet will determine whether a driver with a 5 tonne truck or a mail carrier with a bag on her shoulder arrives for the pickup.
If the user is sending any of their parcels via Priority or Priority Worldwide service, the pickup is included for free — users will know this from their parcel order but we didn’t want highlight that it’s free in the pickup tool and risk users “gaming the system” by providing false information.
Communication about timing
We learned from conversations with experts that operationally, pickup timing for Canada Post is general rather than precise, and depends on when users book the pickup and when the truck can get there.
Items going by Priority Worldwide service have specific constraints for cutoff timing because they’re going to the airport.
Thus it was was important to communicate the cut-off times clearly with respect to the earliest or latest the pickup can be done, mindful that users simply need to know when to have their items ready.
Together, the team decided on the guiding principles:
Make it really simple
Ask the fewest number of questions
Devise an easy, correct order to ask the pickup questions (address, location details) so it quietly fills in the logic as they go
Reduce the flow to as few steps as possible
Everyone on the team sketched the four steps very clearly, although there were some differences in the order. During our sketch review and critique, we eventually concluded that given the way the logic should build, WHAT, WHERE, WHEN and PAY was the ideal order for the flow.
For shaping the questions, I was inspired by Airbnb’s Become a Host flow: it’s simple and the tone is casual and conversational—as if you’re getting info from a friend. While being consistent with other Canada Post projects I’ve worked on, I tried to keep the language simple, easy and friendly.
Since it was a similar multi-step flow to Snap Ship, I reused the general layout, form design and progress bar. As well, we had made progress in developing The Canada Post UI/UX design system: I used the new typographic scale, the top navigation shell and the new colour palette that better meets accessibility requirements.
Two members of our team live and work in Ottawa and they left after day three when most design decisions were complete.
We decided that it would be ideal to have the form functionality and logic that an Axure prototype offers, and Sarah and I divided and conquered the prototyping and test planning.
A little too ambitious
Yeah. It’s a real challenge to build a high fidelity prototype in a day. We were accustomed to testing with hi-fi prototypes including visual design, but it was too time-consuming here. In retrospect, a simple black and white prototype with the desired language for the questions and labels would have been more practical. Going hi-fi ate into our test planning, which we eventually discovered would have benefited from additional finessing.
Test plan questions
Would users understand what to do in the “worst case” scenario — when pickup is not available for the postal code they entered?
How would users respond to the way we communicated free pickup for Priority packages at checkout? Would they be confused? Would they cheat the system in the future?
Would users notice the pickup summary building dynamically as they went through the different steps of booking a pickup?
We recruited seven small business test users, but only three showed up, so we had limited test findings with which to move forward. Nevertheless, we learned a few things worth thinking about:
Our test users went through the pickup process very quickly (so on one hand, good news) — and two out of three people didn’t seem to register that they had paid (possibly bad news?).
Our test users didn’t understand what Priority or Priority Worldwide meant (they were not very familiar with Canada Post’s shipping methods).
Our test users didn’t really notice the summary building on the right hand side of the screen.
User testing part 2
A few months after our sprint, the Agile scrum team that took on the project tweaked the prototype and tested it with four users.
All users liked the clean look of the tool.
All users felt the progression of steps made sense.
Users who were more tech-savvy and more experienced with shipping were able to go through the tool quickly and smoothly.
All users stated that they’d prefer to have a continuous flow within their shipping order to include booking a pickup vs. using a separate pickup tool.
All users were confused about why the tool asks if they’re shipping Priority or Priority World wide: the easy way to solve for this is to provide contextual help beside the question that explains that these services have particular cut-off times for pickup.
What I learned from the sprint experience
For testing a concept—general ideas and functionality—visual design is less important, and language and writing are very important.
Our language in the prototype wasn’t perfect, but it was pretty good and our test users commented that their experience using this tool was very simple and easy.
In retrospect, I would leave more time to polish the test plan. We discovered we didn’t set up the context and flow into the pickup tool as well as we could have, as well as the tasks focused on managing address info for pickups that weren’t available: as a result, the feedback we got from our users was a bit unclear.
The sprint methodology itself is really great. I would use it again in a heartbeat for any project that is suitable. It’s fun, and all team members contribute to and own the design. A team of six people can do a lot of good work in 5 days. Moreover, several techniques (defining goals, drawing the map, writing HMW notes while interviewing experts, sketching) just make good sense as a process for UX design everyday.
Limited time limits the pursuit of perfection, and I learned that it's OK, and actually it’s better at this stage, to be a little messy.