Building rohlik digital experience
How I worked on checkout, live order updates, an AI shopping assistant and the design system behind one of Europe's online grocers.
Designing the everyday grocery run at Rohlik.cz
Online grocery is a strange product to design. People use it every week, often in a hurry, with a kid on one arm and a half-empty fridge in front of them. Nobody wants to admire the interface. They want the order placed, the slot booked and the bags at the door on time.
At Rohlik I worked as a product designer alongside leadership on where online grocery shopping should go next. I owned UX and UI across several initiatives and ran research with customers to test ideas before we committed to them. This piece covers the work as a whole, with most of the space given to the two areas I think get underestimated: checkout and live order updates.
How I worked
Most of my research was interviews with customers. Sometimes I put a Figma prototype in front of them, sometimes we walked through the live web or app together and I watched where they slowed down. Testing on the real product showed me what was actually broken. Testing on prototypes let me check a direction before engineering spent time on it.
My part covered the full path from those conversations to shipped UI: flows, interaction details, visual design and handover to developers.
Checkout: the screen where the order is already won or lost
By the time someone reaches checkout, the hard work is done. They found the products, filled the basket and decided to buy. Every bit of friction after that point loses an order that was already yours. That makes checkout one of the highest-stakes screens in any shop, and in grocery it's also one of the most complicated.
A grocery checkout is not a payment form. It has to settle a lot of real-world logistics in one place: where the order goes, who receives it, how it's packed, what the courier should know, when it arrives, how it's paid and which vouchers or credits apply. Each of those is a chance to confuse someone or make them second-guess the order.
The checkout I worked on puts all of it on a single screen as a stack of summary rows. Each row shows the current choice in plain words ("Reusable bags", "Today between 21:00 and 22:00", "Electronic receipt") with an edit control beside it. Returning customers mostly see their saved defaults and can confirm in a glance. New customers, or anyone changing plans, can open just the row they need without leaving the order.
Grocery also has details that a generic e-commerce checkout never has to deal with. The courier note lets people say things like "sleeping baby, please be quiet", which matters when a delivery arrives at someone's door late in the evening. The reusable bag deposit appears as its own line, so the total doesn't look wrong. And a notice tells customers how long they can still add items to the order, which removes the worry of placing an order too early and forgetting the milk.
Live notifications: the order isn't finished when it's placed
Most shops treat the order confirmation as the end of the experience. In grocery delivery, that's when the waiting starts. People plan their evening around a delivery window. They want to know whether they can take a shower, go downstairs or start cooking.
Without live status, the only option is to keep opening the app, or to contact support and ask where the order is. Live activities answer that question before anyone has to ask. Showing the order's progress in real time, from packing to the courier being on the way, turns waiting into something predictable.
That's why I think live notifications deserve real design attention rather than a default push-message template. The space is tiny, it's read in a glance, and it has to stay accurate as the situation changes. Getting the states and the wording right matters more than the visual polish.
Custom shopping experience
Weekly grocery shopping is repetitive. Most baskets look a lot like the last one, so the store should adapt to the customer instead of making them search for the same products every time. My work here was about making the shop feel shaped around each customer's habits.
Maia, the AI shopping assistant
Maia is Rohlik's AI shopping assistant. Grocery suits a conversational helper well, because many shopping needs start as a goal rather than a product name: "something for dinner tonight", "a birthday party for ten kids", "what do I need for this recipe". An assistant can turn that intent into a basket, which the search box alone can't do.
The design challenge with any AI assistant in a shop is trust. People need to see what the assistant added and why, and be able to change it easily, or they'll stop using it after the first wrong suggestion.
Referral program
A grocery service grows best through people who already use it, because a friend's recommendation answers the trust question better than any ad. A referral program makes that easy and rewards both sides. The design work is in making the invite simple to share and the reward clear to both people.
The Rohlik design system
All of the above sits on the Rohlik design system, which I helped manage. My work covered creating new components when the product needed them, handing them over to developers, and maintaining the library as the product changed.
A design system pays off in work like this because so many teams touch the same customer journey. When checkout, notifications and the assistant are built from the same components, the product feels like one shop instead of several projects stitched together, and new features ship faster because the basics are already solved.
Designing the everyday grocery run at Rohlik.cz
Online grocery is a strange product to design. People use it every week, often in a hurry, with a kid on one arm and a half-empty fridge in front of them. Nobody wants to admire the interface. They want the order placed, the slot booked and the bags at the door on time.
At Rohlik I worked as a product designer alongside leadership on where online grocery shopping should go next. I owned UX and UI across several initiatives and ran research with customers to test ideas before we committed to them. This piece covers the work as a whole, with most of the space given to the two areas I think get underestimated: checkout and live order updates.
How I worked
Most of my research was interviews with customers. Sometimes I put a Figma prototype in front of them, sometimes we walked through the live web or app together and I watched where they slowed down. Testing on the real product showed me what was actually broken. Testing on prototypes let me check a direction before engineering spent time on it.
My part covered the full path from those conversations to shipped UI: flows, interaction details, visual design and handover to developers.
Checkout: the screen where the order is already won or lost
By the time someone reaches checkout, the hard work is done. They found the products, filled the basket and decided to buy. Every bit of friction after that point loses an order that was already yours. That makes checkout one of the highest-stakes screens in any shop, and in grocery it's also one of the most complicated.
A grocery checkout is not a payment form. It has to settle a lot of real-world logistics in one place: where the order goes, who receives it, how it's packed, what the courier should know, when it arrives, how it's paid and which vouchers or credits apply. Each of those is a chance to confuse someone or make them second-guess the order.
The checkout I worked on puts all of it on a single screen as a stack of summary rows. Each row shows the current choice in plain words ("Reusable bags", "Today between 21:00 and 22:00", "Electronic receipt") with an edit control beside it. Returning customers mostly see their saved defaults and can confirm in a glance. New customers, or anyone changing plans, can open just the row they need without leaving the order.
Grocery also has details that a generic e-commerce checkout never has to deal with. The courier note lets people say things like "sleeping baby, please be quiet", which matters when a delivery arrives at someone's door late in the evening. The reusable bag deposit appears as its own line, so the total doesn't look wrong. And a notice tells customers how long they can still add items to the order, which removes the worry of placing an order too early and forgetting the milk.
Live notifications: the order isn't finished when it's placed
Most shops treat the order confirmation as the end of the experience. In grocery delivery, that's when the waiting starts. People plan their evening around a delivery window. They want to know whether they can take a shower, go downstairs or start cooking.
Without live status, the only option is to keep opening the app, or to contact support and ask where the order is. Live activities answer that question before anyone has to ask. Showing the order's progress in real time, from packing to the courier being on the way, turns waiting into something predictable.
That's why I think live notifications deserve real design attention rather than a default push-message template. The space is tiny, it's read in a glance, and it has to stay accurate as the situation changes. Getting the states and the wording right matters more than the visual polish.
Custom shopping experience
Weekly grocery shopping is repetitive. Most baskets look a lot like the last one, so the store should adapt to the customer instead of making them search for the same products every time. My work here was about making the shop feel shaped around each customer's habits.
Maia, the AI shopping assistant
Maia is Rohlik's AI shopping assistant. Grocery suits a conversational helper well, because many shopping needs start as a goal rather than a product name: "something for dinner tonight", "a birthday party for ten kids", "what do I need for this recipe". An assistant can turn that intent into a basket, which the search box alone can't do.
The design challenge with any AI assistant in a shop is trust. People need to see what the assistant added and why, and be able to change it easily, or they'll stop using it after the first wrong suggestion.
Referral program
A grocery service grows best through people who already use it, because a friend's recommendation answers the trust question better than any ad. A referral program makes that easy and rewards both sides. The design work is in making the invite simple to share and the reward clear to both people.
The Rohlik design system
All of the above sits on the Rohlik design system, which I helped manage. My work covered creating new components when the product needed them, handing them over to developers, and maintaining the library as the product changed.
A design system pays off in work like this because so many teams touch the same customer journey. When checkout, notifications and the assistant are built from the same components, the product feels like one shop instead of several projects stitched together, and new features ship faster because the basics are already solved.