Amazon Checkout Redesign Exercise —Part I: Navigation
Please, note: this is an exercise. Its purpose is not to create business solutions, but to practice creating them in a simulated environment. The power of guessing is applied to form business goals and metrics.
You will find links to the prototypes and other parts of the exercise (once they are published) at the end of this article.
The Goal
Amazon is doing a great job processing millions of orders per day, but there’s always some room for improvement: higher customer satisfaction rates, successful up-selling, conversions to paid subscriptions, etc.
In this exercise, we will try to break the checkout process into smaller experiences, and see if we can improve them one by one, starting with navigation.
The Given
Checkout at Amazon is a multi-step process. Here’s what an unregistered user goes through to place an order:
Despite knowing none of the actual performance indicators for this workflow, we can spot the most obvious issue here — UI seems to lack consistency:
- Most screens have unique layout and styling, so you’ll have to study every screen before you can start interacting with it confidently.
- Screens have different context: Shopping Cart (1) view is part of the general UI, but the rest of the screens are treated with special header, representing steps to complete.
- Navigating through the checkout process is a one way road: you can’t go back to previous steps most of the time. Header indicates your progress, but it doesn’t do the job well: you are stuck in Shipping and Payment for three different screens (3–5), then Gift Options are just skipped in most use cases.
The checkout process is complex (for a reason) with many more UX problems, and I recommend you go through it yourself and watch others do it. Experiencing the solution is worth a thousand images.
For now, our task is to improve navigation, and it’s time for some pencil work.
Sketching
Doodling is a great tool for UI design exploration. Similarly to brainstorming, you trade quality and details for freedom and speed of generating solutions. And if you ask me, freedom along with speed are what matters most for the first iteration.
A couple of hours later, myriads of ideas boil down to either of the two approaches in navigation:
First one is checkout-centric. It means we basically start with what currently is the last screen of the checkout process: Summary. In order to edit the information, a user has to open the respective views (like shipping and payment).
Second one is step-based. It’s very similar to the current design Amazon has, but with some exceptions: shopping cart is part of the overall checkout workflow, and we also want to allow users to freely navigate around the steps of the process.
Now that we have sketches for two starting points, we can go to the next level of design exploration. No, not mockups, of course.
Prototyping
Instead of drawing mockups in Sketch or Figma just to add a little more detail to our hand-drawn doodles, we’ll use vue.js to start creating actionable designs right away.
The prototypes will have the Prototype Manager built-in to quickly switch between versions we implement and iterations we go through:
Checkout-centric design
The idea here is to make final Checkout page a starting point, and make all other (editable) views its children:
Showing Shopping Cart as a part of the complex screen isn’t a good idea for those who just want to see what’s in there, or maybe remove some items. So it makes sense to set editable Shopping Cart screen as an entry point for the process, even though it’s not the main view.
Some coding hours later we have a prototype simulating the steps for first-time users to go through with this navigation architecture:
Initial testing and observations reveal some good things about this approach:
- The main flow for a first-time user is the same as for a registered one: Shopping Cart — Checkout (— optionally Edit Shipping / Payment Info). This pattern is simple, compared to step-based navigation, that tends to silently skip some steps under particular circumstances.
- At any given moment, it’s easy to tell where exactly you are in the process, how you got there and where the buttons will take you. This comfort is achieved by eliminating all mysterious Continue and Proceed buttons, which itself is a result of moving away from the linear step-by-step process. Here users have to consciously choose to go to every screen by pressing the corresponding button.
Bad things about this approach reveal themselves quickly too:
- You have to choose to enter the missing information yourself. Unlike in the steps-based design, which shows you all required forms one by one before it allows you to proceed, here you need to press Edit for all missing pieces.
- The busiest screen is shown right from the start. There’s no getting away from the Summary view that has to display all the information to make you feel comfortable clicking Place Order. But having it as the home of the process may overwhelm the user.
Here you can test the prototype yourself: Prototype A.1. Don’t bother entering some data in Shipping and Payment—just pressing “Save” will do the trick for now.
Step-based design
This architecture is very similar to navigating with tabs, but instead of tabs we have steps, and most of them reveal forms you need to fill in to proceed. This pattern should look familiar to anyone who was lucky enough to install software packaged with Installation Wizard.
During first iterations of the prototyping process, it becomes obvious that table of contents can also serve as navigation and information summary. So why not give it a try:
Good things we find here:
- The process is clearly progressive: one screen at a time, followed immediately by another. You only see one action button at a time, so it’s unlikely that you will ever wonder what to do next.
- We were able to turn the table of contents into an even more useful part of the UI that now also serves for navigation and order summary. Showing users the results of their efforts usually improves the overall understanding of the process.
Bad things about this approach:
- The flow varies for different use cases. First-time users go through all the steps, while the registered users will be taken to the last step. And a lot of people will probably experience both cases.
- Registered users are starting out with a pretty busy screen, just like in our first approach. Though in this case it’s almost inevitable since there is no information to fill in, which means no steps to show.
Here you can try the prototype yourself: Prototype A.2
Conclusion
There’s no clear winner between the two approaches since both have their unique strengths and weaknesses. Many fixes will come in later iterations. There’s definitely more user testing to do, but that also comes later. Navigation is just one bit of the bigger experience, which should be the real subject to testing.
Meanwhile, you can find both prototypes here:
Go ahead and give prototypes a try (don’t forget to switch between them using Prototype Manager’s menu at the bottom right), and hit me up with your suggestions and ideas on Twitter.
Don’t forget to subscribe and I’ll see you in Part II: Shopping Cart Redesign.
