App Checkout redesign

product Design   |   UI redesign   |   optimization

Project overview

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:

Project Goal

Create a new UX/UI design for 3 screens:

1) A new app checkout one-pager, which should contain:

  • the choice of delivery or pick up, delivery address, and the option to choose a different address;
  • fast delivery (in 60 minutes) or the option to choose a specific date and time (timeslots);
  • payment options and the switch for the invoice;
  • the final price of the order.

2) The screen for choosing the address.

3) The screen while the payment is being made.

Four screenshots of the checkout, showcasing the order screen, delivery timeslots, delivery address options, and payment processing

Process step 1: Research

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

Initial design

A screenshot of the initial delivery timeslots design in the app checkout

The contrast of not available time fields & their text 4.48 : 1

The initial design contrast analysis with respect to Web Content Accessibility Guidelines. Analysis shows that the contrast of red and white colors of not available timeslot fields fails the WCAG AA standard for normal text

The contrast of available time fields & background 1.09:1

The initial design accessibility analysis shows that the extremely low contrast of available time fields & background fails the WCAG AA standard for graphical objects and user interface components

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.

step 2: analyzing the design & Task

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?

Visuals of the analyzing process together with short descriptions. Showcasing analyzing both versions of the initial user flow, the task, and the project constraints

Process step 3: Low Fidelity

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:

  • When buying food, it’s common to buy a lot of products. This means a higher probability for the user to remember forgotten items even at the last step of the buying process. Or the need to double-check if everything is there.
  • Adding cart editing to the checkout screen makes the user feel safer making changes to the cart at this step. That's because it doesn't require leaving the checkout and potentially losing already entered information. Even after filling in everything, the user can confidently move between the cart and the checkout. In the current design, moving between the cart and the checkout is more complicated and inconvenient for the user.
  • Among the users, there are people distracted by various circumstances (parents of young children, people on public transport, etc.). The easier everything is to find and navigate - the faster such users will be able to shop. Cart editing/viewing at your fingertips greatly simplifies the shopping process for such users.

Of course, the design decisions would require testing.

The first option of a low-fidelity checkout one-pager. It showcases the order summary consisting of delivery/pick-up, delivery time, payment method, cart (with a preview of the items and edit button), and price details
The second option of a low-fidelity checkout one-pager. It showcases the order summary consisting of a cart (without a preview of the items, just a view/edit button), delivery/pick-up, delivery time, payment method, and price details
High-fidelity screenshot of the new checkout one-pager design
High-fidelity screenshot of the new delivery timeslots design

Design decisions: checkout

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.

Design decisions: Address

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.

Before

After

Screenshot of the initial delivery address selection design
High-fidelity screenshot of the new delivery address selection design

Before

After

Screenshot of the initial payment processing design with a grey loading circle
High-fidelity screenshot of the new payment processing design with a brand’s bus animation

Design decisions: payment processing

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.

Four screenshots of the checkout. The first two screens show an initial design of delivery timeslots and payment methods (the “Before” version), and the second two screens show the new design (the “After” version)

The result: prototype

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

The final design of the checkout one-pager with numbered interactions that are enabled in the prototype