Gett - Bookings architecture redesign
System redesign
Cross-product impact
Web
B2B
Mobility
A system-level redesign of Gett’s Bookings Dashboard. I identified a broader architectural problem and proposed a more scalable interaction model for managing rides across their lifecycle.
Product: Gett Web Platform | Team: Gett B2B | Role: Senior Product Designer | Timeline: Mar - Apr 2026
Current Bookings Dashboard
Consists of fixed booking form, tabs for tracking rides and ride cards
Context
Bookings dashboard
Gett’s B2B customers use the Bookings Dashboard to create rides and manage them throughout their lifecycle.
Ride card
Ride cards contain essential information about a ride. A card can be expanded to show full ride info.
Booking form
The booking form is used to create a new ride / delivery order for one or several passengers.
Current Bookings dashboard issues
User challenges
• Small screens: 25% of users had a 1280 × 720 display. • The booking form is always visible, even when users weren’t booking a ride. • Too few ride cards fit on screen (3 in average). • Expanding a card made the surrounding ride list context hidden.
Platform challenges
• No room for new tabs and workflows. • Inconsistent ride layouts across lifecycle stages. • Separate web and mobile web components increased design and engineering effort. • The dashboard was trying to function as both a monitoring surface and a ride-creation surface.
A legacy layout leaves little room to work
Fixed panels take up much of the screen, leaving users with a cramped area to manage rides, especially on smaller displays.
Problem Definition
I reframed the problem from:
to:
That led to three design principles:
1.
Ride management should use a consistent interaction model across the product.
2.
Creating a new booking should not permanently reduce the space available for managing existing bookings.
3.
The architecture should make future workflows easier to introduce rather than forcing another redesign.
My Role
As a Senior Product Designer, I identified the architectural problem while working on other workflow and proposed expanding the scope beyond the immediate feature.
Instead of finding another local workaround for a new workflow, I initiated a redesign of the entire Bookings Dashboard interaction model.
I led the redesign closely collaborating with the PM, analysts and engineers.
Research and analysis
Ride behaviour
• The dashboard displayed rides as expandable cards on any tab. • Completed rides stayed in 'Past 24h' for 24 hours, then moved to Reports section. • In Reports, the same rides appeared in a table with a details sidebar. • On mobile web, tapping a ride card opened a separate details screen.
6 different components for the same entity
• Web Dashboard: collapsed card • Web Dashboard: expanded card • Mobile Web Dashboard: ride card • Mobile Web Dashboard: ride details screen • Web Reports: table row • Web Reports: ride details sidebar
I used MixPanel and Logrocket data for quantitative and qualitative research.
Checked the share of users with smaller screens and how they interact with Bookings dashboard.
Also I interviewed account managers for a feedback from customer companies which have more than 100 rides in dashbord at the same time.
Hypotheses
HYPOTHESES
EXPECTED IMPACT
RISK
Moving the booking form behind an explicit New Booking action will improve the use of screen space.
EXPECTED IMPACT
Removing the permanently visible form will free approximately 400 px of horizontal space when users are managing existing rides.
RISK
High
Users may find booking less discoverable, or the layout may become difficult to use when they need to view an open ride alongside the booking form, which now appears on the right side of the screen.
Replacing expandable cards with a table + details panel model will make Bookings more scalable.
EXPECTED IMPACT
More rides will be visible at once, while users can inspect a ride without losing the surrounding list context.
RISK
Medium
A denser table may make individual rides harder to scan or understand, especially for users who are accustomed to cards.
Using a shared interaction model across Bookings, Reports, and future ride-management workflows will make the product more consistent.
EXPECTED IMPACT
Users will be able to transfer their knowledge between sections, while new workflows can be added without introducing another layout pattern.
RISK
Low
The main ride actions are already handled by an established pattern: primary actions are shown as buttons at the bottom of the sidebar, while secondary actions are grouped under a three-dot menu in a dropdown. So the risk is minimal.
Reusing the same core ride-details component across product areas will reduce duplication.
EXPECTED IMPACT
Engineering can maintain a more consistent ride representation across web and mobile web, reducing implementation and maintenance effort.
RISK
Low
Shared components may become overly generic or difficult to adapt when individual surfaces require specialised information or actions.
Exploration
Consistency principle
• Rides are represented as rows for all web. • Selecting a ride opens its details in a side panel.
• The table remains visible while a ride is inspected. • Users switch between rides without repeatedly expanding and collapsing content.
Rides were shown as cards and as table rows
Moving from ride card to compact table row
A more compact layout preserves key ride details and makes room for additional information.
Dashboard with table rows
More than 8 rides (before scroll) could be visible at once instead of approximately three or four even on small screens.
Shared ride details
Instead of treating Bookings and Reports as separate UI systems, I proposed using the same underlying ride-details structure wherever possible.
Different ride states could expose different actions, but the basic way users read and navigate ride information would remain familiar.
This also opened the possibility of reusing the same component architecture in mobile web, rather than building another independent representation of a ride.
Booking as an intentional action
The permanent booking form was useful only during ride creation, yet occupied around 400 px of the screen at all times.
I proposed replacing it with a prominent New Booking action. Opening it would create a Booking form that could be minimised and restored later, similar to Gmail Compose.
This preserved the ability to start a booking without forcing the booking form to dominate every other task on the page.
Inspired by Gmail Compose: minimise the booking form and restore it when needed.
New booking wizard
Steps are based on previous logic, tech constraints and interactions between internal services.
For example, platform will know what vehicle classes are available for a ride only after pickup is set.
Also vehicle classes could be limited by passenger's travel policy. So classes are shown after choosing a passenger and setting a pickup point.
Stepped wizard approach instead of long one-form approach made booking process much easier for bookers, and simplified errors handling
Room for new workflows
With the permanent booking form removed and the ride list made denser, Requests could become a first-class part of the dashboard rather than something squeezed into an already overloaded layout.
More importantly, the architecture would have room to accommodate additional ride states or workflows later.
Solution
The proposal changed Bookings from a page built around two permanently competing areas into a flexible ride-management workspace.
The redesigned architecture consisted of:
• compact table for scanning and managing multiple bookings. • persistent ride list context while viewing ride details. • right-side details panel based on the model already used in Reports.
• dedicated Requests section for Admin Approval. • on-demand New Booking flow instead of a permanently visible form. • shared ride representation that could be reused across different stages of the ride lifecycle.
Validation
Because this was an architectural proposal, I validated it primarily through product and technical review. I first discussed the concept with the Product Manager and worked with engineers to understand whether the interaction model could share components and data structures with Reports. Also I collected a feedback from Account managers.
The proposal was then presented to the CTO and other Product Managers. The concept received strong support, particularly because it solved more than the immediate additional workflow requirement, and created a clearer direction for the broader ride-management experience.
Results
Learnings
Look beyond
The Admin Approval request revealed a broader architectural problem in the Bookings Dashboard. Instead of adding another workaround, I questioned the underlying interaction model and addressed the system-level issue.
Recognise structural inconsistency
Working across Bookings and Reports showed that the same ride entity was represented through two different interaction models. Identifying this inconsistency helped create a more unified and scalable product experience.
Make existing patterns reusable
The project reinforced the value of looking beyond individual screens and reusing successful product patterns. The table-and-details model from Reports became a foundation for improving Bookings and supporting future workflows.
Next Steps
Redesign Booking form
After implementing the new dashboard architecture, the next step would be to redesign booking flow, replacing the long form with a step-by-step wizard.
Why?
A step-by-step wizard could validate dependencies at each stage. For example, changing the ride time might conflict with the selected vehicle class or passenger. Checking these dependencies early would prevent confusing conflicts in a long form.
How?
With QA, I would define which errors block progression, which appear inline, and how users can fix issues in earlier steps without losing their input.
Additional insight 1 : The booking form needed a more structured flow
Additional insight 2 : Multi-passenger bookings could be significantly simplified
OBSERVATION
EVIDENCE
IMPLICATION
In 70% of multi-passenger bookings, both passengers shared a route, creating an opportunity to simplify booking by eliminating duplicate pickup and drop-off entry.
EVIDENCE
Around 85% of multi-passenger rides had two passengers. In 70% of those, both shared the same pickup and drop-off locations.
IMPLICATION
To simplify the most common scenario, I proposed defaulting the second passenger’s pickup and drop-off to the first’s, with a clear option to change them. I reviewed interaction options with product and confirmed feasibility and booking logic compatibility with engineers.
By default, switch is turned ON for each subsequent passenger