Imagine this....
Because Lin’s parents are fairly old, she has to shop for them. Every weekend, she asks her parents to make a list of what they want, and she also orders grocery shopping for herself. She placed similar orders regularly for several different local grocery stores.
Today, Sal, the delivery worker for Lin's order and other people's order, was told by Ravi, the store worker, that something Lin wanted was missing. However, They did not managed to communicate to Lin, and Lin was upset because she didn't want to order again.
How do we bring the grocery shopping experience to people's daily life & ease the responsibilities of the service provider.
In the early stage of research, we brainstormed possible stakeholders and started with primary user research (more specifically, contextual inquiry) on three types of stakeholders: customers, service providers, and business owners. Learning how stakeholders perform their tasks in the real world setting can help us negate any pre-existing bias and spot anything we did not notice before, especially for the business owners’ perspectives and the service providers’ perspectives.
For this purpose, we interviewed college students, a local grocery store owner, and part-time delivery workers due to the time constraints. Based on their responses, we created 3 personas.
What will the stakeholders go through?
Based on our previous research, we created a journey map that illustrates how customers place online order and how service providers deliver orders.
After knowing what some of our problems could be, we brainstormed different ideas and created 20+ scenarios, which were used for internal discussions and later early stage testing, to figure out how we could potentially create solutions for different stakeholders.
After creating scenarios, we picked six scenarios that represented our ideas best for our storyboards, which were used for speed dating.
Using the storyboards, our team conducted speed dating for each to see how people who were unfamiliar with the problem would react. Immediately, it was apparent that some of our designs didn’t make sense to a brand new user. The forum feature and the pre selling products features for farmers was too unfamiliar, so we noted that this part of our storyboards wasn’t the most successful. The other storyboards received engaging feedback, and many related the grocery delivery to food delivery from restaurants.
For this round, we created a feature list. This list helped us to determine what information should be displayed for what kind of stakeholders, and by connecting the problems with solutions, we could better figure out and focus on the pain points we wanted to resolve.
We conducted our second round of speed dating on the feature list. The purpose of this speed dating was to get feedback from our users on their initial reactions to our features.
Because one important thing for this project was to consider what kinds of devices will which stakeholder needs under what condition, as we created the user flow, we looked into the specific devices needed as part of our responsive web design.
An ideal sitemap for customers and delivery workers is shown here, as we decided to focus more on these two stakeholders due to time constrains.
Allows customers to collaborative create shopping lists, which could be saved and used smoothly.
Create a smoother communication platform between the delivery worker and customers
A innovative scanning system that allows the delivery worker to scan while picking up items.
By providing a collaborative tool, users can have a smoother communication without back and forth. Also, this allows them to plan ahead for regular shopping and special events. It’s a place for bulk orders! Save your items without actually thinking about buying them (cart).
%20(Mockuuups%20Studio).svg){kind=tracking}
Matching people’s mental model to the concept of “shopping lists” and “shopping cart” was another challenge that we faced. It is hard to distinguish them during online shopping. To make the purpose of lists clearer, we conducted quick User Testing on how people described a shopping list and tested our design to see if it could match their mental model.
Another challenging parts in designing responsive web was that we need to think differently for different screen sizes even if they serve the same purpose.
Thus, we needed to construct information differently for different screens. For example, in the mobile version of the lists, the users can’t immediately see the price breakdown, but in the laptop version, they are presented with the information directly. However, the full price is still provided to reduce cognitive load.
During the shopping phase, the customer is still able to make changes to their order. Here, we show recommendations for other products that the customer might want based on their lists.
This alleviates that pain point of forgetting something at the last moment, and having to make a completely new order.
After all the items have been acquired by the shopper, the user can no longer make changes. Then, we have more information such as when the order will arrive.
In the case something is unavailable, our service provides the live swap feature. The customer is notified that some part of the order is unavailable. This allows the business owner to set some certain alternatives using related items. There is also an opportunity to decrease the price to account for the unavailability. This gives the satisfaction of the customer having more control over the shopping process. This ensures that they get all the items according to their needs.
We also learned about using standard text font and grids for our web design. When we started designing in gray scale, we did not notice this issue, but more questions came up in terms of usability, readability, and consistency. For example, we would wonder how large was it big enough for the users. After we checked the standard font sizes for laptops, tablets, and phones, we applied those standards to our design.
On the other hands, using grids helped us a lot in standardizing and creating visually appealing design.
%20(Mockuuups%20Studio).svg){kind=tracking}
%20(Mockuuups%20Studio).svg){kind=tracking}
Unlike traditional checkout process, the shoppers can scan each item while they are shopping. In this way, unavailable items are notified to customer on a button click in the checklist format of shopping list. After all items are scanned, the business owners can double check the order.
Overall, this reduces wait time for shopper in billing and makes the communication faster, which solves the earlier pain points of mis-communication between different stakeholders.
Something I learned...
Our business domain was very commonly known, and lots of great designs as well as patterns had been made specifically for online grocery shopping. To be able to find the unique value for our project, although we found way more pain points or problems at the beginning stage, we managed to narrow down the range and cut down the screens we wanted to make. For example, the checkout process involves a long process, but we mainly focused on three screens to present the core functionality. Cutting down ideas and selecting the key points we wanted to present were hard because you would never know if the other one would be better, but this also allowed us to focus on one specific idea and make it better. The quality of the solution is worth more than the quantity of the solution.
Another lesson I learned was to use consistent components across different frames. Before we worked on the specific content on each page, we first discussed what should be included in the navigation bar on different devices. For example, we thought that while for the navigation bar on the laptop, “My order” was not needed because users could find it under “My account” just by hovering over the button, it should not be the case for the navigation bar on mobile devices. Thus, we included an icon for orders for mobile devices. After confirming the navigation bars, we created components and copied the same component for each frame. In this way, it was more consistent and we would not run into the case where we forgot to change the navigation bar for one screen.
Other Projects
