Fig 1: The initial designs for the scheduling system
Grocer Delivery App
A redesign of a grocery delivery scheduling system
Last year, I worked with a North Carolina grocery delivery company to create a shopper's app under an NDA. I was provided with app requirements and features and collaborated with a UI designer to deliver these features.
I decided after my contract to re-design some screens with more context about the user by understanding their journey and how the created features fit within it. This case study also allows me to showcase some of my work without breaking the NDA.
The company's initial measure of success was to conduct usability tests to ensure users could complete the tasks. And on launch, we would get more qualitative and quantitative feedback from real users.
Before tackling a redesign, I created a list of constraints that I'd have to keep in mind throughout the project.
Must be designed within four weeks
Must meet initial business' needs
No direct access to the target users
As part of a bigger project, I was tasked to create a scheduling system with a co-designer. The company required this system to be able to accommodate a shopper who might shuffle between two locations.
This prototype was based on the app requirements provided by the company:
Users must be able to add multiple locations and availability
Due to the time constraints, I initially tackled the whole space without creating a persona. I decided after my contract to re-design with more context about the user by understanding their journey and how this feature fits within it.
Jacob is a 20-year-old Business major at The University of North Carolina, Greensboro. He drives to and from his home in Thomasville to attend lectures at Greensboro. He also works as a gig shopper to pay his bills.
Utilize his time to earn some money
Pick batches at current location
Set his availability for both locations
From all the artifacts created, I established user stories to reflect the task Jacob would hope to accomplish in order to pick up batches at multiple location and earn money efficiently
Add, edit and delete multiple locations
Set, edit and delete availability for existing locations
With multiple locations and availabilities, it is possible for shoppers to get confused. So shoppers should be able to —
Quickly identify current location and schedule to avoid confusion between locations
See an overview of each schedule to prevent overlapping
Then I created a task that allows users to set their locations and availability and sketched out a task flow.
I wondered what a fleshed out understanding of the users could uncover so I went back to the drawing board.
With the help of my mentor, we thought of different ways and reasons people organize their time. From the word "schedule," we immediately thought put together & establish.
Booking a trip, flight or accommodation
Setting the alarm to keep them on track
Creating a reminder on a calendar
I also remembered that Google Home had done a good job of giving users the ability to add multiple home addresses and devices.
I pulled inspiration from all these platforms and flows and sketched some wireframes.
My first attempt at redesigning the experience was an eye-opening experience. It was still very similar to the old wireframes, with more considerations for accessibility.
Although, gig work allows shoppers to have flexible hours. An article by a&b shows that building a routine, planning and consistency helps people stay organized.
I removed the 2-week model for a weekly view to integrate the routine building into the app. I kept the calendar view to give users the ability to schedule hours for a particular day.
I brought a snapshot of their schedule to the front to help shoppers quickly identify their locations and schedules.
The designs received some positive feedback; however, I received questions that made me re-think certain features.
" I'm more interested in my weekly view."
" Is this supposed to be a calendar? "
" What would I use the calendar view for? "
The calendar view restated what the weekly view could do, so I dropped this feature to avoid distracting Jacob from the key task. I tested these wireframes again.
Here is a timeline of changes I made to the wireframes after each round of testing.
I used colour to help Jacob differentiate between different locations and schedules
Following accessibility guidelines, “Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)”. I included shape as another way to distinguish between locations & Schedules
Shoppers were to provide a nickname and colour before they added their address.
Testers felt confused by the initial flow
Reflection: being able to enter their address was the crucial task, so I switched this flow.
The flow didn’t feel right. After speaking with my mentor, I decided to reduce the user’s decision load by making the colour and shape assignment automatic.
This reduced the screens from 2 to 1
Testers hesitated before clicking on the headline to change the address
I brought the arrow menu close to indicate it was a clickable element.
I also included the shape element to the scheduled time
I removed the greeting information as it was not relevant and took up visual space.
I also made the Home element bigger to improve accessibility
Learn from others
There were certain times that I felt I was relying too much on my assumptions. I reached out to product designers who could give me some guidance based on their experience. When I finally started talking to people about my designs, I was able to get different perspectives. I learnt things that helped me progress and would be carrying it to my future projects.