Parcel Pickup
Parcel Pickup is a tool that allows both personal and business customers to schedule one-time (on-demand), multiple (on-demand) and recurring (continuous) pickups at a cost. Customers can modify, cancel or pause their recurring pickups. The parcel pickup service encourages companies to ship with Canada Post with the incentive of not having to transport parcels to the post office.
Problem Space/Product Rediscovery
The MVP was launched in February 2020 and I was brought onto the scrum team as a Product Designer to support a number of major change requests to the tool.
One of the primary concerns among the stakeholders was that the Recurring pickup flow was not very user friendly due to the current UI for scheduling dates and time. They also expressed concern about not meeting customer needs due to limitations of the tool such as, users not being able to enter custom pickup instructions and oversized parcel options.
Wireframing/Prototype
Recurring (Scheduled) Pickup
Multiple-On Demand Pickup
User Testing/Validation
One example of a finding we made was that after analyzing the participants’ observations is that the Multiple On-Demand pickup option was being overlooked and that participants were more likely to resort to using the default One-time On Demand option to schedule multiple pickups. Additional feedback probed by our researcher revealed that it was often due to the jargon terminology. A suggestion was later made to rename or further explain each pickup option.
Takeaways
This project was the first time that I was able to deeply collaborate with a research team. A key learning here was that I was able to observe how real user interviews and testing sessions are conducted. This exposure gave me insight as to what kind of questions should be asked and what factors are important to consider, in order to set up the right framework for gathering research.
Another key learning from this project is that testing and validating prototype designs should be an ongoing, iterative process. We ran into a hurdle during a series of sprints where we had finished the wireframes and immediately handed the specs off to the developers to code (due to time constraints) - the problem was that we did the user testing sessions after the specs were handed off and ultimately had to re-code part of it after the design was updated to reflect the feedback from the sessions. This definitely resulted in a loss of time and resources. What I would do differently going forward is to do user testing earlier on in the process with rough prototypes and to set realistic timeline expectations with stakeholders (i.e. more time in between testing and dev work) so that the end design is validated and better informed.