Behind the scenes: user-testing the 1st MVP
When I started my job for Savvie, I jumped immediately into the transition phase which is from defining the business model to making a tangible product.
Savvie has the value proposition of reducing food waste of bakeries by using machine learning. Jess & the team had already been doing research on the business, tech & user side of it. So, the “why” of this problem:
How to simplify the bakery forecast of a store manager?
Has been defined and found out, so the best thing to do as a designer was to challenge the concept through user testing and find out which users are the most interesting to target and which kind of features are useful to them. So this article covers how I’ve been working through user testing.
Settings
brief & challenge: make an MVP useful, desirable for store managers of bakeries. Take the lead of the Saas product, define & prioritize tasks, define work for a UX Design intern.
Time constraints: 2 weeks
Ressource: no budget for deep user testing, limited time availability of the owners of bakeries (end users) or inexistent.
Context: A design agency made some wireframes for Savvie before I joined the team. As Savvie spent money on this first draft, my best advice is to reuse the work done for bringing it to user testing.
Design teammate: Ingrid Sørvik
But why undergo User testing and follow the RITE method?
For 4 reasons; we can spare resources (time and money) by utilising the initial concept or work done previously.
- Second, we can make sure that the existing ideas during the previous months are reaching out and correspond to the needs of the end-user as well as the market.
- Third, we can iterate as quickly as possible on the prototype and validate features before a piece of code is dropped.
- Last but not least, based on this user testing we can understand which features are the most necessary and useful to the end-users, so we can prioritize tasks to be done on a Design, machine learning, and back-front end side.
Building the bridge between the concept and the market
From the start, the priority has been to determine the kind of bakeries we want to include depending on their size and purpose, the user-testing has been helpful for understanding how they currently work as well as how responsibilities are shared. Later on, I suggest that basing this collected information on persona will help to relate easily to when designing & iterating on the features.
Criteria for success
As we do not have analytics data, we will assess these goals through a survey sent during the launch of the MVP. Here are the 3 mains goals we defined;
- The store managers define the product as intuitive and easy to use.
- The store managers trust the bakery forecast number based on machine learning.
- Additional: The store managers save time in their daily process by centralizing the main task in one place (registering waste log, registering broken or not delivered food)
Objectives of the first user testing
2 minutes intro + 10 minutes current daily task + 15 minutes user testing due to time constraint of the end-users
- Understand their daily process.
- Identified a new hierarchy & relevant features & understanding of the interface.
- Evaluate how far they trust the machine algorithm numbers.
- Current or new frustrations resulting from the prototype.
Result
The main result of the user testing session shows that the weather forecast as well as the amount of each item are relevant features. So they first had a look at the list in the app. Why? Because that is where they have an overview of the available products they have in the store as well as being able to see the forecast for the next few days.
At the end of the session, I asked them to prioritize the content on printed wireframes. This information helped to compare with previous responses and decrease the number of biases through the insight.
The milestone
As mentioned above, user testing is not that easy as some users don’t have time for a user testing session, so my best alternative is to understand their way of working. So I observed them and asked them what the importance of their tasks are. As a result I found this tool: a wonderful paper list where managers of Bakeries write down what they ordered for their store, and what was wasted at the end of the day. It is also a tool for planning the future forecast and registering their waste. This element has been really interesting for building the mean features and keeping the same hierarchy of information as the sheet is today.
This is also helpful on the development side because these lists of items are going to be displayed into the app in exactly the same order as shown in the above data. Because the end-user knows their list and will expect to have the same content; this similarity allows for and is done for efficiency.
A/B testing of interactions
It has been really helpful to build different kinds of interactions in figma and see how the user understands, uses, and compares them. The “plus” & “minus” buttons for adjusting Vs the “keyboard control” Vs “flipper”. The quick and easy thing to do has been to add these 3 different interactions into the same “main prototype” so the user can compare it easily and feel themselves already using the product in real time. The outcome had been useful and of course insightful. It all depends on whether the bakery Manager knows what number they will input before using the app. For example in the “waste log” it will make sense to use the keyboard, because it is just about entering a number they knew before. Nonetheless compared to the forecast already made, the end user would adjust the machine learning forecast, meaning increasing from 2–3 numbers. So in this case the “plus and minus” interaction makes sense.
Also they want to keep the overview of the list while doing adjustments, so they can scroll faster between needed items and have the quick interaction at the same time.This “flipper’’ system was not good enough in answering this need for two reasons; taking all the screens as mentioned above, and, the user has to scroll up and down on the number and already has a need to scroll on the list at the same time; meaning that it would lead to confusion and will overlap misleading gestures from the user (by clicking and swiping up and down to fast they could scroll to far in this “flipper” and lose the correct initial information). The closer the interactions are from each other, they also have to be just as different, so it would be easier for a good experience in this context.
This RITE method has been done iteratively 3 times a week; morning user testing, afternoon updating prototype and features. Meaning that the prototype has drastically changed from its first iteration 🔥
Fun fact of the user testing; I got the chance to be offered a drink on most of my user test (orange juice as I do not like coffee😛) 🥤
Never take it for granted
The Bias factor has been an element to evaluate and take into consideration, as the end-user doesn’t have time to give, they will sometimes be distracted from tasks, so it will influence the quality of information collected. Likewise, some could be too positive without having a reason for doing so.
Following the process
In addition, a GUI has been built with components for an ease of update in the future. Also we have used the agile methodology to define and plan the task to achieve each week, based on the user value, difficulty from design and code perspective, I will write another article about it soon ✌🏻
Thanks for reading
In addition to solving the bakeries’ surplus, these “quick and dirty’’ user testing + wireframing process has been useful for making sure we were building the right things for the right end users by taking in account all their experiences. It also shows how far people could trust an algorithm that predicts their forecast. The rating of the data from the machine learning wireframe has been positive even without having an identity defined, with the numbers landing between 6–8 on a range of 10. Keep in mind that the users are the oil of a successful product. Thanks for reading this article.
Feel free to continue to read the next step of the process
