What

The first screen presents actionable information without requiring any input or action from the user. The app makes assumptions about any settings or queries (such as location or time) related to its primary function, and presents the output for immediate response. Making assumptions about what the user is most likely to do also drives what appears on launch.

Use when

Your mobile app generates value by doing one thing really well, or is used or known for one primary thing.

Why

Starting the user with an immediately actionable mode, choice, or screen provides instant value to the user, and gets them engaged instantly. There is limited ability to enter search or any kind of choice or configuration, but there is useful information available from the device and the primary use cases to make this assumption highly likely to be valuable, even expected.

How

Use live data from the user’s mobile device (assuming the user has given permission in the settings). Primarily, look at location and time to generate a meaningful landing screen for the user. Make assumptions about what the user is most likely to be doing with your app, and get them as close to completing the action as possible, with a minimum of input.

Examples

All of these examples are mobile but could be valuable in desktop settings. In the first example, Snap (Figure 2-12, left) lives up to its brand as a photo-centric social media and camera company. When the app is launched, the user-facing camera is automatically turned on, ready to take a selfie. The next three examples all show how the apps use location and time data to return meaningful results with no input from the customer. INRIX ParkMe (Figure 2-12, right), Eventbrite and Weatherbug (Figure 2-13) give useful results this way. ParkMe makes some smart prefill assumptions (park for one hour) to gather price results by default.

Figure 2-12. Snap and INRIX ParkMe start screens

Figure 2-13. Eventbrite and Weatherbug start screens

What

A dashboard is often the first screen a customer will see when logging in to a consumer or business platform. They are a very common pattern for business information software. Dashboards display key data points in a single information-dense page, updated regularly. They show users relevant, actionable information, charts and graphs, and important messages and links or buttons, often related to key metrics or workflows that are important to the business.

Dashboards are very popular because they solve the need to get a quick update on status, on key information, and on tasks to be done. Your site or application deals with an incoming flow of information from something—web server data, social chatter, news, airline flights, business intelligence information, or financials, for example. Your users would benefit from continuous monitoring of that information.

Why

This is a familiar and recognizable page style. Dashboards have a long history, both online and in the physical world, and people have well-established expectations about how they work: they show useful information, they update themselves, they usually use graphics to display data, and so on.

A dashboard uses many interlocking patterns and components. Many online dashboards use a collection of these patterns found elsewhere in this book:

• Titled Sections

• Tabs and Collapsible Panels

• Movable Panels

• One-Window Drilldown

• Lists and tables of various kinds (Chapter 7)

• Information graphics (Chapter 9)

• Datatips

Examples

Salesforce (Figure 2-34) has built a huge software business around answering the need for enterprises large and small to monitor and manage all forms of business processes. Custom-built and customizable dashboards are a central part of this strategy. Some examples of purpose-built dashboards are shown here. Users can build or configure modules according to their needs, and then arrange the standard-sized modules into a grid that suits them best. These can be saved and shared.

Figure 2-34. Salesforce Dashboards

SpaceIQ (Figure 2-35) offers a dashboard on login. This startup follows a classic design pattern of offering key performance indicators, an overview of what is happening now or needs attention, and quick navigation to other key parts of the platform.

Figure 2-35. SpaceIQ

Finally, you might be interested in Stephen Few’s book on information dashboards, Information Dashboard Design: Displaying Data for At-a-Glance Monitoring (Analytics Press, 2013).

What

An application structure defined by a central workspace with containers of tools around it. It consists of a large blank area, or canvas, where a user creates or edits a digital object. Arranged around this open area, at the sides or top or bottom, are grids of tools, called palettes. The tools are represented as icons. The user clicks the palette buttons to create objects on the canvas, or to select a tool to modify objects. The overall effect is a digital workbench or virtual artist’s easel. The user selects one tool after another to use on the main object.

Use when

You’re designing any kind of graphical editor. A typical use case involves creating new objects and arranging them on some virtual space.

Why

This pair of panels—a palette with which to create things, and a canvas on which to put them—is so common that almost every user of desktop software has seen it. It’s a natural mapping from familiar physical objects to the virtual on-screen world. And the palette takes advantage of visual recognition: the most common icons (paintbrush, hand, magnifying glass, etc.) are reused over and over again in different applications, with the same meaning each time.

How

Present a large empty area to the user as a canvas. It might be in its own window, as in Photoshop (Figure 2-18), or embedded in a single page with other tools. The user just needs to see the canvas side by side with the palette. Place additional tools—property panels, color swatches, and so on—to the right or bottom of the canvas, in small palette-like windows or panels.

The palette itself should be a grid of iconic buttons. They can have text in them if the icons are too cryptic; some GUI-builder palettes list the names of GUI components alongside their icons, for instance.

Place the palette to the left or top of the canvas. It can be divided into subgroups, and you might want to use Module Tabs or Collapsible Panels to present those subgroups.

Most palette buttons should create the pictured object on the canvas. But many builders have successfully integrated other things such as zoom mode and lassoing into the palette.

The gestures used to create items on a palette vary from one application to another. Some use drag-and-drop only; some use a single click on the palette and a single click on the canvas; and some use pressure-sensitive tools, such as a digital pen or simply varying your finger pressure on a touch-sensitive screen and other carefully designed gestures. Usability testing in this area is particularly important because the behaviors of the tools might not be obvious or might be difficult to learn.

Examples

The examples that follow show a variety of canvas and palette patterns. Adobe Photoshop (Figure 2-36) is a classic. All four edges of the app feature palettes, panels and commands that the author uses when working on an image. In Axure RP Pro (Figure 2-37), there are palettes to the left and right of the central drawing pane, where the user creates interactive wireframes for software prototypes. Next is OmniGraffle (Figure 2-38), a vector drawing application for MacOS, which has its tools palette on the left. Even mobile apps have need of this pattern when dealing with large numbers of tools or choices. In iOS Photos (Figure 2-39), the image that the user is editing appears in the central canvas. Below this are three tools palettes that are open-close panels, with multiple editing tools inside each.

Figure 2-36. Adobe Photoshop

Figure 2-37. Axure RP Pro

Figure 2-38. OmniGraffle

Figure 2-39. iOS Photos

What

A feature or component that leads the user through the interface step by step to do tasks in a prescribed order.

Use when

You are designing a UI for a task that is long or complicated, and that will usually be novel for users—not something that they do often or want much fine-grained control over (such as the installation of a software package). You’re reasonably certain that the designer of the UI will know more than the user does about how best to get the task done.

Tasks that seem well suited for this approach tend to be either branched or very long and tedious—they consist of a series of user-made decisions that affect downstream choices.

The catch is that the user must be willing to surrender control over what happens and when. In many contexts, that works out fine, because making decisions is an unwelcome burden for people doing certain things: “Don’t make me think, just tell me what to do next.” Think about moving through an unfamiliar airport—it’s often easier to follow a series of signs than it is to figure out the airport’s overall structure. You don’t get to learn much about how the airport is designed, but you don’t care about that.

But in other contexts, it backfires. Expert users often find a Wizard frustratingly rigid and limiting. This is particularly true for software that supports creative processes such as writing, art, or coding. It’s also true for users who actually do want to learn the software; Wizard doesn’t show users what their actions really do or what application state gets changed as choices are made. That can be infuriating to some people.

Why

Divide and conquer. By splitting up the task into a sequence of chunks, each of which can be dealt with in a discrete “mental space” by the user, you effectively simplify the task. You have put together a preplanned road map through the task, thus sparing the user the effort of figuring out the task’s structure—all they need to do is address each step in turn, trusting that if they follow the instructions, things will turn out OK.

But the very need for a Wizard indicates that a task might be too complicated. If you can simplify a task to the point where a short form or a few button clicks can do the trick instead, that’s a better solution. (Keep in mind, too, that a Wizard approach is considered a bit patronizing.)

How

Examples

The Microsoft Office designers have done away with many of its Wizards, but a few remain—and for good reason. Importing data into Excel is a potentially bewildering task. The Import Wizard (Figure 2-40) is an old-school, traditional application Wizard that guides the user step by step through the import process. It uses Back/Next buttons, branching, and no sequence map, but it works. Each screen lets you focus on the step at hand, without worrying about what comes next.

Figure 2-40. The Microsoft Excel import wizard

What

An easy-to-find, self-contained page or window where users can change settings, preferences, or properties. Divide the content into separate tabs or pages if you need to manage large numbers of settings.

Use when

You are designing any of the following applications or tools, or something similar:

• An application that has app-wide preferences.

• An operating system (OS), mobile device, or platform that has system-wide preferences.

• A site or app for which a user must sign in—users will need to edit their accounts and profiles.

• An open-ended tool to create documents or other complex work products. Users might need to change a document’s properties, an object within a document, or another item.

• A product configurator, which allows people to customize a product online.

Why

Though both use forms, a Settings Editor is distinct from a Wizard, and it has very particular requirements. A user must be able to find and edit a desired property without being forced to walk through a prescribed sequence of steps—random access is important.

To aid findability, the properties should be grouped into categories that are well labeled and make immediate sense.

Another important aspect of Settings Editor design is that people will use it for viewing existing settings, not just changing them. The design needs to communicate the values of those settings at a glance.

Experienced users have strong expectations for preference editors, account settings, and user profiles being in familiar places and behaving in familiar ways. Break these expectations at your own peril!

How

First, make it findable. Most platforms, both mobile and desktop, have a standard place to find application-wide preferences—follow the conventions, and don’t try to be overly clever. Likewise, websites where people sign in usually put links to account settings and profiles where the username is shown, often in the upper-right or upper-left corner.

Second, group the properties into pages, and give those pages names that make it easy to guess what’s on them. (Sometimes all the properties or settings fit on one page, but not often.) Card-sorting exercises with representative users can help you figure out the categories and their names. An outrageously large number of properties might require a three- or four-level hierarchy of groups, but be careful that users don’t get frustrated at having to click 53 times to reach commonly needed properties.

Third, decide how to present these pages. Tabs, Two-Panel Selector, and One-Window Drilldown (Chapter 7) with an extensive page “menu” on the top page seem to be the most common layouts for Settings Editor.

The design of the forms themselves deserves an entire chapter. See Chapter 10 for patterns and techniques used in forms.

Finally, should you immediately apply changes that the user makes or offer Save and Cancel buttons? That can depend on the type of settings you’re working with. Platform-wide settings seem to be applied immediately when changed; settings on websites mostly use Save buttons; and application settings and preferences can go either way. It might not be a huge usability issue in any case. Follow an established convention if there is one, or see what the underlying technology requires; test it with users if you still have open questions.

Examples

Google (Figure 2-41) and Facebook (Figure 2-42) both use tabs to present the pages of their profile editors. Amazon has one single link for all account-related information: Your Account (see Figure 2-43). This Menu Page (Chapter 3) lists account settings alongside order information, credit card management, digital content, and even community and wish-list activity. The clean, tight page organization is terrific—if I have any questions about what’s going on with my relationship to Amazon, I know I can find it somewhere on this page.

Google, Facebook, and Amazon have huge settings, preferences, and configuration management issues related to their services. Customers must access these settings from time to time in order to review or change them. All have opted for a strong organization system to categorize their settings and preferences. Google and Facebook use tabs to organize the settings into major categories, with screens in each that are in turn sectioned out with titles and groups of controls to allow for comprehension and relatively easy access. Amazon places its most frequently used settings and configurations at the top of the settings screen, with special formatting as giant buttons. Selecting one allows the user to drill down into the appropriate category of settings. Below this is a grid of cards, each labeled with its settings category name, and displaying a list of links to each subcategory within. All three use strong information architecture and navigation to bring some understandable structure to a complicated part of their platform. Although it’s not painless, the user has a good chance of eventually finding and changing the setting they seek.

Amazon (Figure 2-43) offers an outrageously large number of properties that require a deep hierarchy of pages. The designers mitigated some of the problems, however. For instance, they put a list of shortcuts on the top-level page; these are probably the items users look for most often. They put a search box on the top. And by using lists of items, they show users which items fall into which categories.

Figure 2-41. Google

Figure 2-42. Facebook

Figure 2-43. Amazon

In Apple’s mobile OS, iOS, there are many settings (Figure 2-44). Some are for the entire device, and some are for individual apps on the iPhone. Apple has opted for a single scrolling list. Some order is provided by putting the most critical and frequently used settings at the top. The items in the long list are also grouped to help with navigation and selection.

For its desktop OS, macOS, Apple has opted for a panel of categories for its system settings (Figure 2-45). These are marked by sections, icons, and labels to help with understanding the categories and selecting the right one.

Figure 2-44. iOS settings

Figure 2-45. macOS system preferences

What

Views or methods of visualizing information in your software or app that are substantially different from one another but offer access to the same information.

Use when

You’re building something that views or edits a complex document, list, website, map, or other content. You might face design requirements that directly conflict with one another. You can’t find a way to show both feature set A and feature set B at the same time, so you need to design both separately and let the user choose between them.

Why

Try as you might, you can’t always accommodate all possible usage scenarios in a single design. For instance, printing is typically problematic for websites because the information display requirements differ—navigation and interactive gizmos should be removed, for instance, and the remaining content reformatted to fit the printer paper.

There are several other reasons for Alternative Views:

• Users have preferences with regard to speed, visual style, and other factors.

• A user might need to temporarily view data through a different “lens” or perspective in order to gain insight into a problem. Consider a map user switching between views of street information and topographic information (see Figure 2-31 at the top of the pattern).

• If a user is editing a slideshow or website, for instance, they might do most of their editing while using a “structural” view of the document, containing editing handles, markers for invisible content, layout guides, private notes, and so on. But sometimes they will want to see the work as an end user would see it.

How

Choose a few usage scenarios that cannot easily be served by the application’s or site’s normal mode of operation. Design specialized views for those scenarios, and present them as alternatives within the same window or screen.

In these alternative views, some information might be added and some might be taken away, but the core content should remain more or less the same. A common way to switch views is to change the rendering of a list; file finders in both Windows and macOS let users switch from lists to Thumbnail Grid to Tree Table to Carousel, for instance.

If you need to strip down the interface—for use by a printer or screen reader, for instance—consider removing secondary content, shrinking or eliminating images, and cutting out all navigation but the most basic.

Put a “switch” for the mode somewhere on the main interface. It doesn’t need to be prominent; PowerPoint and Word used to put their mode buttons in the lower-left corner, which is an easily overlooked spot on any interface. Most applications represent the alternative views with icons. Make sure it’s easy to switch back to the default view, too. As the user switches back and forth, preserve all of the application’s current state—selections, the user’s location in the document, uncommitted changes, undo/redo operations, and so on because losing them will surprise the user.

Applications that “remember” their users often retain the user’s alternative-view choice from one use to the next. In other words, if a user decides to switch to an alternative view, the application will just use that view by default next time. Websites can do this by using cookies; desktop applications can keep track of preferences per user; an app on a mobile device can simply remember what view it used the last time it was invoked. Web pages can have the option of implementing Alternative Views as alternative CSS pages. This is how some sites switch between ordinary pages and print-only pages, for example.

Examples

Let’s look at an effective use of different “modes” or alternative views of data in two different applications. The pattern is to offer search results on a map, giving a spatial or geographic representation, and then to show the same results as a scrollable list, which can be sorted and filtered more easily. One mode is for an overview, and geographic context (closer to or further from me). The other is for reading detailed information about each item.

Yelp, the local business directory platform, is the first example. On iOS, the Yelp mobile app (Figure 2-46) offers the two aforementioned views. The searcher must toggle between the views on the small screen format. The Yelp desktop app (Figure 2-47) has the room to offer the map and list views side by side. This offers more robust exploration and learning interactions, such as highlighting the same venue in the list and on the map.

Zillow, the real estate  platform, follows a similar design. On iOS, Zillow offers a map view and a list view of your query results (Figure 2-48). The user must toggle between the views. On the Zillow desktop app (Figure 2-49), the home or rental searcher can view these modes side by side. Note the choice to use photographs of the properties in the list view. This supports rapid scanning of the huge numbers of choices so that the searcher can zero in on properties they consider most attractive.

Figure 2-46. Yelp iOS map and list screens

Figure 2-47. Yelp desktop map and list combination screen

Figure 2-48. Zillow iOS map and list screens

Figure 2-49. Zillow desktop map and list combination screen

Two graphic editors, Apple Keynote (Figure 2-50) and Adobe Illustrator (Figure 2-51), show different views of a work product. In the slideshow, the user normally edits one slide at a time, along with its notes, but sometimes the user needs to see all the slides laid out on a virtual table. (Not shown is a third view, in which Keynote takes over the screen and actually plays the slideshow.)

Adobe Illustrator shows an “outline” view of the graphic objects in the document—most useful if you have a lot of complex and layered objects—and the normal, fully rendered view of the artwork. This mode is explicitly for performance reasons. The outline view puts much less demand on the computer processor and so speeds up work considerably.

Figure 2-50. Apple Keynote

Figure 2-51. Adobe Illustrator

What

An interface where users can view more than one page, project, file, or context at a time. It can consist of multiple top-level tabs, tab groups, streams/feeds, panels, or windows. Users might have the option to place these workspaces side by side.

Use when

You’re building an application that views or edits any type of content—websites, documents, images, or entire projects that include many files. A major aspect of choosing this pattern is the need to have different views or task “modes” available at the same time. For example, people often keep many browser tabs open at the same time so that they can switch between various websites, or compare them. Application developers and media creators often need to see and adjust code or controls in an editor window, and at the same time see the output of their work to see whether they are getting the desired outcomes—either as compiled and executed code, or as a rendered media object.

Designers of conventional websites don’t generally need to think about this. All of the major browsers supply perfectly good implementations of this pattern, using tabs and browser windows. Spreadsheet applications such as from Microsoft or Google offer tabbed workspaces to separate a complicated workbook into individual calculation sheets.

Applications whose central organizing structure is a personal news stream might not need Many Workspaces, either. Email clients, personal Facebook pages, and so forth show only the one news stream that matters to the user; multiple windows don’t add much value. That being said, email clients often let a user launch multiple email messages in different windows. Some Twitter applications can show several filtered streams side by side; for instance, they might show a search-based feed, then a feed from a custom list, and then a feed of popular retweets. (See the TweetDeck example in Figure 2-52.)

Why

People sometimes need to switch rapidly between different tasks in the same project or file, or monitor activity across a large number of real-time feeds.

People multitask. They go off on tangents, abandon trains of thought, stop working on task A to switch to task B, and eventually come back to something they left hanging. You might as well support it directly with a well-designed interface for multitasking.

Side-by-side comparisons between two or more items can help people learn and gain insight. Let users pull up pages or documents side-by-side without having to laboriously switch context from one to another.

This pattern directly supports some Chapter 1 patterns, such as Prospective Memory (a user might leave a window open as a self-reminder to finish something) and Safe Exploration (because there’s no cost in opening up an additional workspace while leaving the original one where it is).

How

Choose one or more ways to show multiple workspaces. Many well-known applications use the following:

• Tabs

• Separate OS windows

• Columns or panels within a window

• Split windows, with the ability to adjust the splitters interactively

If you deal with fairly simple content in each workspace—such as text files, lists, or Streams and Feeds—split windows or panels work fine. More complex content might warrant entire tab pages or windows of their own so that a user can see a larger area at once.

The most complicated cases involve development environments for entire coding projects. When a project is open, a user might be looking at several code files, stylesheets, command windows (where compilers and other tools are run), output or logfiles, or visual editors. This means that many, many windows or panels can be open at once.

When users close some web browsers, such as Chrome, the set of workspaces (all open web pages, in tabs and windows) are automatically saved for later use. Then, when the user restarts the browser, their entire set of previously opened web pages is restored, almost as they left it. This is especially nice when the browser or machine has crashed. Consider designing in this feature; it would be a kindness to your users.

What

Providing labels, explanations, and descriptions of how to use the interface are a fundamental part of making usable software. The goal is to provide assistance, answers, or training to users when they need it—in multiple forms so the it can be accessed in different situations.

Use when

Every well-designed website or application should have some form of help. Copy on the screen, prompts in form elements, and tool tips are a must. How will you help beginners become experts? Some users might need a full-fledged help system, but you know most users won’t take the time to use it. For complicated applications, full training and help documentation is a must.

Why

Users of almost any software artifact need varying levels of support for the tasks they’re trying to accomplish. Someone approaching it for the first time ever (or the first time in a while) needs different support than someone who uses it frequently. Even among first-time users, enormous differences exist in commitment level and learning styles. Some people want to watch a tutorial video, some won’t; most find tool tips helpful, but a few find them irritating.

Help texts that are provided on many levels at once—even when they don’t look like traditional “help systems”—reach everyone who needs them. Many good help techniques put the help texts within easy reach, but not directly in the user’s face all the time, so users don’t become irritated. However, the techniques need to be familiar to your users. If they don’t notice or open a Collapsible Panels, for instance, they’ll never see what’s inside it.

How

A lightweight or simple help approach can include displaying meaningful on-screen copy, such as descriptive headers and on-screen instructions. Rollover tool tips for all controls is another lightweight approach. However, rollovers work only on desktop apps in which the browser can track where the user’s mouse pointer is, thus triggering tool tips based on location. Mobile can offer tool tips, as well, but these must be tapped on to access them (there is no hover concept in the mobile interaction design world). This also means any hover tools that you have implemented in a web app must be accessed via a tap action, icon, or menu on mobile.

When the user wants to learn in more detail or as a task in itself, a user guide or online manual is the way to go. Sometimes, this is in your application itself. Other times, it is a separate website or system. This is a more heavyweight technique because it involves creating more content. The benefit is that this help system information has a long life cycle–it provides value for a long time and doesn’t need continuous updating. Users can refer to it again and again, and updates need happen only periodically.

You can think of help systems as existing on multiple levels of detail. Some are very close to the user and their task and are meant to maintain focus on completing it. Others are separate experiences in and of themselves and create a separate learning environment, for times when the user wants to focus on learning.

Create help on several levels, including some (but not necessarily all) of the help types in the following list. Think of it as a continuum: each requires more effort from the user than the previous one but can supply more detailed and nuanced information:

• Meaningful headings, instructions, examples, and help text directly on the page, including patterns such as Input Hints and Input Prompt (both found in Chapter 10). At the same time, try to keep the total amount of text on the page low.

• Prompt text in form fields.

• Tool tips. Use them to show very brief, one- or two-line descriptions of interface features that aren’t self-evident. For icon-only features, tool tips are critical; users can take even nonsensical icons in stride if a rollover says what the icon does! (Not that I’d recommend poor icon design, of course.) The disadvantages of tool tips are that they hide whatever’s under them and that some users don’t like them popping up all the time. A short time delay for the mouse hover—for example, one or two seconds—removes the irritation factor for most people.

• Hover Tools (Chapter 8). These can display slightly longer descriptions, shown dynamically as the user selects or rolls over certain interface elements. Set aside areas on the page itself for this rather than using a tiny tool tip.

• Longer help texts contained inside Collapsible Panels (see Chapter 4).

• Introductory material, such as static introductory screens, guided tours, and videos. When a new user starts the application or service for the first time, these materials can immediately orient them toward their first steps (see the Instant Gratification pattern in Chapter 1). Users might also be interested in links to Help resources. Offer a toggle switch to turn off the introduction—users will eventually stop finding it useful—and offer a way back to it elsewhere in the interface in case a user wants to go back and read it later.

• Help shown in a separate window, often in HTML via browsers, but sometimes in WinHelp or Mac Help (a desktop app for help). The help resource is often an online manual—an entire book—reached via menu items on a Help menu, or from Help buttons on dialog boxes and HTML pages.

• Live technical support, usually via chat email, the web, Twitter, or telephone.

• Online community support. This applies only to the most heavily used and invested software—the likes of Photoshop, Linux, Mac OS X, or MATLAB—but users might consider it a highly valuable resource. Host your own community or use social networking resources for these or more traditional online forums.

Examples

In-screen help: labels and tool tips

The first layer of help that can be designed into your software is the help that appears right in the context of usage: labels, rollover highlights, and tool tips. In Adobe Photoshop’s desktop application (Figure 2-55), hovering the mouse over a tool icon (which lacks a label) causes it to change background color and then display a tool tip that explains what the highlighted tool does. Learning through exploration is enabled this way.

Figure 2-55. Adobe Photoshop: animated titles as hover tools and tool tips

Microsoft Excel (Figure 2-56) view controls have permanent labels. The selected tool has a selected appearance and a corresponding label. But if the user hovers over an unselected view button, the label will change to show temporarily what the name of the highlighted (not selected) tool is. Excel also makes extensive use of regular rollover tool tips, as shown in Figure 2-57, especially for icons that don’t have default labels.

Figure 2-56. Microsoft Excel: animated titles as hover tools

Figure 2-57. Microsoft Excel: tool tips

Help systems

Publishing instructional and reference content in the software platform or application itself is a longstanding best practice in usability and customer success. Essentially it means providing a digital version of the user manual for the software that the customer can access as needed. This provides incredible value to users because they have a place to turn to answer their questions that they can access on their own, without having to initiate a customer service request. They also don’t need to break from their task at hand to come back later. Also, new users self-train with such materials. From a customer confidence and satisfaction point of view, and considering the savings in reduced customer service requests, deploying a help system in your application (or in a separate website that your software can link to) is a significant benefit.

Adobe Photoshop (Figure 2-58) shows how a designer can access help and tutorials directly in the application. From Photoshop, the user has links to the Adoble Photoshop Help website (Figure 2-59). Microsoft Excel (Figure 2-60) offers the full help system in a separate application window that can be opened while using the app.

Figure 2-58. Adobe Photoshop Search and Help

Figure 2-59. Adobe Photoshop Help (website)

Figure 2-60. Microsoft Excel Help (in the application itself)

New user experiences: guided instruction

What is the most natural way in the world for a visitor, a new resident, or a new employee to learn where things are, how the space or campus is laid out, or how to do things? Or, what’s the best way for an existing user to get some help in the form of a reminder, a repeat training, or a “refresher”? It’s to ask a more experienced person to give a tour, to be a guide. Many software platforms have taken this approach to onboarding new users. It’s possible to create and deploy step-by-step guides for software that gives a new customer or employee a tour of the software or a guide for how to do specific tasks. These often take the form of an overlay on top of the standard interface, or a series of pop ups that point to key screen components. In this way, a new UX can be scripted and developed once and then used by many people after that.

Userlane (Figure 2-61) is a company that provides a user-guide authoring platform that other companies can deploy in their own software. In the example here, using Wikipedia as a demonstration, an instructional panel displays in lightbox mode on top of the regular Wikipedia interface. In this way, the learner is prompted to focus on one step or interface component at a time, which promotes better learning. They can also go at their own pace while still getting a tour of all the most important parts of the software by the end.

Similarly, Pendo (Figure 2-62) offers pop-up user guides as part of its customer engagement platform. The Pendo customer, usually a software company, creates user guides for how to do things in the app. In this example, the learner is in the middle of some task walk-through. The immediate next step, which is to go to Settings, is highlighted at top in an overlay.

Figure 2-61. Lightbox mode: instructional panel with highlighted step (Userlane)

Figure 2-62. Overlay mode: step-by-step pop ups pointing to UI elements (Pendo)

Online community

Finally. if all other sources of help are exhausted, a user can turn to the wider user community for advice. We’ve now moved beyond the realm of software design, per se, but this is still product design—the UX extends beyond the bits installed on users’ computers. It includes the interactions they have with the organization, its employees or other representatives, and its website.

The UI design app Sketch is widely used, and it’s no surprise that the company wants to bring this community together around this popular tool. The Sketch User community (Figure 2-63) shows how this community is a source of news and learning.

Similarly, Adobe User Forums (Figure 2-64) offer a way for designers and others to discuss issues. Adobe creates the forum. Their customers create the content in the form of discussions, questions and answers, and advice. In this way, knowledge can be spread more easily among members of the community.

Community building like this happens only for products in which users become deeply invested, perhaps because they use the product every day at work or at home. But having an online community of users of some sort is common. It is also a huge advantage for the product. So, it is worth considering how to foster such a community.

Figure 2-63. User community as a learning resource; hosted by third party (Sketch community hosted by Spectrum)

Figure 2-64. Adobe User Forums