How to Boost User Experience Through Didi’s Service Governance
Estela Young
In the article “A Year of Doing User Experience” I once wrote that “a good user experience means users can achieve their goals without obstacles, efficiently, and beyond their subj...
In the article “A Year of Doing User Experience” I once wrote that “a good user experience means users can achieve their goals without obstacles, efficiently, and beyond their subjective expectations.”
In fact, whether from ordinary intuition or from reality, the situations where users feel the experience is poor most often occur in abnormal scenarios—e.g., “the user wants to check their housing fund but can’t open the page; the page opens but clicking ‘query’ throws an error; the user can click ‘query’ but no results are returned,” and so on.
Because of this premise, when we set out to improve user experience we usually start with negative feedback such as complaints and low ratings, and we prioritize fixing those issues. Of course, this approach can lead to an incomplete understanding of the problems. More comprehensive evaluation frameworks—such as NPS, CSAT, HEART, etc.—will be introduced in future posts if the opportunity arises.
This article attempts to take the relatively complex business context of Didi (滴滴) as a starting point, and, from the perspective of product design that users can actually perceive, briefly analyze Didi’s service‑control strategies and draw lessons for enhancing user experience.
1 What is Didi Service Control?
When a user orders a ride, they are purchasing a travel service—a non‑standard product. Take a commuter’s daily ride to work as an example: although the fare differences among rides are small, the condition of the car, the in‑car environment, and the driver’s service can vary widely. To keep the service level as consistent as possible, Didi controls the core experience issues that matter to users.
It is important to note that the level of service control differs across businesses and scenarios.
Different businesses have different standards. For instance, the premium “Didi Premier” (滴滴专车) not only restricts eligible vehicle models and requires a clean, tidy interior with tissues and bottled water, but also imposes strict rules on driver conduct. The most tangible sign for ordinary users is the driver’s six‑sentence script:
- “Hello, Didi Premier at your service.”
- “Is the temperature inside the car comfortable for you?”
- “Are we following the navigation route?”
- “Please fasten your seatbelt; we are about to depart.”
- “Please keep your belongings with you and exit on the right side.”
- “Thank you for using Didi Premier.”
In stark contrast, the ordinary “Express” (快车) service is essentially only required to be “safe” and “on time”; everything else is left unspecified.
Scenarios also differ. In the case of a pre‑scheduled airport pickup, the conditions under which a driver may cancel without penalty are far stricter because the passenger has already prepaid.
2 Core Ride‑Sharing Experience and the Scope of Service Control
As mentioned above, to maintain service quality Didi controls the core experience issues that users care about.
Using the most common “Express” service as an example, and setting aside dispatch‑related scenarios, the main service‑control areas—derived from frequent user complaints—are:
- Fare‑related issues – primarily overcharging, which can be broken down into detours, premature billing, delayed end‑of‑trip billing, and destination changes (e.g., after a fixed‑price ride has started).
- Service‑related issues – primarily cancellations, which can be subdivided into passenger cancellations (before the driver accepts, after acceptance, after driver arrival) and driver cancellations (after acceptance, after arriving at the pickup point, after the trip has started).
3 The First Step to Solving a Problem Is Decomposing It
To solve a problem you must first dissect it in detail, clarifying the scenario and the exact cause. This is the first and most critical step.
In section 2, the “overcharging” problem has already been split based on logic and user feedback into sub‑issues such as detours, premature billing, delayed billing, and destination changes.
For each sub‑issue, you then need to break down the specific causes using cases and user feedback. Take “detour” as an example:
- The user reports a detour, but there was none; the price difference is due to new congestion caused by changing traffic conditions.
- The user reports a detour, and the route indeed deviates; driver‑side data (trajectory, etc.) indicates it was the driver’s fault (e.g., the driver missed an exit on the 5th Ring Road and had to turn around at the next interchange).
- The user reports a detour, and the route deviates; platform data (navigation updates, etc.) suggests the platform’s routing was outdated, preventing the driver from following the optimal path.
- The user reports a detour, and the route deviates; passenger data (e.g., in a fixed‑price scenario the passenger picks up a friend) points to the passenger’s own actions.
When attributing sub‑issues, don’t stop at a logical enumeration. You must examine actual complaint cases (if you have 100 complaints a day, look at at least 1,000 entries). Reconstruct the situation using the original user text/audio, planned route, driver’s actual trajectory, passenger’s actual trajectory, the driver’s complaint history, etc. In this process you will inevitably uncover many unexpected scenarios—this is both the challenge and the charm of offline service control.
4 Three‑Pronged Approach: Pre‑, Mid‑, and Post‑Event Measures
Didi’s service control adopts a three‑pronged problem‑solving mindset: pre‑event, mid‑event, and post‑event interventions. To make this clearer, the following examples are framed from the user side.
One point worth emphasizing is that, besides actually fixing the issue and reducing its recurrence, managing user expectations to improve perceived experience is also crucial.
Pre‑Event Education
As described in section 3, “the user reports a detour, but there was none; the price difference is due to added congestion from traffic changes.” This scenario often stems from users not understanding the billing rules.
In China most “Express” rides use real‑time pricing—calculating fare based on duration and distance after the user inputs start and end points. However, traffic conditions change instantly, so the actual fare can differ from the estimated fare. When the final price exceeds the estimate by a noticeable margin (e.g., an estimate of ¥29 becomes ¥31), users remember “twenty‑something” turning into “thirty‑something” and feel overcharged, leading to detour complaints.
When addressing the issue, improving the accuracy of the estimate (e.g., by predicting traffic) is important, but educating users is equally vital.
The screenshots below show how Didi provides education both before the ride is confirmed and while the user is waiting for a driver response.
In addition, whenever a new feature launches or a user uses the app for the first time—especially fee‑related features—strong reminders such as pop‑up dialogs should be employed.
The following images illustrate how Didi notifies users in Chengdu about overtime waiting fees.
⟟TOK3⟧
Many product managers mistakenly assume users already understand the business well. In reality, most users are far less knowledgeable than we think. Even when users are savvy, it’s a basic duty to inform them. Avoid the “parental” Chinese mindset of “How can you not know this?” when communicating.
Mid‑Event Intervention
Compared with traditional street‑hailing, ride‑hailing benefits from abundant data, allowing direct intervention and responsibility attribution in certain scenarios. Didi can access, but is not limited to, the following data: estimated route (duration and distance), driver‑generated GPS trace, passenger‑generated GPS trace, post‑trip questionnaire responses, in‑car video/audio recordings, etc.
A typical mid‑event intervention case: a driver’s phone dies, causing abnormal billing for the current passenger. In this situation the system can proactively ask the driver whether a price adjustment is needed. Below are two passenger‑side examples for illustration.
Case 1 – The driver deviates from the prescribed route (e.g., misses an exit on a highway). After the trip ends, the system automatically adjusts the fare to the original estimate and charges the passenger accordingly.
Case 2 – At Hangzhou Xiaoshan Airport the driver adds a toll fee; the system prompts the passenger to confirm whether the fee is reasonable.
Post‑Event Feedback
After years of app‑based education (thanks especially to Taobao), ordinary users now know they can contact customer service when something goes wrong. Nonetheless, it’s undeniable that customer service is a cost center, which is why many companies now invest in AI chatbots, voice assistants, and even hide the service entry point to reduce manual complaints.
I have always argued that burying the customer‑service link does not solve the volume of complaints. Users already approach support with strong emotions; making them work harder to find the help they need only amplifies their frustration, ultimately raising the cost of resolution.
A better approach is to make the support channel easy to locate when a problem occurs, and to suggest possible issues based on the context, guiding users toward self‑service solutions. This can reduce the number of cases that require human intervention.
Again using Didi as an example, most complaints cluster after a trip ends (largely because they involve fares). Didi’s solution is to place a high‑priority, large‑size customer‑service card on the trip‑completion page, and to surface common Q&A items tailored to the user’s situation (e.g., if the system detects a possible driver‑delayed‑end‑of‑trip billing issue, it prominently shows “Driver delayed ending the trip” as a quick answer).
(Unable to find a domestic Didi screenshot, so a DiDiglobal image is used for illustration.)
That’s all.
Hope you find this helpful.
WeChat Official Account: A Product Dog’s Confession
Sharing product insights, reflections, and reading notes.
Thank you for following.
Originally written by Estela Young and published in Chinese on 一只产品汪的自白. Translated and edited for DriftSeas with permission.