Amazon is launching the next line of products for its Build It crowdfunding platform. The company has collaborated with fashion designer Diane von Furstenberg on a range of Echo Dot smart speakers that’ll only go on sale if enough people pre-order them within 30 days.
Two thoughts. First, I wasn’t aware that Amazon had launched its own crowdfunding platform. Here’s more about Build It, “a new Amazon program [that] lets you weigh in on which devices we build next”:
Many SaaS (software as a service) companies make a distinction between their “product” websites and their “marketing” websites. The former refers to the service itself, the tool or application that customers use. The latter refers to the site where customers learn about the service before they sign up. Although the audience for both is often the same, product and marketing sites serve different purposes. As a result, it’s not unusual for these sites to have different navigation structures. Few companies illustrate this distinction as well as Mailchimp.
Let’s start by looking at Mailchimp’s marketing website. Here’s the site’s primary navigation bar:
Clicking (or tapping) on any one of these top-level navigation elements (except Pricing) reveals vertical menus, which swipe in from the left edge of the screen:
Selecting one of these menu items reveals a second level of menus:
These are the mechanics of navigating Mailchimp’s marketing site. Let’s also look at how the site is structured — the main distinctions it asks users to understand:
Products: the company’s offerings, framed in terms of the value they provide to users (“We’ll help you…”) and features of the Mailchimp platform.
Resources: content meant to help users get started or become productive with Mailchimp, including documentation, examples, access to relevant third parties, etc.
Inspiration: ancillary content such as podcasts, blogs, videos, workshops, etc.
Pricing: leads to a page that does more than explaining mere pricing: it also lays out the company’s business proposition in terms users can understand (and that hopefully relate to their needs.)
There are three other elements in the site’s primary navigation bar: the company’s logo, search button, and the “user” menu. (If users are logged in; if they aren’t, they’re shown buttons for logging in and signing up instead.) The logged-in user menu isn’t revealed with the left-to-right swipe of the main navigation elements, but is instead presented in a more traditional dropdown menu:
This marketing navigation system is standard fare; I’m sure you’ve seen lots of site structures like this one. Mailchimp’s product navigation, on the other hand, is unique — and very different from the one in the company’s marketing site. Here’s what you see after you click on that View Dashboard button:
The first thing to note is that the navigation bar is no longer laid out horizontally across the top. Instead, we’re shown a tall and narrow vertical bar aligned with the page’s left edge. A thin vertical yellow bar draws our attention to this navigation bar.
This navigation bar starts with the Mailchimp logo. Unlike the logo in the marketing navigation bar, this instance doesn’t include the Mailchimp wordmark. In fact, none of the items in this navigation bar have obviously visible labels. Hovering the pointer over the icons reveals what they are:
This mechanism is essential because most of the icons in the product navigation bar are somewhat obscure.
(Perceptive readers may have noticed I’ve been sharing screenshots from my iPad in this post. I’m using an Apple Magic Keyboard with my iPad Pro, which includes a trackpad that makes mobile Safari behave more like a desktop browser. For touch-only interactions, the labels appear on the first tap and the menu appears on the second tap. This additional interaction adds a bit of friction to the experience on large-screened mobile devices. In devices with smaller screens, Mailchimp’s product navigation structure collapses to a hamburger menu that shows labels next to the icons by default.)
These are the labels for each icon in Mailchimp’s product navigation bar:
Look again at the screenshot above. Do these labels come to mind when you look at those icons?
As with the marketing navigation system, clicking (or tapping) on each icon reveals a vertical menu:
Helpfully, these menus start with the icon’s label. The options in these menus are all “places” within the product. But unlike the marketing site, people don’t visit these places to learn about the system but to do things: create a survey, write an email, configure steps in a customer journey, etc.
Still, being able to use any system effectively requires that the user form an accurate mental model of what each option does and how it works. Navigation isn’t just a means for moving around; it also helps users grok the main elements of the system, how they relate to each other, and how these relationships can help users get things done.
While these elements may be labeled using ordinary words, the words carry particular meanings in this context. As such, these distinctions aren’t as obvious as the ones in the marketing site. Revisit the list I transcribed above. Do you have a sense for what they do just from looking at the list?
To wit, “audience” and “campaign” are central elements of Mailchimp’s platform, and they have particular meanings in the system. Users can’t effectively work with this system if they don’t understand these meanings. These concepts become clearer as users move around in the system, getting a sense for the distinctions-within-distinctions that characterize multi-level navigation structures like this one.
I suspect the absence of recognizable icons and visible labels in the first level of Mailchimp’s product navigation structure slows down this learning process. The first time users see this navigation structure, they must hover over all the icons and hold their names in short-term memory to get a sense of the whole.
After a while of using the system, even the most obscure icons acquire meaning in the user’s mind. For example, after several months, I’ve come to associate the third icon in Mailchimp’s product navigation with “audience” and the fourth (the megaphone) with “campaigns” — the two parts of the system I use most. However, I still don’t remember what some others do. I explored these other parts of the system while preparing to write this post and found useful features that I can use for my business. I wonder if I’d discovered them sooner had they been labeled more clearly.
It’s worth noting that unclear labeling isn’t a problem with the marketing site; its primary navigation labels and their underlying menus go to great lengths (and a relatively large amount of screen real estate) to explain themselves to the user. This effort is understandable: visitors to the marketing site are fickle; they must understand the main points as quickly as possible. You can’t assume visitors to the marketing site will stick around to expend time and energy learning the system.
On the flip side, users of the product already expect a learning curve. They want to get things done, and once they’ve learned the system’s conceptual model, navigation shouldn’t be in the way. So, the tradeoff is between a more obtrusive and somewhat redundant navigation system and one that aims to occupy as little space as possible and stay out of the way until the user needs it.
Apart from aesthetic considerations — i.e., color and font choices — Mailchimp’s marketing and product sites are very different from each other. They only share two navigation elements in common: the company logo, which in both cases leads to each system’s version of “home,” and search, which presents different interfaces on either site. Everything else — including, as I’ve pointed out, the navigation bar’s position and orientation on the screen — feels very different.
These differences may be appropriate, given that both sites serve different purposes and create very different contexts. However, given my challenges with using the product site, I wonder if they may be too different. Perhaps clearer labeling (as evidenced in the marketing site) would make the product site easier to use. In any case, the sharp contrast between these two navigation systems makes for an interesting case to study.
It’s challenging enough for a product’s conceptual models to be internally coherent. But it’s even more challenging to maintain coherence within a family of products. One of my favorite examples is Amazon’s Kindle.
The Kindle product family started with a dedicated e-reader device in 2007. Over the years, the line has grown to include several devices with different capabilities, ranging from relatively simple readers with e-ink screens to fully-featured tablets. Besides dedicated devices, Kindle also encompasses apps that run on other hardware platforms, such as Android phones, iPads, and personal computers running Windows and macOS.
This widespread availability is one of the system’s most attractive features. It means you can read your e-books on your preferred device. Alas, this variety also presents design challenges. These devices don’t have the same features and capabilities. Some have touchscreens, while others use a mouse or trackpad. Some have larger screens than others. Some have color displays, while others are monochromatic. And so on.
Also, even though they’re all labeled “Kindle,” not all Kindle products have the same capabilities. Dedicated Kindle e-ink readers (such as the Kindle Oasis) are optimized for reading books. The Kindle apps on other platforms, such as Windows and iOS, are also optimized for reading books, but run in the context of a third party’s operating system. In some of these platforms you can peruse and buy from the Kindle bookstore, while you can’t do so in others. As a result, Kindle’s user interface is different on each platform.
That said, all of these products must provide a basic set of functions for users to experience them as “Kindles.” That set includes, at a minimum, giving users access to their book library. They must be able to open a book and read it. They must be able to move around in the book, including navigating its table of contents. They must be able to search in the contents of the book. They must be able to highlight key passages and leave notes in the book. Those changes — especially users’ highlights and notes and their reading location in the book — must synch with other instances of Kindle. I don’t think you can call a product — be it software or a dedicated device — “Kindle” if it doesn’t provide these basic features.
It’s not necessary that the UI that provides access to these features be identical in each platform, as mentioned above. However, ideally, the underlying structural relationships would be maintained throughout all instances. For example, I expect the features that allow me to navigate within books — e.g., the table of contents, jumping to a particular page, synching to the furthest location read — to be grouped together. I also expect that these features would only be available in the context of reading a book. (As opposed to the level of the library of books.)
In fact, this is how these features are grouped in the iOS and iPadOS Kindle apps.
The Windows and macOS versions of the Kindle app (which are very similar from a structural perspective) feature a dedicated “Go To” menu. The “sync to furthest page” feature has a dedicated button, and it’s located next to the “Go to” menu.
However, the “Sync to Furthest Page Read” feature is in a different location in the dedicated Kindle e-ink readers. Instead of being grouped with the book-content navigation features, in these devices, “Sync to Furthest Page Read” is in a generic menu alongside seemingly unrelated features such as “About the author” and “Share.” This menu — which is signified with a vertical ellipsis — is also present at the library level, where it shows a different set of options. Note that the e-ink Kindle devices also have a dedicated “Go To” menu, which lists the book’s table of contents and user notes, but “Sync to Furthest Page Read” isn’t close to this menu.
So, three different platforms that share the same feature set but present it within very different structures. I’ve chosen to focus on “Sync to Furthest Page Read” because this feature is especially useful for people such as myself who use Kindle in more than one device. If there is one feature that should be located consistently between platforms, this is it. I’ve used Kindles concurrently in multiple devices for many years, and I still make the frustrating mistake of looking for “Sync to Furthest Page” read in the “Go To” menu on my Kindle Oasis. There’s a lot to be said for maintaining structural coherence across a family of products.