BonAPI recipe widget

BonAPI works from an extensive data collection to tailor a variety of ingredient solutions, such as recipe profiling, generating dynamic recipes and integrating grocery deliveries. Their holistic approach to food-making takes many factors into account, e.g.: diets, allergens, health, economic cost, seasonality. They collaborate with supermarkets and wholesalers in the online space.

Project background:

I was approached by BonAPI to help solve a product problem ailing their recipe widget. As someone living with a digestive condition, I was already fully behind their mission and happily took up the opportunity.

Problem:

A very high dropout rate and a lack of consistency. The disrupted flow was causing frustration among users, leading to a decrease in conversion rates.

Users:

Majority (67%) female-identifying, aged 25+, based in Germany and Austria. An overwhelming amount of traffic (83%) is on mobile and organic.

Opportunity:

There were no big constraints for the scope of the project, and the look and feel of the widget could be altered to improve the user experience.

Desired outcome:

To increase conversion rates and improve usability.

How did I do it?

1. 🍅 Making sense of the problem: To understand the root cause of the high dropout rate and the design decisions behind the widget, I first did a UX audit, followed by testing sessions with a small group of users.
2. 🥦 Competitor analysis: I analysed similar products offered by a range of local competitors to understand the best practices and identify opportunities for improvement.
3. 🍒 Iterative design: Based on the findings from steps 1 and 2, I created several design prototypes that I then ran by BonAPI. Conducting usability tests was next to iterate on the design until a solution that satisfied users' needs was found.
4. 🥑 Development and hand-off: This was likely the biggest learning for me. From the start, I worked closely with the start-up, learning to communicate my design decisions and their expectations for the look and feel of the widget, as well as the intended end goal of the redesign. It was crucial to land at something feasible from a development perspective.

What was the problem, exactly?

From the data available we knew that users were dropping off between the consecutive steps in their journey navigating the widget. Some detriments to the overall experience also became apparent during the UX audit and some preliminary tests on the old design.

I broke it down further to try and understand the possible causes:

1. The widget's purpose is not clear enough, and users may not understand what it does. It is also possible that the widget is perceived as clutter on the parent (recipe) website. Secondly, it is not obvious at this stage that users are being suggested items available at a partner seller.
   
2. Suggestions made by the widget might not be accurate.
   
3. Scrolling on desktop is hindered by the bar disappearing behind the topmost window.  On mobile, the auto-fill feature takes up most of the screen, making it difficult and frustrating to proceed.
   
4. Information order changes between steps 1 and 3. In step 1, users are told how much they need, but in step 3, they are told how much they are buying. This makes the process less intuitive.
   

What were the competitors doing?

Competitor A offers a more streamlined experience with little to no personal information required, unchecking items that users might already have, and different options for partner stores. Competitor B offers integrated portioning but only allows for one grocery partner, and product naming can be confusing. Competitor C has a well-integrated portioning feature and offers the ability to swap and find alternatives, but product mapping and naming are sometimes problematic.

What were my ideas?

I proposed a number of options on how to solve the apparent problems. Naturally, I wanted to strike a balance between feasible from the developer’s POV and useful for the target audience. Some ideas, such as tighter integration of the widget on partner websites, were nice-to-haves if only we had full control over the backend.


The plan was as follows:
1. Simplify and shorten the user flow.
2. Introduce a feature to allow users to edit and replace items easily. Less recipe abandonment.
3. Add personalization features, such as a “favorites” option or a feature that remembers past orders. This could improve user engagement and increase conversion rates.
4. Create a more intuitive portioning feature with options to specify the number of servings, and to adjust ingredient amounts based on the number of servings required.
5. Provide more options for grocery partners, and highlight the value proposition of each partner store. Users would be making informed decisions.

When I started prototyping in Figma, I kicked off by staying closer to the original widget’s look and feel while already incorporating some much needed changes.

Below you can see the four versions I eventually created following feedback from users and BonAPI themselves.

A/B testing:

While I believe this testing method to be a little more efficient in marketing than in UXD, I did decide to employ it to validate some of my own (and the developers') assumptions. The question was simple: which option makes for a better “home” screen of the widget? Unsurprisingly, 19 out of 20 users picked the recipe overview screen where a visual takes up the central position (left).

Usability testing:

I conducted a remote unmoderated test on a workable prototype via Maze. The main task was reaching the shopping basket; there were also follow-up questions on the ease of use, and perceived surprising or unclear features.

The final flow of the widget was:
ingredient/recipe selection – check delivery availability – choose a delivery partner – check shopping basket.

During testing, the average misclick rate was found to be 11.7%, with an average screen time of 8.2 seconds. Simplifying the screens resulted in a decrease in misclick rate.

I also did not consider all misclicks a failure on our part, as for tools such as Maze it often means that testers clicked around, exploring. This usually becomes apparent when running moderated face-to-face tests.

Finished redesign and closing thoughts:

We identified a few other potential hiccups that could be resolved in the next rework of the recipe widget, e.g. the presence of modal screens being confusing on mobile (because there are no buttons to click). Going back to the full recipe overview should be made easier, as the last step is essentially viewing and confirming the shopping basket only.

Finally, an interesting piece of feedback was the possibility of adjusting ingredients quantity. The widget is not a grocery shopping tool for one's favourite store. The widget had been designed for ultimate convenience: the shopping list is created based on what a recipe calls for. Quantities are adjusted in line with product modifiers, such as biological or non-bio, or cheaper alternatives. Thus, if it identifies a smaller pack of mushrooms as the cheaper option, it is going to suggest that. If, however, multiple recipes call for the same ingredients, the amount would be adjusted accordingly. We are removing the need for creating a shopping list manually.