Redesign the ride history function of the new version

 Didi App Screenshots from   App Store

Didi App Screenshots from App Store

Project Info  Internship project@ Didi

My Role   UX Design Intern (Collaborated with a PM and developers)

Date   July - Aug, 2016





In 2016, I interned at Didi as an UX designer for 6-month. Didi is a mobile app cooperation that commits to building an intelligent ride-sharing platform. It allows consumers to request a trip and then be picked up by Didi drivers. Didi now serves for almost two hundred million users around China.

Fortunately, during this time, Didi was merging with Uber China, so I had a chance to participate in the 5.0 new version design process. I was a part of the pitch team and responsible for the design of the Ride History section. Mentored by a senior UX designer, I produced major deliverables and presented these on design critiques as well as technical reviews. Also, I worked alongside a product manager and developers. They helped me to grow fast as a professional UX designer and learned about how to collaborate as a team.

The 5.0 version of the app launched on February, 2017.




The Didi's Rider app — designed in 2014, struggled to scale alongside the hyper-growth of the complex service lines and the company itself. As anyone whose ever used Didi app knows... It's HUGE. It has nine service lines (taxi, pool, bus, didi, etc) and disparate features of each service line competed for focus. We realized that to make Didi accessible to increasingly users we need to integrate the whole app with a consistent design guideline. Then we decided three keywords to guide our new version's design work: 

design goals.png

Since we were asked to deliver high-fidelity prototype to technical production partners within two months, our team was under great pressure to move fast. Besides, the combination of a fixed deadline, technical reviews, UI development, usability testing meant I needed to get my part of work done in first 3 weeks. 


Picking Up the Pieces


Get in touch with the users

At the outset of the project I didn't have a clear goal for the after-ride experience. Though I got some research data from our user research team, I decided to make 20 more rides personally in the first week by using Didi app. I wanted to explore who were our users, how they were using our app, and what were their after-ride experiences. During the rides, I talked with other passengers casually and asked questions like "Tell me about your experience of using Didi", "Why you are using Didi", "When will you look at your Ride History", "What's your least favorite part of using Ride History function"and so on.  

Combining my personal research findings with the existing user research data, I realized that for designing the Ride History part, I should focus on daily commuters. There are more than 30000 companies in China, including Lenovo, Huawei, and Alibaba,  remunerate their employees' commuting expenses by using Didi. Amongst all rides, commuters need to select their commuting ones and invoice them in Ride History part of the app. I discussed my findings with my product manager, Mingyu, and then created a persona below:


I used this persona constantly throughout the project to guide design decisions, priorities and develop a clear picture of who the design of the Ride History section of the app would target.


What's wrong?

After building my basic understanding about the travel process and figured out our primary users, I communicated with my design mentor and the product manager to try to figure out the problems that needed to be improved within the passengers' ride history: 


Deeper Insights

How to define a success of my design?


The issues we found felt like just commuters' annoyances, rather than major problems faced by our common users. I was worrying about whether developing potential features would make the app complex for common users? How can I find a balance? After some thinking, I realized that all riders expected the experience to just work with minimal effort. The goal of adding potential features was to simplify the whole process, it should perfect the after-ride experience for everyone, not only daily commuters.

Then I decided to define success and understand user context at scale before I really jump into designing. I partnered with my product manager to unpacked the concept of perfect invoicing process and used this framework to investigate the success metrics:

success metric.png

1. Redesign the ride card

A ride card that users could read

Desktop Copy 7.png


What I wanted to create was a simple up-front impression that didn't overwhelm with information and interactions that only occasionally needed. Therefore I realized that the ride card had to be logically structured with the most important information up front and detailed information secondary. Information that people have deeper memory and used most to recognize a past ride should be more readily accessible, and more detailed ride information should require one extra step. 


What information do users need?

Before I jump into designing, I believed that it was important to understand the different information that would present in different use cases. I mapped all the possible information and analyzed the issue in respect of the basic information, contexts ,and roles:

ride information-01.png

Visualizing the End-to-End

Then I was wondering "What information is really needed here?" "How can users recognize a certain trip?" I decided to analyze the complete flow with a typical use case and listed all the key information in each step:


Outside of the app context helped me understand how the problem should be approached. Out of this, four categories of key information appeared above. However, considering the complexity of Didi's service lines and additional information that I got from user researchers, I decided to also include the service information on the ride card. Since there were considerable amount of users using 2 to 3 types of service in their daily rides. 

 Key information

Key information


And I started sketching

From the start I had a general idea for what I wanted the ride card to emphasize, but I didn’t have a clear picture about how to integrate different types of information. What I wanted was to provide users a simple way to experience the huge number of ride cards and recognize each cards easily. To get rid of the overwhelming presentation of all types of information and emphasize the most important information , I categorized them into 3 areas: ride information area, order information area, and shortcut button

For the shortcut payment button, the idea was that as the card functionality grew in the future, we could utilize the interaction behaviors that the "action button" provided.


And then I redrew the card by Sketch. Compared with the original design, I added driver information, service type, order state, and cost to complete the trip information. As for the payment button, it would not be displayed unless the order is not finished,

D Trip Card .png

Wait...The card is too large

However, the redesigned card was much larger than the former one which means that users have to continue sliding to look through all their recent rides. How can I reorganize the content and shorten the card's height?

card comparision.png

I made my first attempt by trying to put the pickup time in the card title. Below are my design iterations with two layouts:

D Trip Card ITERATION 1&2.png

In the iteration 1, I highlighted the service part by putting it on the top-center of the card. In the iteration 2, I arranged the time part for a change. These were the most vital information that passengers would use for trip searching and identification. However, when both the date and service character length are long, there is no enough space. So I reorganized the information in a different way, which led to the birth of my third iteration. In this iteration, I placed Driver area and Detail area side by side, making the trip card clearer and shorter.

D Trip Card iteration3.png

2. Add a Ride Filter

Help users search for their rides effectively

Desktop Copy 8.png


Why people are finding certain rides?

To figure out the filter criteria, I needed to know why passengers are searching for their rides. Based on the user research, more than 30000 companies, including Lenovo, Huawei, and Alibaba,  remunerate their employees' commuting expenses using the Didi app. Amongst all rides, passengers need to select their commuting ones and invoice them by using Didi. People commute on workdays at the same time, and tend to use the same means of transportation. Therefore, by setting the criteria of date, time and service, the recoverable trips can be chosen easily. 


Ride Filter Design alternatives

Then I started creating wireframe of the ride filter and came up with two design alternatives:  

filter design alternatives.png

"Which one is better?" I had a really hard time trying to figure out that question. Then I decided to make two very quick prototypes by invision to ask users' opinions. (Since I didn't have much time to conduct strict user testing, I just asked several my colleagues who use didi to commute everyday to test the prototypes.) 


What I learned from usesrs?

  • The filters themselves are a type of content

Filter themselves communicate various attributes about rides to users. When a user is doing research,he/ she might not know what specs apply; the list of filters helps them understand what kinds of categories exist.

  • Most of the users are not going to apply all these three filters

The first version of design alternative looks like requiring users apply all these three filters at once. While for the second one, users clearly know they can just apply 1 or 2 filters which is a more common use case.


Date Filter Iteration

Through the design process, I had lots of opportunities to communicate with my mentor, user researchers, and product managers, from which I gained insights about business concerns, user demands and feasibility. I conducted multiple design pitches, compared and reflected to find a better one. Before I made any decisions, I would ask my mentor and other designers for their suggestions first, so that I could find weak points earlier.

The second version of design looks good. However, after presenting it in the design critique meeting, I realized it was too cumbersome. On the one hand, users need to scroll through four rollers to select the date period. On the other hand, the small screen resulted in considerable unintended operation.

date filter before.png

Ok so... What if?

How can I make the date filter more explicit and easy to use? What came to my mind was a calendar. What if I redesigned the date filter as a calendar? The calendar is a more familiar tool for users to check the date. In addition, users only need to click twice to choose the date period. It will be easier for users to understand and utilize the date filter.

date filter iteration.png

Final filter wireframe

filter wireframe.png

3. Invoicing Process Optimization

Easy Access to Invoice Your Rides

Desktop Copy 9.png


Problems & Solution

“I spend a lot of time trying to finding where to invoice my trips, and the invoicing process is so inconvenient! I have to search and invoice my trips one by one! ” Hearing these complaints pushed me to pay attention on the overall invoicing process.

I first built a diagram to help me understand the existing invoicing structure and to find out what was wrong with it.

The invoicing process is very long, and the the step from My Wallet to Invoice is somewhat unintuitive, which resulted in the confusion among users. How can I simplify the whole user flow? Provided that users were tend to select and invoice their commuting trips by using filter in Ride History part, I got that insight from user testing that conducted by the user research team, I believed that adding an Invoice function to Trip History is a good way to make the invoicing process easier and more explicit.

Then I must reorganize the structure:


The reorganized one was shorter than the previous one as the trip selection process was simplified. Moreover, by moving the Invoice function to Trip History, the redesigned user flow was more logical and user friendly. According to the feedbacks from passengers, they can find out where to invoice their trips now. Then based on the redesigned structure, I refined invoicing user flow.

user flow invoice.jpg

Main Walkthrough

D Invoicing Walk Through.png

The Whole wireframe

invoice wireframe.png

Download the PDF file HERE


1. Make decisions fast

Working in real product versus school project is very different. At a product company, your work will be nitpicked and you need to make your decisions fast. Since the process is long, the deadline is fixed and everybody is working together. 

2. Think about business goals and technical restrictions

Users first. It's true, but work in a real-world you need to find a balance between users, business goals and technical restrictions. There are many more aspects to consider and more stakeholders to take into consideration. I got to understand that only after I presented my work to design critiques where I got feedback from PMs and technical people. I feel that I still have a long way ahead to learn more about the knowledge in terms of business value as well as technical restrictions.

3. Convincing your team is a skill

I was asked to present my work almost every week. The art of convincing is important to learn. It's better if you have supportive user data, but if you don't, you'd better present all the alternatives and iterations that you have made. Lay out your preferred solution and tell them the reasons behind. So that you are prepared when someone asks "Have you tried...?".

4. Always open to getting feedback

Be comfortable with getting critique. Get over the feeling of making mistakes and being wrong. Learning from it is the fastest way to grow as a professional designer. If you don't get any, then reach out and ask the people around you to give you some. 

5. Concern: Clear-cut responsibilities, how to reach out to users?

During the design process, I worked mainly with Product Managers and User Researchers. I got to know about the demands and user research data from them. However, although the files could provide me with the main problems of users, they couldn't make me really understand what they felt and walk in their shoes, so I took more than 20 trips personally to talk with the real passengers. What's more, whenever I finished my iteration, I would prototype it and invite passengers to test it. I think highly of the users' responses instead of mine, because I always keep it in mind that I am designing for users.

However, the situation is that the division of  labour at company is increasingly clear and specific. As a UX designer, I had a little chance to get in touch with the real users. Even I had multiple sessions with user researchers, who conducted and analyzed  surveys, but was it really a good way for design? Maybe UX designers should spend more time talking with the real users instead of leaving these tasks only to user researchers and product managers.


Interning at Didi greatly developed my professional UX design skills and understanding. I treasured every working opportunities and took down working journey by Evernote everyday. In the journeys, I record my design thinkings and talked to myself about what I learned and what I could do better.