Launching the first analytics view and building the foundation for a platform
SmartReserve is a Yandex Eats product for managing restaurant reservations. It was built after the acquisition of LeClick and has two parts:
I worked on the admin panel.
The problem
Yandex Eats had acquired a working reservation service, but its administrative side was not ready to scale. Restaurants still relied on support or account managers for many changes: configuration, access rights, and analytics.
We needed to launch the first version of the admin panel quickly — a product restaurant partners could use without a manager’s help. The product already included Guests and Reservations, but it had no clear home view.
My role
I contributed to the launch of the SmartReserve admin panel and designed key areas including analytics, guest segments, tags, campaigns, reviews, venue settings, authentication, and onboarding.
This case focuses on restaurant analytics. The goal was to make it a clear entry point into the panel and help partners make decisions using their data.
Starting with the questions the product needed to answer
The product manager brought a map of future directions, developed with their lead. They then presented a table of metrics to the team, grouped into reservation analytics, guest analytics, and service-quality metrics. Once the team aligned on it, we moved into implementation.
We used these questions to define the metrics and organise them into three areas.
We planned three future areas: Dining Room Occupancy, Guest Profile, and Quality. Shipping all of them at once would have taken too long, so we started with an Overview: one page of key metrics that answered three questions:
- What is happening in my restaurant right now?
- Where is there a problem or a change?
- What should I investigate next?
The first release combined high-level restaurant metrics with data on dining room occupancy, booking sources, guest segments, and tags. A helper widget highlighted issues in the top metrics or confirmed that everything looked normal. It was designed as the first step toward a more capable assistant in the future.
Making data readable
Most partners were not professional analysts. Adding more charts would not make the product more useful. Each chart had to help a restaurant manager notice a pattern and decide what to do next.
My scope covered data visualisation, the analytics component system, colour, time ranges, and choosing the right chart form for each metric.
Finding the right chart form
For each metric, I started by asking what the user needed to see: a trend, a comparison between categories, or an outlier.
Once the direction was clear, we tested the charts on real data and defined the behaviour they needed to support. Components had to work with two to five values, show forecasts, and remain understandable for the current day.
One difficult decision was how to show parts of a whole. Pie charts initially caused concern: some stakeholders saw them as imprecise and too difficult for an untrained audience. I explored several alternatives and argued for a pie chart in the specific case of two to five values. It made the whole and each share immediately legible, while values and trends remained visible without requiring hover.
I also developed the colour system. The palette had to work in line and bar charts, stay calm, and preserve contrast. I tested adjacent colours and the ordering of segments.
When a segment had no data, other colours could unexpectedly become neighbours, so I added one-pixel dividers between segments. This kept the chart readable even when the visual order changed.
We also explored a dining-room occupancy heatmap. It did not make the first release: several important partners did not see a need for it at that point. We postponed the idea and focused on familiar chart forms.
The resulting approach used familiar charts, a clear hierarchy, restrained colour, and enough context to compare metrics.
Designing for time and growth
Restaurants work across different time horizons. A manager may need to assess today, compare weeks, or understand a monthly change. I made the time range a visible part of the interface rather than an option hidden in a menu. Users could switch between day, week, month, and a custom range, then move quickly to adjacent periods.
For daily analytics, charts followed the restaurant’s opening hours and marked the current time. This made it clear which data had already been collected and which part was a forecast.
Overview was the first analytics tab, so I designed a system rather than a set of cards for one screen. We tested how many bars and values a chart could hold before becoming noise.
The resulting system included full-width and half-width layouts, mobile versions, empty states, and rules for different data densities. That gave later analytics sections a consistent foundation instead of requiring each screen to be designed from scratch.
Applying the system to Dining Room Occupancy
When we started working on Dining Room Occupancy, the metrics did not form a coherent story about how a restaurant was performing. We involved an analyst and structured the page into three parts: booking setup health, dynamics and sources, and occupancy structure.
Even then, the first block still lacked a clear answer to one question: “How is my dining room occupied right now?” We added a pie chart that showed the dining room as a whole and the relationship between walk-ins, reservations, and available seats.
This gave the page a clear top-level conclusion. The charts below could then explain why occupancy looked the way it did.
Outcome
We launched the first Overview: a clear entry point into the admin panel and a foundation for the next analytics sections.
During the first six months of the panel’s development, the number of supported scenarios grew by approximately 32 times and the number of tracked events by approximately 43 times. These figures describe the growth of the admin panel as a whole, not the impact of Overview alone.
For me, the main outcome was not a single dashboard. It was a system of decisions and components that could support the next areas of restaurant analytics.
