Delimobil 2019–2020 Mobile UX · Rental lifecycle
Five rental states. Clear costs and actions.
Booking, driving, and waiting looked almost the same. I helped redesign five rental states so drivers could tell what was happening, when they were paying, and what to do next.
Design approved for development. Full rollout and post-launch impact unconfirmed.
My role & the design decision
Make state and cost determine the interface priorities, with secondary detail in a sheet above the map.
My contribution
As Lead UX/UI Designer, I helped restructure the rental flow, state-specific controls, car information, and fare selection with the design team.
Collaboration
Three designers, three product managers, and nine engineers worked on prototypes, support surveys, and customer interviews.
A similar-looking screen could mean a different bill
The existing structure changed little between selecting a car, free booking, paid booking, driving, and paid waiting. People could miss the start of paid time or put a car into waiting when they thought they had ended the rental.
These are different commitments. The interface needed to communicate the active state before asking the driver to act.
Five states, five different questions
I treated the rental lifecycle as a set of state-specific priorities. The map remains useful, but it cannot be the only organizing principle when time and money are changing.
Paid waiting is a branch of an active rental. It must be distinguishable from ending the rental, with a clear route back to driving.
Car selection
Is this the right car and fare?
Model, fuel, location, and fare before reserving.
Free booking
How long do I have to reach it?
Remaining reservation time and the action to access the car.
Paid booking
Has charging started?
The active charge and accumulated cost, with a clear next action.
Driving
What is my rental costing?
Rental cost and separate actions for waiting and ending the trip.
Paid waiting
Am I still renting the car?
Waiting cost and the action to return to driving.
Keep essential information above the fold
Important actions were hidden below the visible area. Fare selection had room for only three options, and checking fuel required opening a map pin.
The redesign moved model and fuel information onto car markers and gave fares a dedicated view. A swipe exposed more detail without permanently filling the map with controls.
Alternative considered
Keep every control on the map
Makes more functions visible at once.
Trade-off. Competes with the current state and crowds a small screen.
Selected direction
Prioritize the state; reveal detail
Keeps the immediate action and cost information in view.
Trade-off. Secondary information takes a swipe, so essential cost and state cannot depend on discovering it.
Existing constraints
Reorganized selection
Test the moments where a wrong assumption costs money
The team combined competitor research, quick prototype tests, support-distributed surveys, and interviews with new and existing customers. Sessions included difficult situations such as an app failure, an unlocked car, and reaching support.
The evaluation question was whether people understood the state and could take the intended action. The available record does not include task-level success rates, so I do not present a numerical usability improvement.
- Booking becomes paid
- Can the driver recognize that the free reservation period has ended?
- Waiting is still a rental
- Can the driver tell whether they have paused or ended the rental?
- Something goes wrong
- Can the driver reach support and check if the rental is active?
Different states now have different priorities
The before-and-after comparison shows the shift from repeated screen structures to a rental model organized around state, cost, and action.
A shared structure keeps the app recognizable. The content and primary action change with the driver’s commitment, rather than leaving people to infer it from a small label.
Approved for development
Design approved for development. Full rollout and post-launch impact unconfirmed.
Some elements later appeared in the existing app. I left before I could verify the complete rollout, so the outcome here is the approved design and its state-based structure.
Success would mean fewer state errors, not more taps
These are criteria for evaluating the redesign, not post-launch findings. A task-based test should verify state comprehension before any live experiment involving charges.
Primary KPI
- Correct state transitions
- Drivers who reach the intended state without selecting waiting when they mean to end the rental.
Supporting metrics
- Paid-time comprehension
- Correctly identifying whether charging is active in reservation, driving, and waiting scenarios.
- Time to the intended action
- Task time for reserving, accessing the car, entering waiting, and ending the rental.
Guardrails
- Unintended charges
- Billing-related support contacts connected to a misunderstood state.
- Failure recovery
- Ability to reach support and establish rental status when the app or car does not respond.
The state is the interface’s first responsibility
Secondary detail can sit behind a gesture; active charges and rental status cannot. That distinction shaped the redesign. The next step would be to test the transition from waiting to ending a rental under realistic time pressure.
