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:

Prototype Manager

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.