How we design and engineer product features at Wolt: Pre-ordering food

Our product team is hiring! Check out open positions at wolt.com/jobs.

Today, Wolt is launching a new feature called the pre-order. For the customer, this means that you can explicitly tell when you want to have your meal delivered to you. Or pick it up yourself. Or get it to the table.

We launch features this big only a few times per year. While doing so, we’ve learned that some people are curious about what exactly does it require from our product team of 25 engineers and designers to develop things like this.

We launch features this big only a few times per year.

Today, we are taking the opportunity to share some of the journey we went through to launch pre-order. To guide us is our head of customer-facing product, Elias Pietilä.

(Elias is great for this since he was the first person in the Nordics to win an Apple Design Award, and he’s been involved in the development of more than 60 iOS applications before Wolt.)

Let’s have a chat.

Why would anyone need something called a pre-order?

“Simply put: With pre-order, the customer can tell when they want their meal”, Elias Pietilä says. “That’s super handy, since some people just need to have their food at a very exact moment. Be it corporations for a meeting or people for an event or a get-together.”

“Actually, in the first months of Wolt, we had people hacking the system. They would put in a comment saying that they’d like to pick their order up ‘tomorrow at noon’, instead of right now”, Pietilä explains.

“All that caused problems with our logistics system and our algorithms. We started thinking that we probably should make this pre-order thing into an actual feature. Allow the people to have the food at a given moment, and not only as picked up but as home-delivered as well.”

This kind of a feature needs thought and work to come to life.

“Although pre-order is only a single step in the order flow – you choose when you want to have your order – it’s actually very overarching”, Pietilä says, his speech a bit resembling the proud-yet-commercial tone of Apple’s often-parodied lead designer Jony Ive.  

“It’s been one of the biggest challenges we’ve had.”

“It’s been one of the biggest challenges we’ve had. And we’ve been developing it while simultaneously growing our product team to two dozen people. This is the first feature to really touch almost everyone in the team, and all the sides of our product. It’s a new feature in the consumer app, the restaurant app, our backend, analytics, restaurant sales reporting, logistics, courier app. Phew.”

In the following, Pietilä explains the six steps Wolt tackled to pull off something that Pietilä hopes can, in the future, be summed up as pre-order done right.

Step 1: Do interviews to understand what the customers and the restaurants need

“Pre-order was basically the first feature where we involved both our customers and our restaurant partners in developing it. Previously, we had basically just come up with an idea in our heads, and then develop that.

Here, we went to our users and asked what kind of features they want, and then tried to find the needs behind the answers. For example, we learnt that the restaurants not only want but also need pre-orders, since they are often bigger orders in item quantity.

“Pre-order has always been our most requested feature.”

For the customers, we’ve always been keen to do customer surveys. The feature requested by far the most, right after people wanting to have their food cheaper, has always been the ability to pre-order.

After deciding this is something we want to build, we asked how the users would like to have the feature implemented. For example, for the restaurant, the old version of getting a traditional email or a phone call about an order for the future is burdensome. That’s why they also said they’d prefer getting the order through the Wolt platform.”

Step 2: Figure out what this requires from the whole underlying system

“When we know we want to have a new feature, we start thinking what this will require from the background systems that we run and the whole triangle of hungry customers – restaurants making the food – courier partners delivering the food. 

For example, it’s good that our courier partners know that they are delivering a pre-order instead of a regular one. The customers’ expectation for service level is also higher here, since they have ordered their meal to be there at 6 pm sharp, give or take 10 minutes. 

With pre-order, we have to fulfil these two needs by making our underlying algorithm prioritise pre-orders – without messing the deliveries for people making regular ones.

“Thank God we have an algorithm to do this work.”

First of all, thank God we do have an actual algorithm that does this work. If we had a hack-y system of manual labour to handle these different kinds of orders, things would explode. But here, the beast of an algorithm that we have built is more than capable of handling the mix of pre-orders and regular orders. For example, for the time target that the user has chosen – we are actually able to aim to be there a couple minutes in advance. 

Another thing that has to be taken into account in our background systems: When you, as a customer, want the order to be home-delivered at 6 pm, the restaurant certainly does not see 6 pm as when the food needs to be ready for pickup. Instead, they need to have the food ready at, say, 5.44 pm.

That requires we need to know that the courier will need 16 minutes for delivering the food, which means we need to predict both the traffic conditions and the weather conditions days in advance and incorporate that information.

For our courier ops side, they will also need to see how many pre-orders are made for each day to make sure we have enough courier partners connecting to the Wolt platform.”

Step 3. Design the first version of how this will look for the end user

“When we have found the right needs, we start sketching the wireframe designs for the customer and the merchant apps. The latter runs on the tablet that the restaurants use to receive Wolt orders.

We add some production graphics on top of these wireframes and start testing those designs with actual real-life users.

Here, we learned a lot about how the order contents should be shown for the restaurant. For example, using colour to separate pre-orders from normal orders, and explicitly showing which orders are a bit late and thus need to be prepared now.”

Step 4. Build the functioning prototypes

“Next up, we build the actual working interactions for the apps. We test them both with the same users and restaurants that we had interviewed before, but also a fresh batch of people – just to get untainted feedback from a crowd who’s never seen this before.

For example, we knew that one thing we need to have is a selector for the time that you want to pick up your order, or to have it delivered. Will that selector be in the beginning of the process, in the middle, or at the end?

“We learned that we need to show the customer an animation.”

Now, it’s finally at the end. And there’s a good reason for that. We are developing new discovery and menu features which are coming soon. Once you see those, you’ll also understand why this choice for pre-order flow just needs to be the case.

Another example: When you make a normal order, the restaurant has only three minutes to confirm it. With the pre-order, the restaurant may need more time to be sure that they can fulfil an order prepared days from now. That’s why there’s a 15-minute window to confirm. For this time, we learned that we need to show the customer a certain animation. One that really communicates that the customer is still waiting for a confirmation – the restaurant might need to even make some phone calls within their staff to make sure they can deliver.”

Step 5: Test with the actual functionality we ourselves think is ready

“Finally, we hand out the actual restaurant app to the venues to give it a go.

We also invited some people from Wolt’s Facebook group to be members in an early-access test group using the actual software and we learn even more.

These two groups are different: For the user, things need to click in the very first go. For the merchant, this is a tool. When using a tool, it’s usually fine that it requires a few more times to get to know it, if as a payoff certain solutions make it way more efficient in frequent daily use.”

Step 6: Ship it

“Now, we have an actual feature ready to be shipped for you to enjoy.

Technical capability is not everything. Now we need to tell people we have this cool thing, and you can use it. So off you go.”