Designing a food delivery app starts not with beautiful screens but with the ordering scenario: what the person chooses, what changes the price and how many taps lie between the menu and the door. That is how we worked on the KruchuVerchu app, for a shawarma chain from Saint Petersburg: 30+ screens and four steps from the menu to the address.
Key takeaways
The chain wanted its own app where street food is ordered as cleanly and quickly as coffee in the best chains.
A plain list menu cannot do that: shawarma is built to taste, and add-ons, size and sauces change the total. If you show only a list of dishes, the guest will not see how their choice affects the price.
The project details are on the KruchuVerchu case page. We were responsible for the design: the brand, the interface and the logic of every screen.
The task was described with three requirements, and each can be checked on screen.
| Task | What we did | What the guest sees |
|---|---|---|
| Ordering in a few taps | A path of four steps: menu, dish card, basket, address | A short path with no extra sections |
| Shawarma built to taste | A configurator: ingredients, add-ons and sauces on one screen | A photo of the ingredient, the price of the add-on and a total that updates at once |
| A brand recognised on screen | Yellow, the flipped “VERCHU” and a spin in the interface | The brand in every gesture, not only in the logo |
No row can be closed with a beautiful mockup. They are checked by how many taps and screens remain between a hungry person and an order, and by whether the person sees the price of their choice at once.
On the card of a ready dish there is nothing to choose, while in a made-to-order dish the choice is the main part of the order.
| Criterion | Ready dish | Made-to-order dish |
|---|---|---|
| What the guest decides | To take it or not | What to build it from and how much extra to pay |
| What changes the price | Nothing, there is one price | Add-ons, size and sauces |
| What has to be shown | A photo and a name | A photo of every ingredient and the price of every add-on |
| Where it is easier to go wrong | In the description of the dish | In the total: the guest does not understand what it is made of |
The conclusion for design follows: a made-to-order dish needs a separate configurator screen with a live total. Without it the advantage of “build your own” turns into guesses about the price.
The order path is designed as one movement: menu, dish card, basket, address.
In its design guidelines for iOS Apple advises you to limit the number of on-screen controls and make secondary actions available with minimal interaction. A short path of four steps applies the same principle to ordering: every extra section is an extra reason to give up.
How such scenarios are built and which mistakes appear most often in mobile interfaces, we described in the article on mobile app UX/UI design.
A configurator is needed where a product is assembled for the customer rather than chosen from a ready list. In KruchuVerchu it shows a photo of every ingredient and an honest price for each add-on, and the total updates on the fly, with no extra screens.
The guest chooses ingredients, add-ons and sauces on one screen. The price of an add-on is visible at once, so the person does not discover a surcharge at the last step but decides at the moment of choosing.
A photo of the ingredient answers the question “what will I get”, and the price next to it answers “how much does it cost”. When both answers are on one screen, choosing does not require going back and forth.
Example A configurator works for more than shawarma. At a pizzeria the base, toppings and size are also chosen separately, and the total depends on the choice in the same way. The ordering logic is built on one principle and suits any place where a product is assembled for the customer.
The name KruchuVerchu spins around the skewer, and so does the interface: from building a shawarma to the order status ring.
The brand was given the task of reading in every gesture, not only in the logo. There are three signs for that: yellow, the flipped “VERCHU” and a spin. The palette, fonts and icons are collected in one design system, so all screens look like parts of one app.
How names are chosen and why a whole presentation can grow out of one, we covered in the article on naming.
Tip Give the brand movement, not only colour. Colour and type can simply be copied, while the chain “name — movement — interface” rests on meaning. If the name has an image, check whether it can be shown in an animation and in the order status, not only on the packaging.
All KruchuVerchu screens are collected in one design system, and the work can be split into four blocks.
A single system is not there for tidy files. When the app is developed and extended, a new screen will be assembled from ready components rather than drawn again and reconciled with the rest.
The client was planning to publish on the App Store, so the design system and every screen were designed specifically for iOS.
The choice of platform shapes design decisions: iOS has its own gestures, its own system components and its own rules for placing elements. Apple, for example, reminds designers that controls are easier to reach in the middle and lower part of the screen, which is worth keeping in mind when you decide where the main button goes.
If Android is needed later, it will require separate work for the rules of that platform, and it is better to put that work into the plan in advance.
If the app is needed on two platforms at once, start with the article on mobile app development for iOS and Android. And what is checked before release to the store is covered in the article on publishing in the App Store and Google Play.
The client received 30+ screens, a design system and the ordering logic, from the storefront to courier tracking. This is a product ready for development, not a finished app, because code was not part of the project.
These 30+ screens include the storefront, catalogue, dish cards, configurator, basket and tracking. For a developer this is a reference point: the app is built from ready screens and ordering logic, not from a description in words.
The case has no figures for orders, revenue or speed, and we do not invent them: the result of the project is a product ready for development.
These questions suit any service where the customer builds the order: from a coffee shop to a pizzeria. Ask them before you start drawing screens.
Mistake Showing the price of an add-on only in the basket. The person builds a dish without knowing the price and sees the total only at the end, when the decision is harder to change. A configurator is honest when the price updates in the same place where the choice is made.
You can check the result on a phone: go from the menu to the address and count the taps, then build the most complex dish and make sure that after every choice it is clear what it costs. If you have to guess, the design is not finished.
We start with the ordering scenario and with what changes the price in it, not with the styling. First the path from the menu to the address, then the configurator, then the brand, icons and components in one design system. That way the screens agree with each other, and the developer gets described logic rather than a set of pictures.
We are responsible for the design: the brand, the interface and the logic of the screens. Building a website or a platform can be ordered separately; formats and prices are collected on the page for website and platform development. We clarify the task and the scope after a short conversation.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Only the design: the brand, the interface and the logic of every screen. The result is 30+ screens and a design system ready for development, not a finished app.
It suits any place where a product is assembled for the customer rather than chosen from a ready list: the ordering logic is built on the same principle. At a pizzeria, for example, that is the base, toppings and size; for shawarma it is ingredients, add-ons and sauces.
Add-ons, size and sauces change the total, so the configurator shows the photo of an ingredient and its price at once and recalculates the sum on the fly, with no extra screens.
The client was planning to publish on the App Store, so the design system and every screen were designed specifically for iOS.
Four: menu, dish card, basket, address. The path is designed as a single movement, with no extra sections.
30+ screens, a design system and the ordering logic, from the storefront to courier tracking. This is a product ready for development.
