Introduction
Yandex Eats is a food delivery service connecting customers, restaurants, and couriers. When something goes wrong with an order — a late delivery, a missing item, a payment issue — support operators investigate and resolve it through an internal admin system.
The order page is the core of that workflow: it brings together information about the customer, courier, restaurant, payment, and delivery status. But years of piecemeal development had turned it into a fragmented interface where even finding basic information took time.
This case covers rebuilding the order page around how support actually diagnoses a problem, cutting information lookup time roughly in half.
Role
Product Designer
Sole designer on the project. Owned research, information architecture, interaction design, UI, design system, and developer handoff
Team
Product Designer
Product Manager
Development Team
Design Lead (review)
Timeline
~3 weeks research
~2 months design & alignment
~2 months implementation & review
Context
Business
Support quality was becoming a business problem: customer reviews increasingly mentioned slow or unhelpful support, while high operator turnover meant new people regularly had to learn a complex internal system.
At the same time, Yandex Eats was preparing to expand into new geographies. The admin had grown piecemeal without design involvement or reusable patterns — difficult to learn, maintain, and scale.
And this wasn't a niche internal tool: every support operator used it, and every customer request passed through it accordingly.
Problem
Years of piecemeal development had left the order page without a consistent structure. Information was placed wherever there was room for it: high-use and obsolete elements competed for attention, related data was split across the page, and visually prominent sections often had little relationship to how frequently operators needed them.
Operators had the data they needed, but the page gave them no clear path through it
Constraints
There was no existing design system: patterns had been hardcoded independently over time. The timeline was tight relative to the number of known issues, and there was internal resistance to investing additional development effort into an internal tool.
Work Scope
The support order page — customer, courier, timing, order, payment, and restaurant information — plus search, courier tracking, core actions, and the design system underneath it.
Research
I started by learning how operators actually worked: a week immersed in support workflows, operator training, and real support call recordings.
After that, I followed my research with:
The interviews surfaced a broad set of issues, but the timeline made solving everything unrealistic. I used a prioritization survey to identify what mattered most to operators, then benchmarked the existing admin through timed usability testing — measuring how quickly they could analyze an order and find key information. This gave me a baseline to validate the redesign against later.
What stood out
Finding information was work
of its own
Operators described the admin as chaotic and tiring to use. Important information was buried, while obsolete or rarely used fields occupied some of the most prominent positions.
Operators used separate tools for customer chat, calls, and courier tracking. Even a common delay ticket required repeatedly switching context.
The interface contained most of the information needed to solve the problem, but gave operators little help moving through it.
Key Decisions
Instead of preserving the existing layout, I grouped information by the operator's task: each block answers one clear question and keeps related data and actions together.
Order
Understand the order context at a glance: its status, key details, address, and anything unusual that may affect the case
Client
Quickly assess who the customer is and what matters for resolving their request, including their status, order history and previous interactions
Timing
See immediately whether the order is delayed, by how much, and at which delivery stage the delay occurred
Courier
Understand who is delivering the order, what has happened on their side, and take the most common courier-related actions without searching elsewhere
Keep restaurant details and contact context in one predictable place when the issue needs to be escalated or verified
Items
Make the current order composition and all changes easy to scan, especially for missing, replaced, or modified items
Payment
Give payment status and order totals their own compact area instead of mixing it within other blocks
Courier location was critical when investigating delays, but previously required leaving the admin and opening Yandex Go.
I integrated tracking directly into the order page, but kept it on demand rather than loading the map by default.
Building a system instead of another one-off page
I designed a reusable component system alongside the new order page, covering the core components, states, patterns, and developer specifications needed across the admin.
The development team initially pushed back on introducing the additional process during an already time-constrained project. The PM and I made the case in terms of development reuse, easier maintenance and upcoming geographic expansion, rather than visual consistency alone.
Other shipped work
Search & secondary pages
I simplified search by keeping frequently used parameters upfront and moving rarely used fields into advanced options. Status and change-history pages already worked well, so I kept their logic and refreshed them with the new component system.
Better modals
I introduced task-focused modals for actions that needed more space without taking operators away from the order page, including courier tracking with key delivery details and a new date and time picker.
Real-time change notifications
I added notifications for order updates that happened while an operator was working on a ticket, reducing the risk of acting on outdated information.
Some future work
Dark theme
Frequently requested by operators working full shifts in the admin. It was prioritized as the next design-system improvement after the core order page was shipped.
Keyboard shortcuts
An interview insight led to a proposal for shortcuts for repetitive actions. The direction was approved, but implementation was left for a later iteration.
Further design system rollout
The new system was designed to extend beyond the order page. The next step was bringing more internal admin surfaces onto the same components and interaction patterns.
Result
Faster
I repeated the original courier-delay test with a different group of roughly 20 operators, using the same scenario and questions.
For instance, in one scenario operators had to determine:
Is the order late? → By how much? → Why? → Where is the courier? → What should happen next?
The average task achievement time per step dropped from 13–14 seconds to 5–8 seconds.
Shorter
The page itself also became roughly 40% shorter after obsolete and redundant information was removed and the remaining content restructured.
Systematized
Reusable foundation for subsequent admin pages
I left Yandex before longer-term operational metrics became available, so unfortunatley I don't attribute changes in support KPIs or business performance to the redesign. The result I could measure directly was clear: operators could find the information needed to diagnose the same support scenario in roughly half the time.
