What We Learned Designing FoodTech Products: Case Studies and Business Outcomes
Let’s review real cases involving Scale-Ups and MVPs, the problems they face with adoption and retention, and the specifics of B2B products in the FoodTech space.
A few months back, we had one of those team meetings over a virtual coffee that was supposed to be more about bonding than about work.
The conversation eventually turned into an exchange of nostalgic comments on what we had done so far under one hood. Someone occasionally said, “Seems like we’ve been into FoodTech lately.” We laughed, and then there was a moment of realization.
Indeed, we had been quite active in the FoodTech space by then. We really enjoyed working with our clients and handling the challenges that came along with their products. These were the kinds of problems that many product teams struggled with. Not just FoodTech ones. We had even discussed how useful it would be to share these experiences with others, but then we got caught up with other projects.
There would never be a perfect time, so we thought: Why not now? This reading is about real cases involving Scale-Ups and MVPs, the problems they face with adoption and retention, and the specifics of B2B products in the FoodTech space. Read the stories and check out our designs. We hope you’ll enjoy it!
Sides Web Platform
We first met Sides about two years ago through our mutual friends. They said they had been around since 2004 with their product, supporting restaurants in their core business processes. And then, we learned that while the technical side had been actively evolving, they hadn’t made many changes in the product design since its first versions.
Not only roots from the digital stone age did make this sound challenging — but the actual functional complexity did even more. Sides is more than a product — it’s a range of products combined to serve a specific audience.
Imagine the product complexity, considering they deal with all the following for the restaurant businesses:
- attracting and retaining customers (bonus system and website);
- receiving and processing orders (web shop, POS system, call center, self-order terminal, and delivery portals);
- managing preparation and delivery (driver app and kitchen manager);
- business administration (HR management, merchandise management, branch management, and statistics).
Although the range of features sounded impressive to us, we understood that it was not enough anymore for the product to have a complex function to be successful. The most competitive ones already had an excellent user experience. And that’s what Sides also realized right before turning to us.
Challenge
As we learned afterward, Sides wanted to address the onboarding part in the first place. New users had to spend around two working days to figure out how to work with the platform. Not only did the process take too long — but it was often unclear. We imagined there was room for unpleasantness on the users’ side during the onboarding stage. The product team agreed to that and said that it led to a couple of consequences for their business.
First of all, some of the customers would naturally bounce off during this stage due to the length of the onboarding stage and its unclarity. Secondly, the customer support team was always overwhelmed with the how-to type of questions from newcomers. Sides wanted to make a better experience for their users, a step directly connected to their business success.
Process
We shook hands and started researching the platform just as regular users would do. That’s a part of our usual process: we try to step into users’ shoes so the testing would be an honest experiment. However, we ended up confused. And surprised. We’d seen and built quite a few products, but still, there were parts we couldn’t figure out on our own.
Although the Sides team provided explanations, we felt overwhelmed with the functionality and confused about the overall impression of the product. So, we kept researching, turning to the product team rather often.
We also talked about the customer scenarios, core functionality, and limitations. We learned about the product team’s perspective on what had to be improved and the information that supported their vision. In particular, we received metrics data, which we used to analyze the platform’s usability further.
Next, we studied the approaches among competitors, added best practices of complex SaaS products from other domains, and combined all the information we had gotten so far. Altogether, it helped us to list the initial hypotheses of product solutions. Based on our hypotheses, we moved on to prototyping the new user flow for customer onboarding and conducted an initial series of workshops with the product team.
In the process, we discovered other pain points down the customer journey that weren’t reflected with enough clarity in the UI/UX design of the product. At the same time, there were those who had been using Sides for a while and gotten accustomed to the product the way it was. Therefore, the new design had not only to solve problems but do it in a sort of familiar way.
After the research phase and our initial prototyping, we ended up with a list of the challenges throughout the product — those we were going to address with the design. Based on the list, we prototyped, tested, and refined new elements, sections, and user flows, one by one addressing each point of the list. It was a hybrid form of collaboration, which consisted of a big piece of our autonomous work and a crucial part of our collaboration with Sides (doing workshops and various team sessions).
To summarize our work, we came up with the following highlights:
1. Simplified the onboarding part and ensured ease and clarity at every step.
2. Made the dish creation more intuitive and provided explanations at the points where customers could be confused.
3. Structured the dashboard part to make the team learning fast and the management process straightforward.
4. Improved the search and navigation through the platform so customers could easily find anything they needed.
We worked together for around two years, redesigning, adapting, and creating new stuff that would fit the whole ecosystem. As the changes have been implemented, the product team has been sharing with us that their metrics have been gradually improving.
Sides App, QR payments
In the previous part, we told you about our redesign project for Sides. Now, we want to focus on the piece of their current product range we did from scratch. By the time we heard about this idea, we had been working closely with Sides for around four months.
One day, their product team turned to us and told us they had found a new market opportunity: They wanted to add a possibility for the restaurants to create an app with QR payments. It implied that guests could study the menu, make an order, and pay with an app only. We loved the idea and were excited to do the entire design.
Challenge
On one hand, creating this one from scratch had to be easier than it was in the redesign scenarios. But on the other hand, we needed to maintain consistency across the design of Sides products.
Finally, the payment mechanics was a challenge on its own. We had to think through and prototype scenarios that may occur when there was more than one person who needed to pay for their meal, such as paying evenly, paying separately for your order, contributing only the desired amount, etc.
Process
First, we gathered requirements and expectations from Sides and researched the mobile experience of other FoodTech products targeting the relevant audience. We then explored payment practices from other domains to broaden our reference group of design approaches and ultimately create an even more convenient and competitive payment experience.
Before we turned to prototyping, we had identified the key points of the payment experience, which would guide our decisions, and approved them with the product team. They were split mechanics, bill sharing, real-time synchronization, and interaction between guests.
At first sight, paying via QR wouldn’t look complicated technically. However, when you start asking questions, you find room for complexity. What if there will be more than one person having lunch?
As a next step, we did initial prototyping, followed by a series of workshops with the product team. During sessions, we asked questions and worked together to answer them and model the user scenarios accordingly. Not only did we aim to address the common scenarios but also to help the product team solve rare issues and handle unobvious errors.
To summarize our work, we came up with the following highlights:
1. Used gamification features to make splitting bills a part of the fun get-together experience.
2. Made the payment process fast, transparent, and easy regardless of whether you eat on your own or with a bunch of friends.
3. Provided explanations for the cases where any confusion could likely appear and the possibility of leaving feedback for the restaurant.
The functional prototype we designed for the QR payment app was tested then and is currently under development.
B Lunch Web Platform
We got to work with B Lunch around three years ago. However, “B Lunch” came up later; first, it was the restaurant and its owner that we got to know. In the B Boutique restaurant, they had spent years receiving orders from office spaces and regularly delivering to them. And then, their owner realized that ordering meals via an app could work better for those who had their lunch in the office.
The plan was to design a product for managers and employees so they could pre-order lunches and get them delivered to their office spaces. After a period of testing, the client considered turning it into an open product everybody in their location could use. Unlike the previous project where our main goal was to redesign the existing product ecosystem, B Lunch was an MVP we created from scratch.
Challenge
Based on the knowledge of their regular customers who regularly ordered from the workplaces, the client wanted to make the usage as intuitive as possible. They understood that those customers were busy and the experience should be tailored to their context. Most likely, they would use the app to plan lunch orders during their break, so the client was eager to help them save time for doing something more enjoyable.
Process
We had a series of sessions with the B Lunch team to understand better the context and challenges of their customers. It turned out there were two types of users — managers and employees. Their behaviors slightly differed, and we need to keep this in mind.
Another important piece of the puzzle was in the unique client’s offering — the possibility to order lunch in advance. It was often a winning feature in competition with other products when customers were choosing the lunch service.
While learning from the client, we dug into the differences in the behavior between the two types of users and how the scheduling option could affect the result for each of them. After the initial learning phase, we did independent research on the client’s audience and competitors, combining new information with their knowledge base.
Next, we did prototyping and refined them with the B Lunch team during our workshops and other collaborative sessions.
To summarize our work, we came up with the following highlights:
1. Combined product experiences for both types of users — employees and managers — to make their collaboration and interactions with the service intuitive and fast.
2. Worked further with user roles, providing managers with the possibility to correct orders of their team members and adding a guest role to allow ordering for additional people.
3. Ensured consistency across the aesthetics of the restaurant and the online service.
4. Added the calendar logic to help users keep track of necessary actions and make it in time.
5. Created a clear and intuitive experience for restaurants to manage with mobile devices.
After the B Lunch project, the client invited us to work on the user experience for Zoloche Bistro, their subsidiary business.
“Other Land has pioneered a process that makes them to move faster than any other team I’ve had the pleasure to work with. They design, prototype and validate ideas in a matter of days, enabling us to make big decisions with ease.”
Illia Kosheliev, Product owner of B Boutique Bar
In Conclusion
We’ve come up with a few actionable notes for future work with the B2B FoodTech space. They are a sort of reminder of where to place our focus.
Let’s see if you have anything to add:
1. Understanding the complex B2B context:
Designing for the B2B type of products implies that you need to take into account several user groups down the line: your client, then the direct users of your client, and ultimately the end users of the product. The more effort you devote to the context at the beginning, the higher your chances of success.
2. Paying attention to domain specifics:
Once you understand who the product serves, explore what they do in the specific domain — how it benefits them and how they engage with it. Imagine you’ve created characters; now you must place them in their proper setting. And the FoodTech setting has its specifics.
3. Planning with the product stage in mind:
Scenarios of redesigning an established product and designing an MVP from scratch pose distinct challenges: how you deal with the technical side, how you conduct your market research, how you test your product hypotheses, and how you engage with customers.
That’s it for now.
We have big hopes you enjoyed reading this as much as we enjoyed putting it together!
I’d like to thank Tremis Skeete, Executive Editor of Product Coalition, for his valuable contributions to the editing of this article.
I also thank Product Coalition founder Jay Stansell, who has provided a collaborative product management education environment.
Feel free to reach out and say hi, or connect with me on my network at: https://www.linkedin.com/in/artem--ivanov/ 🤙
I’d also like to acknowledge Liliya Kizlaitis and Veronika Bogush UA for their collaborative efforts on this project and materials.
