The company wanted to optimize & redesign the checkout in their app.
Initially, the company’s checkout was made of 3 main screens - cart, time reservation, and payment. However, 21% of users reserve time and only then add items to the cart and go to the checkout.
The company decided to optimize the checkout, by reducing the current 3-screen checkout to 2 screens. The new checkout has to be made of the cart (which should stay the same) and the checkout itself (with time reservation & payment).
Also, the company wanted to create a new UI design that would be different, while still keeping the colors from their current design system.
If you're in a hurry - you can see the final result here:
Create a new UX/UI design for 3 screens:
1) A new app checkout one-pager, which should contain:
2) The screen for choosing the address.
3) The screen while the payment is being made.
This time I only needed to ask the right questions to find out about the user pain points because the team has already done the research.
One of the issues revealed in research that I had to address was that users tend to try tapping on already taken times trying to reserve them. This is most likely due to the initial design showing unavailable times in the same color as CTA (call-to-action) buttons.
Even though the red color usually instinctively indicates unavailability, in this case (due to the brand colors used throughout the design) users get accustomed that the red color is actually what they need to tap, not avoid.
Also, in the initial design due to the colors unavailable times are emphasized way more than the available ones (available ones do not even pass WCAG AA requirement for graphical objects where the bar is really low - you may only use such low contrast for elements you want users to NOT notice, not the important clickable ones). This may lead to the tendency of users to tap the unavailable times (especially users who are distracted by circumstances or have a situational impairment (lower contrast of white on the red does not help here either, especially with a small light font) and may not concentrate as much to what’s written on the timeslot).
This kind of pain point (users tapping on already taken times) can be quite easily spotted using usability studies (moderated or unmoderated).
If a company uses analytical tools like, for example, Smartlook - it’s even easier. Of course to find these types of usability issues you have to know how to use tools like that to get the most value. I worked for a company that had this tool but only used it partially, mostly for quantitative data.
Even though quantitative data is very beneficial, there are things that qualitative research helps to grasp better. In this case, you can use quantitative data to logically pinpoint the users that will give the most valuable insights in qualitative research.
You can’t possibly research all your users and you don’t have to. You can look into locations that most users are in, devices that are mostly used (in this case - phones, of course), and recorded session times (you won’t get as much valuable data from a few less-than-minute-long screen recordings as from the ones that are longer). Also in this case, of course, you only need users who went through to the checkout, since that’s the area of the app we’re trying to improve.
When you find the best users for qualitative research, you start analyzing. Not just looking into recordings, but truly analyzing, gathering, and systemizing the data. How many users struggled to select the available time? What are the other problems in the checkout and how common are they?
Pareto Principle (80/20 Rule) usually applies here quite well. In the beginning, you’ll find a lot of new insights which will soon start revealing tendencies. You’ll have plenty of valuable data, together with pain points and usability issues to guide you to the design solutions.
I managed to get a lot of valuable research insights this way for another project in a short time. It was quick, painless, and didn’t cost the company anything extra - I only used the tools they already had.
I started the process with the analysis of a current design. I separated 2 versions of the same user flow:
1. User flow, when the user fills the cart, then goes to the checkout and makes a reservation there. This is what the majority of users do, so I started exactly with such a user's path - I made it as detailed as possible, with all screens and their different variations.
2. User flow, when the time is reserved first, then the cart is filled, and then the user goes to the checkout (user flow of 21% of users). Since it has many similarities with the first user flow, I paid more attention to the differences between these user flow versions.
After getting familiar with the current user flows, I moved on to clarify what is expected in this project. The essential question was: what are we trying to achieve with this design change?
I started creating the design with low-fi prototypes for the most important screen of the task - the checkout one-pager. In the prototype, I planned everything that was asked in the project. I also considered adding a cart editing feature. I considered this possibility for several reasons:
Of course, the design decisions would require testing.
In order to focus the user's attention on the checkout and ensure the ability to go through it as quickly and simply as possible, only essential elements are left on the screen. It is still possible to change the delivery/pick-up method and time, and view the price details without leaving this screen.
The second screen shows what happens when the user taps "EDIT” next to the reserved time - the timeslots are displayed.
Since the design principle of timeslots itself seems quite convenient and clear, I did not change the essence of the design here. BUT I did change the colors to address the problem of users tapping the taken times.
In the new design, the unavailable times remain visible only for clarity of the structure but do not look like active buttons - more like non-clickable elements. Available times in this case are much brighter, the green color identifies availability.
Testing would show if this would solve the problem.
The user input should be minimized as well. Nothing new, but it's worth noting because there are still other screens where the information input could be reduced and simplified.
1. Since the aim is to have a modern minimalistic design - I eliminated all unnecessary UI design elements and also limited the number of colors. The new design of the address selection screen maintains the same style as the checkout one-pager screen.
2. I chose red as the main color of the design because it is the most associated with the brand for consumers.
3. I chose a darker shade of red from the design system, as it better meets the standards of contrast accessibility. It also goes well with the modern minimalistic design.
4. I also added the option to adjust existing addresses (not only to add new ones). If the user would like to change only certain information (for example, only the phone number), this is a faster way than entering it as a new address or going to the profile (leaving the checkout ) and changing the address there.
Not all users see this screen, but it is important when a payment is taking longer or there are problems with the payment.
In this case, it is useful to give the user something to focus on (not only the malfunctions and the wait itself) and possibly reduce negative emotions by at least a little. For this, I created a waiting progress animation in Figma, using the well-known "Barbora" delivery bus.
If a technical problem occurs during the payment process, the necessary information and help for the user should also appear on this screen.
Remember that not all the elements are activated to make it easier to focus only on what the project addressed. In the prototype, you can:
1. Enter the screen where you can change the address;
2. See the time slots (without changing the selected time itself, because then notifications about changes and other additional elements would be needed);
3. Choose whether you need the invoice;
4. View the price details;
5. And the fun part - view the animation of the bus by clicking "PAY".