Changing an industry at REKKI

‍

The problem

Probably you don't know that most independent restaurants struggle to order their supplies in an efficient way. Each night after service, they take a dirty napkin where they've written down what they need, and call their supplier to leave a voicemail with their order. The next morning, suppliers listen to all these voicemails, and, as you can imagine, there's a lot of room for something going wrong. REKKI, is a mobile app that works similarly to WhatsApp. You create chat with your suppliers and can communicate and order from them in the app, where you can have your personalised product list.
‍

‍
My role in the team

I joined REKKI as the only designer in 2016. These are the key things I worked on:
‍
- Streamlined the mobile app design so it follows UX guidelines on each platform Android and iOS. And optimised the core action: ordering.

- Interviewed chefs and suppliers to gather industry insights and shared them with the team to help informing and prioritising new features.

- Designed, tested and launched an onboarding experience that allowed replacing the sales-led onboarding and reduce Cost of Acquisition per user.

- Designed and tested many features that were supporting the core action.

- Worked together with a brand designer to implement a design system for our react app.

‍

Streamline the design

When I joined there weren't any design guidelines established, and both apps android and iOS looked very different. I decided to follow best UX practices to reduce complexity and allow users to order quicker.

When I joined, we wanted to launch the first live version of the app as soon as possible, since many chefs were already using the beta version in London. So I took a very functional and aseptic approach for a quick redesign of the app, creating very simple components and cleaning up the core action, ordering.

I interviewed a lot of chefs to understand what were the most common problems they experience when they order. For context, they make their orders around midnight after a really tiring service, when their brains are completely burnt. Very frequently they would:
‍
- Order the wrong quantity of an item, either because they order the wrong number or the wrong size, (eg. each instead of kg) 

- Order after the supplier cutoff, which will result in a missed or late delivery.
‍
- Forget which suppliers they had ordered from "When you have to order from 7 different suppliers at 11pm, sometimes you just can't remember which order you did and you didn't" 

With these things in mind, and Mixpanel data, I designed and tested several iterations of the main flow until we got to this: 

in-app onboarding flow

For a long time, our user acquisition was led by sales. There wasn't an onboarding flow in the app, instead, the sales and customer success team would get everything ready for chefs to start ordering straight away. They would digitise all their invoices, contact their suppliers, manually input all their items etc...

‍
Then, during the first weeks they would message chefs to remind them to order, add more suppliers to their app, and invite more chefs from their restaurant.

They discovered that restaurants that had ordered 5 times from the same supplier, and had at least 2 chefs and 2 different suppliers in the app, would pretty much keep using REKKI forever, because at that point they have clearly seen the value of the product and was significantly better than their previous flow. They called these users Post-5.
‍

These practices led to a ~80% monthly retention for active users, but it wasn't scalable. How could we maintain such a high retention rate and have a scalable self-onboarding experience in the app? The first step I took was to lay out the current sales process and identify the key actions.
‍

Then, I designed a bunch of prototypes and went to test them to a few restaurants that were using REKKI, but soon we realised that we couldn't test this flow with existing users, because they loved the app so much that they were biased.
‍
At Findmypast, I had used Facebook before to recruit people for testing, so I joined London chef collective on Facebook and started recruiting chefs that had never heard about REKKI to test the prototypes with them. After two months, we had tested with 18 chefs, and iterated over the initial prototype 3 times.

‍

‍

The main learnings from these initial two flows were:

- The "wow moment" came when they realised they could have all their suppliers in the app.

- They were suspicious, and didn't trust that their suppliers would receive orders from REKKI, since most of them don't like to use tech.

- The whole "chat with your supplier to order" flow was a bit confusing.

- Everyone skipped through the intro screens that explain the product. We know people in general don't read much, but chefs just don't have time to go through things that don't give them immediate value.

With these learnings in mind I decided to:
‍
- Change the order of the flow so the list of suppliers would go first.
- Included a supplier card that shows the time that supplier has been receiving REKKI orders.
- Added an explanatory text to the chat view "This is your chat to order and communicate with your supplier"

And we got to a version that was ready to share with the team and start implementing.

This flow was good for restaurants in London that were working with suppliers that we knew of. But for chefs in different cities it would have been a pretty empty experience, since we did not have a single supplier in those cities. Those chefs, were losing "the wow moment".
‍
For these users, I replicated the sales flow in which users would give us a few invoices and we will set them up for them. This was also a good way of getting data from new suppliers and opening new cities.
‍

The customer success team, was doing the set ups remotely now, instead of going to the restaurants to try and find new users. Which significantly reduced the cost of acquisition per user.
‍

The design system

In the new year, I started working with David, the creative director who had join to develop the brand principles of REKKI. We started creating a design system to transition into our react app.  

‍
For this piece of work we followed these core principles: 
- Tap instead of type. Understand that users are tired and English is not their native language in a lot of cases, the most they can find tapping the better.
- Simplify and maintain the core flows. Data showed us that the ordering flow was working really well, so we decided to leave that flow as it was and just reskin it, while we "killed" some other flows and features that were barely used.
- One main action per screen. We know chefs don't have time to choose between actions, so we made sure they would only have one main action per screen that truly stands out.

‍

Key leanings

Well, this was quite a ride. But just to name a few:

- Talk to users as much as you can, and don't keep it to yourself. At REKKI I created a research channel on slack where I would post the interviews and key findings during user testing. This way, everyone knows who they are building for.

- Take small risks very often. Many times we knew we didn't have enough people to build really good solutions to complex problems, but we kept finding a middle ground option that helped us keep learning.

- Make sure you can track how your design performs. At one point, it was very clear we needed to provide a solution for chefs to collaborate on orders, but there were a lot of things to consider and we didn't have enough time or resources to do so. We wondered though, if, in the meantime, there was something simple we could do, like showing a message "Nicole has 4kg of tomatoes in her draft" in chefs' ordering lists. I tested it in person with some users and got really good responses, but since it was just a piece of copy, it became really difficult to measure how this feature was performing. So we ended up removing it during the redesign.

- Design systems give teams a common understanding of their visual language and the speed they need to innovate. In contrast with a static style guide, a design system is a continuous process that needs to be lead by both designers and developers, in order to be really successful.