Redesign the ride history section and optimize the invoicing experience

Didi App Screenshots from   App Store

Didi App Screenshots from App Store

Project Info  12-week Individual Internship project@ Didi

My Role   UX design intern on the platform UX team




Last year, I interned at DiDi as a UX designer for 6-month. DiDi serves for almost two hundred million users around China, committing to building an intelligent ride-sharing platform. It allows consumers to request a trip and then be picked up by DiDi drivers.

Fortunately, during this time, Didi was merging with Uber China, so I had a chance to participate in the design process of 5.0 new version . 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 designer and learned a lot about how to collaborate as a team.

The 5.0 version of the app launched in winter of last year.


Brand and Design Principles


The DiDi's Rider app — designed in 2014, struggled to scale alongside the hyper-growth of the complex service types and the company itself. As anyone whose ever used DiDi app knows... It is complex. It has five services within the app (express, premier, Luxe, taxi, and carpool) and disparate features of each 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 guideline.png

Since we were asked to deliver final design mocks within six 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 the first 8 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 two weeks 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 the most important: “What does Ride History mean to you?”  

Combining my personal research findings with the existing user research data, I realized that for designing the ride history part, I should focus on the daily commuters and the casual users. After discussed with the product manager, Mingyu, and the design team, we identified several behavioral variables to create the primary personas below:

*Only the primary personas showed here

*Only the primary personas showed here

persona_casual users.png

I used the personas constantly throughout the project to guide my design decisions, prioritize design tasks, and develop a clear picture of who the design of the ‘My Trips’ (Ride History) section would target in different phases.

previous design.png

What should be improved?

After building my basic understanding about the travel process and figured out our primary users, I communicated with the team to figure out the problems that needed to be improved within the passengers' Ride History. Although the interface offered a easy way to browse all the past rides in one section, if you start thinking about it in specific user groups and real use contexts, there are some inherent problems: 

early insight 2.png


Set design metrics

How to define a success of my design?


The invoicing issues we found felt like focus a lot just on the daily 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 more users? How can I find a balance between different user groups? 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 the daily commuters.

Then I decided to define the success and understand user context at scale before I jumping into designing. I partnered with the PM to unpack the concept of the perfect Ride History section and used this framework to investigate the success metrics:

success metrics.png

1. Redesign the ride card

A ride card that users could read


How might we create a simple up-front impression that didn't overwhelm with information and interactions that only occasionally needed? The general idea was to restructured the ride card with the most important information up front and detailed information secondary. That way, directly presenting the information that people have deeper memory and used most to recognize a ride, while proving access to more secondary detailed information seems like a good idea.


How to get there

What information do users care about?

Before I jumping 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 aspect 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 ride?" I developed a user journey with a typical use case and listed all the key information in each step to help me gain a better understanding:

journey map.png

Outside of the app context helped me understand how the problem should be approached. Out of this, three categories of key information appeared above: driver, route, and time. However, considering the complexity of DiDi's services and the business need of leveraging timely-payment rate, the service and money information are also included. Then I divided them into 3 sections below:

Key information

Key information


And I started crafting

Now I had a general idea for what information I wanted to emphasize on the card, but I didn’t have a clear picture about how to integrate them together. To get rid of the overwhelming presentation of all types of information and let users focus on the most important ones, I categorized all types of information into 3 sections: ride information, order information, and the quick payment button

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

Trip Card B:A.png

Compared to the old design, I added driver information, service type, and cost to complete the trip information and made each ride more recognizable. As for the payment button, it would only show up when the payment doesn’t complete.


Wait...The card is too large

card comparision.png

However, the redesigned card was much larger than the old one which means that users have to continue sliding to look through all their recent rides. It inadvertently increase the time it took a user to find a ride. How can I reorganize the content and shorten the card's height?


Curating focus on the card

I made my first attempt by trying to put the pickup time in the card title. I arranged it for a change since the card order already tells time information to some extent. However, when both the date and service character lengths are too long, the card runs out of space. So I reorganized the information in a different way, which led to the birth of my third iteration. In this one, I highlighted driver information as it was the most vital information that passengers would use for trip searching and identification. Also, by putting driver area and detail area side by side, I make the trip card clearer and shorter.


Simplify browsing experience

simplify surfaces.png

Come back to the goal that we wanted to help users locate the rides by browsing timely organized cards, the way we were showing the cards was inefficient. By structuring the sections in a vertical stack, the most used section (completed) was sometimes pushed off the screen by the ‘Upcoming’ section. Also in that way we had increased the time it took a user to find a past ride. Therefore, we made a change by defaulting the ‘My Trips’ page to a full list of completed rides while the upcoming rides can be accessed via tabs. Now, the riders have more control to focus on the rides they care most about.


2. Improve the efficiency of picking rides

Pick the business rides smartly

How to get there

Ride invoicing means different things to different companies

Soon after starting optimizing the invoicing experience, I saw different companies have different invoicing solutions. For example, a startup might require employees to request ride invoice by themselves in DiDi app*, a larger company may set up accounts in DiDi Enterprise for employees and pay for the rides directly, and giant companies with mature invoice system could use DiDi API and reimburse employee’s business ride in their internal tools. Our business goal is to let more users transfer to DiDi Enterprise as it’s more powerful and easy to control. However, we still need to provide a good-to-go experience for employees and individuals who’re working for small companies and organizations.

*Small companies and some organizations require employees to request ride invoice by themselves

*Small companies and some organizations require employees to request ride invoice by themselves

Also, we realized that for this user group, the user needs vary a lot. Different companies pay for the rides in different situations (business travel, calling for clients, overtime work, daily commute, to or from airports, special request, etc). Some companies only pay for the business travel, visitor trips, and airport commutes; while other companies may also pay for the rides in the late night or daily commutes. That means users need to pick the business rides based on their own rules.

So here comes the challenge:


Ideating from users

What does ride history mean to users?

From talking to the users, one of them mentioned a very interesting metaphor: “When it comes to Ride History, I imagine a desk drawer in which contains all of my past rides, just like files. Also the future rides. They are organized by time. Whenever I need to find a ride, I rummaged through the drawer.” I used this metaphor to help me through the ideation process.


So, how can I help users find a ride?

At first, I thought users had difficulty finding their business rides only because of the lack of information on the ride card. However, after testing the new ride cards, we found out that users had difficulty because they had no control of separating the business rides from others. Finding a ride not only depends on the amount of the information we provided, but also on the organization of the rides.

After gathering all the insights from research and team meetings, I came up with four directions based on the desk drawer metaphor:

Artboard 1 copy0.png

Based on those four directions, I then came back to the user journey again to see how could I apply the drawer concept in each step to possibly help users ‘Mark the card’, ‘Divide the drawer’, ‘Get a new drawer’ or ‘Pick cards smartly’ in the app context. Then, 8 ideas were generated below:


I did different variations, trying to jump out of the box with business goals as well as a balanced user experience in my mind, and finally narrowed down to 3 realistic concepts:

Concept 1

Mark the business rides

Pick Business Ride Alternative 1.gif
pick ride flow 1.png

Concept 2

Filter the business rides

Pick Business Ride 2.gif
pick ride flow 2.png

Concept 3

Mark + Filter the business rides

Pick Business Ride3.gif
pick ride flow 3.png

Chosen idea

Prioritize high-frequency scenarios while enabling flexibility

As it stated in the challenge earlier, the goal of these design concepts were to enable users to pick their business rides smartly while not complicating the whole user experience. I assumed that flexibility was the key to meet more use scenarios - as different companies and different employees have different invoice requirements. After testing the concepts and several iterations, what we observed repeatedly were:

  1. Riders didn’t know whether a ride can be invoiced before requesting. Sometimes, an approval from the supervisor is needed.

  2. Riders expected that the app knew which rides were business ones so they didn’t need to actively search to pick.

  3. Each rider only issues invoice for a couple types of business rides. Among the 6 scenarios, daily commute and overtime work are more frequent.

Finally, among 3 concepts, we decided to proceed with the last one. The reasons were:

  1. Provide most flexibility for riders to pick rides based on their own rules while simplified the searching experience by prioritizing.

  2. Better balance the experience between daily commuters and casual users from before-ride stage to after-ride stage.

  3. Adapt when riders don’t know whether a ride can be invoiced. Plus, forgive users when they forget to mark.

  4. Doesn’t overlap with DiDi Enterprise; thus, has a potential to convert advanced users into DiDi Enterprise.


User Flows

chosen idea flow 1.png
chosen idea flow 2.png

Expose the ride filter

Design for rapid work

Making out an invoice is a tedious process that users are asked to do by their companies. People do want to get their money back, but quicker and easier. How might we make the ride picking experience more productive when requesting invoice?

Instead of jumping directly into crafting alternatives, I stopped for a while to think about what it’s like to work on my mobile phone. One thing I realized was I hate navigating across multiple screens. Often times, moving between screens fragmentize my attention and makes me lost in the context. With the aim to enhance efficiency and help users get their work done rapidly on mobile devices, I explored several iterations:

Among the three iterations above, we finally decided to go with with the last one in which I exposed the entry-point of each filter. We made this decision not only because it decreased the taps it takes to apply filters and show more context behind, but also because:

1. The filters themselves are a type of content

The filters communicate various attributes about the rides to users. When picking business rides, users may don’t know what specs they could apply. By elevating the filter entry-point higher in the stack, we revealed the information to help users understand what categories exist here.

2. Users rarely apply all three filters at once

From the previous concept testing, we realized that many users assume that the first design iteration requires them to apply all the three filters to get a search result. However, often times, applying 1 or 2 filters was enough. In the 3rd iteration, by exposing all three filters in the tab, we helped users to clearly understand that they can just apply the filters they need (or not apply).


Iterate on date filter

Fostering familiarity

Through the design process, I had lots of opportunities to get feedback not only from the design team but also from the engineers. At first, I designed the date filter by using the existing pattern to keep consistency and lighten implementation workload. However, after getting feedback on the technical feasibilities, I realized that the roller filter failed to enable across-year date selection. The backend logic couldn’t identify whether its a wrong input. Plus, scrolling through four rollers by using chubby thumbs on such a small screen was nothing related to effortless.

date filter iteration.png

To solve the problem, what came to my mind first was the calendar. It perfectly solved the problem of cross-year date selection and enabled users to only click twice to select a date period. More importantly, by utilizing a pattern that shared by both physical and digital worlds, we’ve fostered a more familiar experience. Users can pick the date without having to learn a new UI.


The Final Design

DiDi Prototype.gif

The Whole wireframe

whole flow 1.png
whole flow 2.png
whole flow 3.png


Interning at Didi greatly developed my professional UX design skills and mindsets. I treasured every working opportunities and took down working diary everyday. In the diary, I recorded my design thinkings and talked to myself about what I learned and what I could do better.

IMG_5908 2.JPG

1. Balance the business goals and the 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.

2. 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...?".

3. 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. 

4. 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 was 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 researches, 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.