Chapter 7
Interface Design

Since objects cannot speak for themselves, they need to be made to look like what they are and what they do.
—Ralph Caplan, By Design

The technology framework underlying today’s web provides a platform for far more than basic link- and form-based interaction. Much of the complex behavior and functionality that has historically been the domain of native applications, including word processor, image, and video editing software, can now take place in the browser. With the added capacity for complex interfaces comes another crucial skill for web development teams—interaction design. Many web teams include visual designers and information architects but lack experience in designing user interfaces. And quality user experiences depend largely on how easy a site is to get around in while staying oriented, and how easy the features of the site are to use.

Designing for the medium

Readers need a sense of context of their place within an organization of information. In paper documents this sense of where you are is a mixture of graphic and editorial organizational cues supplied by the design of the book, the organization of the text, and the physical sensation of the book as an object. Electronic documents provide none of the physical cues we take for granted in assessing information. When we see a web hypertext link on a page, we have few clues to where we will be led, how much information is at the other end of the link, and exactly how the linked information relates to the current page.

Even the view of individual web pages is restricted for many users. Most web pages don’t fit completely on a standard office display monitor; there is usually a lower part of the page that the user cannot see. Users of small-screen mobile devices have an even more limited viewport, and a big-picture view of a web page is impossible for screen reader users, who access pages an element at a time. Web pages need to give the user explicit cues to the context and organization of the site because only a small segment of any site is available at one time.

No dead-end pages

Web pages often appear with no preamble: users can make or follow links directly to subsection pages buried deep in the hierarchy of web sites. They may never see your home page or other introductory site information. If your subsection pages do not contain links to the home page or to local menu pages, the user will be locked out from the rest of the web site (fig. 7.1).

Make sure all pages in your site have at minimum a link back to the home page or, better yet, a home page link along with links to other main sections of the site. In addition to user interface considerations, these links are crucial for search engine visibility.

Direct access

Users want to get information in the fewest possible steps. This means that you must design an efficient hierarchy of information to minimize steps through menu pages. Studies have shown that users prefer menus that present at least five to seven links and that they prefer a few pages of carefully organized choices over many layers of oversimplified menu pages. Design your site hierarchy so that real content is just a click or two away from the main menu pages of your site.

Simplicity and consistency

Users are not impressed with complexity that seems gratuitous, especially those users who may be depending on the site for timely and accurate information. Your interface metaphors should be simple, familiar, and logical—if you need a metaphor for collections of information, choose a familiar genre, such as file folders. Unusual or peculiar “creative” navigation and home page metaphors always fail because they impose an unfamiliar, unpredictable interface burden on the user. Baffle users with a weird home page, and they will quickly hit the “back” button and move on to the next item on the Google results page, and you’ll have lost a potential reader or customer. Let your content shine, and let the interface recede.

The best information designs are never noticed. Once you know where the standard links are on the page header graphics, the interface becomes almost invisible. Navigation is easy and never competes with content for your attention (fig. 7.2).

For maximum functionality and legibility, your page and site design should be built on a consistent pattern of modular units that all share the same basic layout grids, graphic themes, editorial conventions, and organization hierarchies. The goal is to be consistent and predictable; your users should feel comfortable exploring your site and confident that they can find what they need. The graphic identity of a series of pages in a web site provides visual cues to the continuity of information. The header menu present on every page of the Code for America site creates a consistent user interface and strong site identity (fig. 7.3).

Even if your site design does not employ navigation graphics, a consistent approach to the layout of titles, subtitles, page footers, and navigation links to your home page or related pages will reinforce the user’s sense of context within the site. To preserve the effect of a “seamless” system of pages, you may wish to bring important information into your site and adapt it to your page layout scheme rather than using links to send the reader away from your site (but be sure there are no copyright restrictions on copying the information into your site).

Integrity and stability

To convince your users that what you have to offer is accurate and reliable, you will need to design your web site as carefully as you would any other type of corporate communication, using the same high editorial and design standards. A site that looks sloppily built, with poor visual design and low editorial standards, will not inspire confidence.

Functional stability in any web design means keeping the interactive elements of the site working reliably. Functional stability has two components: getting things right the first time as you design the site, and then keeping things functioning smoothly over time. Good web sites are inherently interactive, with lots of links to local pages within the site as well as links to other sites on the web. As you create your design, you will need to check frequently that all of your links work properly. Information changes quickly on the web, both on your site and on everyone else’s. After the site is established, you will need to check that your links are still working properly and that the content they supply remains relevant.

Feedback and dialog

Your web design should offer constant visual and functional confirmation of the user’s whereabouts and options, via graphic design, navigation links, and uniformly placed hypertext links. Feedback also means being prepared to respond to your users’ inquiries and comments. Well-designed web sites provide direct links to the web site editor or webmaster responsible for running the site. Planning for this ongoing relationship with users of your site is vital to the long-term success of the enterprise.

Bandwidth and interaction

Users will not tolerate long delays. Research has shown that for most computing tasks the threshold of frustration is about ten seconds. Web page designs that are not well “tuned” to the network access speed of typical users will only frustrate them. Check your web site logs to be sure that you understand your typical user’s location and network connections. If you have many international users, for example, you may want to be more conservative about large graphics on your pages (fig. 7.4).

In 2013 there were more than 2.1 billion active mobile broadband subscriptions worldwide, or about 29.5 percent of the global population. In China alone there are an estimated 420 million mobile broadband users, and two-thirds of those subscriptions are for various kinds of smartphones. For many international users (and about a third of U.S. users) their smartphones are their primary computing device. All this suggests that while high-speed Internet access has become standard in the home and office in developed countries, bandwidth is still an issue for the vast majority of the world’s web users.

Beware of potentially slow dynamic content components in your site, such as excessive CSS or JavaScript code libraries, RSS feeds, text from content management systems, or other data sources that can slow the loading of web pages.

Avoid including bandwidth-intensive videos on the main pages of your site—particularly those that are set to “autoplay.” Automatically loading and playing a video has several downsides from an interaction perspective, beyond the demands it places on bandwidth usage. For example, people who use screen reader software will need to find the video controls and stop the video in order to navigate the page. Don’t assume people want to load and watch videos. Instead, play videos only in response to an explicit user action, such as pressing the “Play” button.

Ideally your company webmaster should be able to supply reports and data on your typical users and their equipment. If you don’t have easy access to this information from your organization’s web server logs, you may be able to use a free service like Google Analytics to better understand the geography of your users.

Displays

The sheer number, variety, and orientations of modern computing screens or “viewports” pose serious challenges for the web designer. Indeed, today’s dominant responsive web design methods and the CSS3 @media code queries that responsive design is built upon were born as an attempt to provide a reasonable user experience across the incredible spectrum of current viewports from small smartphones to giant “4k” desktop monitors.

Three intimately related—and sometimes opposing—factors govern screen graphic and user interface design in both mobile and desktop situations:

To accommodate this dramatic change in resolution hardware, makers like Apple and Samsung have introduced schemes that use “rendered pixels (sometimes called “CSS pixels” or “virtual pixels”), in which one rendered screen pixel is actually composed of four hardware pixels. Thus an iPhone 6 screen has a physical pixel resolution of 1,080 by 1,920, but behaves for type and layout measurements as if the screen were 540 by 960. Otherwise, all web pages and typography would look miniaturized on the most recent “retina” screens of smartphones. (See fig. 11.17 for more on virtual pixels.)

This need to balance the physical size of mobile viewports with the increasing resolution of display technology will be an ongoing challenge to web designers. In general this is good news: images and type look spectacular on the newer displays, and the increased legibility will bring a new world of illustration and typographic possibilities to our screens.

Navigation and Wayfinding

In his book The Image of the City, Kevin Lynch coined the term “wayfinding” to describe his concept of environmental legibility—that is, the elements of the built environment that allow us to navigate successfully through complex spaces like cities and towns. The most fundamental underlying metaphor of the World Wide Web is navigation through a space populated by places we call web “sites,” and thus the wayfinding metaphor is well suited to thinking about web navigation (fig. 7.7).

Wayfinding has four core components:

  1. Orientation: Where am I am right now?
  2. Route decisions: Can I find the way to where I want to go?
  3. Mental mapping: Are my experiences consistent and understandable enough to know where I’ve been and to predict where I should go next? Can I make a coherent mental map of the spaces I have seen, and use it to predict where to go next?
  4. Closure: Can I recognize that I have arrived in the right place?

In interviews conducted in various cities, Lynch had local residents draw maps of their cities from memory. The mental maps that residents create are crucial to wayfinding in their environment. An individual’s map of the local environment is unique, but Lynch found that most people’s maps were populated by five types of elements:

Although you can readily see the parallels with navigation on the web, the web is a special kind of space that often doesn’t provide the concrete spatial and navigational clues we take for granted in the real world of walking through a town.

Supporting search and browse navigation

User interface research shows that about two-thirds of web users are browse-dominant—that is, they prefer (at least initially) to browse through menu lists of links to find information. The other third of users are search-dominant, and will go straight to the search box to enter keywords for search. However, this apparent search versus browse dichotomy is simplistic, as research also shows that most users use both browse and search, that 92 percent of users use search at some point in their online activity, and that even users who use search almost exclusively benefit from the information in the browse navigation interface of major site divisions and categories.

Jakob Nielsen has pointed to the irony that web search is used more than ever—by users who typically don’t use search engines effectively. Research by usability experts consistently finds that most readers have only a vague idea how search works, do not understand how to construct efficient queries, and rarely use more advanced features such as scoped search options or “advanced search” pages. It’s a testament to how good Google and Bing are that a simple search box works at all, let alone that it works most of the time for most users. Don’t be misled by the fact that users these days are becoming more search-dominant. Even users who understand search well benefit from well-constructed browse interfaces.

Users often begin navigating an unfamiliar site by clicking on the persistent navigation links of the browse interface, and then shift over to search if they can’t find what they need solely through clicking on links. All readers will use both the browse and search features of a complex site at some point, so supporting both navigation paradigms is important to interaction design. As the web has become larger and more complex, the dependence on search technology has become greater, both for users seeking information and for web publishers hoping users will find their content.

However, even users who depend primarily on site search for navigation also depend on the consistency of persistent site navigation to give them cues for where they are within the site, and how the site information is structured. Even if the search-oriented user never clicks on the header navigation links, that system of major content categories is still an import set of landmarks. Well-designed browse interfaces also support both findability and discoverability in web sites:

Search navigation is most effective for users who already have a thorough understanding of the information space and the vocabulary needed to describe what they are looking for. Imagine word-searching for some gizmo that you don’t even know the name of and you can see the problem. The persistent browse navigation of your site continually teaches search users how you describe things, and how you categorize your information. It is often faster and easier to use a hybrid approach in large sites like Amazon, where you might start by browsing through major product categories, and then use the search box once you are pretty sure that you are in the general region of what you are looking for.

Search does not replace good browse navigation for another reason: many local search tools don’t work very well, producing irrelevant results, few results, or far too many results. For example, in many local search systems (such as those built into cms products) the query “child study center” yields all results for “child,” all results for “study,” and all results for “center,” none of which is remotely relevant. In really poor search engines even enclosing a multiword phrase within quotes doesn’t help. A good browse interface can help make up for poor local search results.

Designing navigation

Most web sites are composed of pages, each with a unique URL. Navigation design is about providing a map describing the topography of the site, and systems of transport for moving from one location to another.

Menus highlight popular destinations

We tend to think of navigation primarily as a means of getting from here to there. Another key function of navigation is to show users what you are offering and what options they can pursue. In this way, your navigation system is like a feature list, and if you don’t make clearly visible the options that would appeal to your target audience, they may not get past the home page. (Alan Cooper and team describe menus as a “pedagogic vector,” teaching users what an application can and cannot do.)

Think of navigation as a map of your site’s features and functionality. What key attributes do you need to expose to keep your target audience on your site? What are they most interested in? How can you describe and display those features so they are immediately evident and meaningful? A user-centered approach can help focus the development team’s attention on including the most relevant aspects of a site from the user’s perspective, and can sometimes resolve internal conflicts around what must be included in the main menu. Make sure your menus accurately represent the scope and primary focus of your offerings, and map to the expectations of your target audience.

Paths lead the way

In web sites, paths are the consistent, predictable navigational headers and links that appear the same way throughout the web site. Paths can be purely in the user’s mind, as in your habitual navigation through a favorite newspaper site. Paths can also be explicit site navigation elements such as breadcrumb trails that show you where you are in relation to the overall site (fig. 7.9).

Create consistent, well-marked navigation paths through the use of persistent navigation built into the design of every page. Use persistent navigation elements like header links, “you are here” markers, and breadcrumb trails to establish and reinforce a sense of location and coherent movement through the information space. Clear, consistent icons, graphic identity schemes, page titles and headings, and graphic- or text-based overview and summary screens can give users confidence that they can find what they are seeking without wasting time.

Users should always be able to return easily to your home page and to other major navigation points in the site. These basic links should be present and in consistent locations on every page. Headers provide basic navigation links and create an identity that tells users they are within the site domain. In the King Arthur Flour site, for example, the header appears on every page (fig. 7.11). The header is efficient (offering multiple choices in a small space) and predictable (it is always there, at the top of every page), and it provides a consistent identity throughout the site.

Links support discovery and exploration

Hyperlinks are a key component in web site navigation and wayfinding. Unlike the navigation systems of headers, menus, and breadcrumbs, links are typically embedded within the content of the page. They are invitations to explore different facets of the content on the page in more detail.

The most effective links are:

Links are so common that we now take them for granted, but hyperlinks define the very nature of the web and are a crucial part of the web user interface. Eye-tracking research shows that readers begin scanning a page in the standard “F” pattern that emphasizes the top left portion of the page, but then quickly shift over to scanning the body of the page for major headers and scanning any linked text on the page. Thus graphic design practices such as using CSS to decrease (or even eliminate) the contrast of web links hurts the scanability of page content. Ensuring links are clearly identifiable and easy to comprehend is a key component of interaction design.

A clear “scent” makes choices easier

Coffee used to be easy: it was regular or black. Now with six kinds of mocha skim lattes on offer, coffee has become yet another potential point of stress in your day. In Western societies we equate freedom with a range of choices, but as psychologist Barry Schwartz points out in his book The Paradox of Choice, an excessive range of choices causes stress, slows our decision making, makes us generally less satisfied (did I make the right choice from my eighty-nine options?), and makes us more likely to walk away from making any choice at all. “Give the user choices” is a constant mantra in user interface design, but too many choices delivered simultaneously leaves most users overwhelmed and likely to abandon the path altogether (fig. 7.12).

Too many links and menu options can inhibit exploration by offering so many choices that it’s difficult to choose. Work to maintain a limited set of major navigation categories (ideally seven to ten at most), and progressively disclose additional details as needed in each subsection of the site. In many sites these navigational nodes are built into the persistent browsing hierarchy of the site, with drop-down or pop-up menus that present many secondary options within each major site navigation category.

You may find it difficult to convince others—colleagues on the development team, clients—that less is more when it comes to link and menu options. Instead, you might be encouraged to provide lots of options in order to minimize the number of times users need to click to get to their destination. Usability expert Steve Krug explores this concept in his book Don’t Make Me Think. His second rule of usability is “It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.” The key is to provide a clear path, with self-explanatory labels that don’t require much decoding by the user.

Scent of information

The theory of the “scent of information” originated at Xerox PARC, where researchers theorized that people confronting a large and complex information space become “informavores,” exhibiting the same information as animals hunting prey. Users pick up a scent trail that appears to map to their desired outcome. They follow the trail, becoming more confident and eager if the scent grows stronger. If they lose the scent, they backtrack and try again.

Web sites with strong scent trails are usually those that demonstrate deep insight into and understanding of the target audience for the site. Through user research and a goal-directed design process, the development team has mapped the design of the user interface to meet user goals in a way that maps to their mental models. In this way, users have confidence in working with the site, have fewer failed attempts, and are generally satisfied, happy, and successful in working with the site.

What gives a site strong scent trails? Here we summarize key principles from the section “The Tao of Scent” from “Designing for the Scent of Information,” a concept report from Jared Spool, Shristine Perfetti, and David Brittan of User Interface Engineering (www.uie.com).

Boundaries and landmarks provide orientation

Consistency is the golden rule of interface design and wayfinding, but there is a paradox at the heart of consistency: if everything looks the same, there are no edges. How can you tell where you are or when you have moved from one space to another? A well-designed site navigation system is built on a consistent page grid, terminology, and navigation links, but it also incorporates the visual flexibility to create identifiable regions and edges within the larger space. In a corporate site, if you move from one region to another—say, from marketing to human resources—you ought to notice that you just passed an important regional boundary (fig. 7.13), but the two areas should be similar enough to assure you that you are still within the same company site.

“You are here” orientation cues are particularly important in the web interface, since users often arrive at a page without having followed a deliberate and repeatable path. For example, one point of web wayfinding that is quite unlike navigation in physical space is Search, which cuts across all the normal wayfinding boundaries to provide a view of every occurrence of a keyword or phrase across the web site. Search can deliver you directly from one point in a site to another, and that direct connection makes the user all the more dependent on “you are here” cues from the user interface of the site.

Both the browse and search aspects of navigation must support the user’s sense of location and orientation to the major landmarks of a site. Core page components and interface elements are relevant to both browsing and searching; they establish and maintain a broad sense of a web site as a navigable space and provide a “you are here” sense of local placement within the larger dimension of the site. Breadcrumb trails, tabs or links that change color to indicate the current location, and section titles all contribute to a firm sense of place within a site (fig. 7.14).

These landmark and wayfinding elements are especially important to users who navigate by searching. The browse interface allows users to move gradually through a site, seeing various landmarks as they pass through the site hierarchy (see fig. 7.13). Web search allows a user to cut directly into a site hierarchy with no preamble. Users who come to your site from a general Internet search engine like Yahoo! or Google may arrive directly at a page deep within the organization of your site. As web search becomes the way most of your audience reaches your site, the percentage of users who enter your site at the home page is decreasing all the time.

Create a unique but related identity for each site region, within a larger design system that is consistent throughout the whole enterprise. These “affiliated design systems” are common in enterprises with many divisions, and can provide unique subsection identities while reinforcing the overall enterprise identity.

Consistency makes navigation easier

Consistency in creating and maintaining landmarks is critical for successful wayfinding, whether in the virtual “space” of a large web site or in the actual space of a large urban transportation hub. New York City’s Penn Station is notorious for its poorly designed, confusing, and chaotically maintained signage. Penn Station is the nation’s busiest train station, and is a meeting point for four rail systems: Amtrak, New Jersey Transit, the Long Island Railroad, and the New York City subways. Each of the rail systems maintains its own separate set of signage in the station, and Penn Station itself adds yet another layer of signage, for a total of five unrelated and competing sign sets, no two of which share any design conventions or color sets. Each railroad tries to orient its riders within the station, so many competing and overlapping signs overwhelm the user with visual noise.

The analogy to large, poorly coordinated web sites is nearly perfect. Large enterprises like companies, government agencies, and (particularly) universities often present cluttered Penn Station–like mixes of uncoordinated user interfaces and visual designs. Each area of the larger site tries to “perfect” its own little piece of the domain with locally unique designs and interfaces, and the result is often a confusing experience for readers who must constantly cross system boundaries to find what they need.

In contrast, most modern airports have solved the user experience and wayfinding issues through carefully coordinated signage systems and wayfinding designs. Guided by widely understood and consistent design conventions—arrival boards, departure boards, gate sign systems, universal icons and symbol systems—even travelers who don’t speak the local language can usually find their way to the right plane at the right time.

Poor navigation (in train stations or web sites) can have important consequences. As users become confused, their confidence in their abilities to find the correct next step leads to a decrease in trust in the site in general, which may lead them to abandon the site, or not to buy the product they were seeking—even if they find it—because they no longer trust the site.

Most text-oriented informational web sites are converging on a relatively consistent layout of header, footer, local navigation, and content elements that together make a useful, familiar starting point for web interface designs. In general, people find the familiar easier to use and remember, and if your site follows these familiar patterns, users will quickly adapt and begin to focus on your unique content, features, or products (fig. 7.18).

As you design the interface for your site, remember that the ideal web interface should never compete with the page content for the user’s attention. The interface is the frame, not the painting.

Search also needs wayfinding

The most fundamental support for users who prefer to search is to make search easily available from every page of your site. Users expect that any site of more than a few pages will have a search feature. Research shows that there are specific areas of the page where users expect to see a search box (fig. 7.19), and that most users expect a simple uncomplicated search box and don’t understand or use “Advanced search” options.

Try to let users know the scope of what they are searching, but keep the search scope controls simple and low-key, as many users never use scope controls even when controlling scope would produce better results. It’s confusing when a user enters a keyword thinking that he is searching only the current web site but then gets search results from the whole company or the whole Internet (“Results 1–100 of about 5,100,000,000 for ‘Help’”). In simple search forms you can make the scope of the search clear in the field label, or in a subtle drop-down menu beside the search box. Where there is more room on the page, the search form can offer more options to control the scope of the search (fig. 7.20), but keep it simple.

To preserve a sense of place within your site, the results of a user’s search query should appear on a page that looks like the rest of the web site. For large institutions, as long as the larger institutional site is well organized and graphically consistent, every small subsite does not need to have a custom search page.

Search is powerful, but web search is no substitute for a coherent site architecture, carefully expressed in your page design and navigation. Ironically, search navigation is heavily dependent on those interface elements and page design features that we think of as part of the standard browsing interface. By cutting out the intermediate steps in browsing through an information hierarchy, search can deliver the user to pages deep inside a web site, where only the “browsing” interface of site graphics, page titles, breadcrumb trails, and navigation links can supply the cues that allow users to establish their “you are here” location within the site.

Providing navigation systems

Several interaction design conventions have emerged to help users move along a path in their quest for information and functionality. Conventions aid interaction because they make use of users’ existing knowledge—what Donald Norman calls “knowledge in the head.” For example, in this book we use standard page numbers and running feet for orientation within the book, and we provide a table of contents and index for wayfinding. Readers generally do not need to learn how to interact with a book. When you follow design conventions for web navigation systems, users will be able to apply what they already know about exploring web sites to navigating your site.

Headers for global wayfinding

Web page headers convey the site identity, provide major navigation links, and often offer a search feature. The header is where people expect to see a consistent statement of your organizational identity, and the header graphics and text are probably the most important elements in making a collection of web pages feel like an identifiable “site” rather than a random assemblage of files. User research shows overwhelmingly that users expect that the top left area of your page header will contain both a visual indication of who you are and a link back to your site’s home page. Users also expect that the header will play an important role in global navigation within your site. Important navigation links are often arrayed horizontally within the page header, as links and as a menu bar with drop-down menus. For responsive sites, menu items collapse into a single drop-down menu or slide-out “drawer” on smartphones.

Menus for local wayfinding

Most web sites have too many layers of content and functionality to have everything accessible from the primary navigation, although some sites try, using “mega menus” to provide access to secondary items. These menus can be effective in providing users a more direct path to reaching their goal. However, mega menus can be difficult to implement so that they are usable with the keyboard and work on small devices. They can be disorienting for people who use screen magnification, where only a small portion of the screen is visible at one time. The user may not know the menu is expanded because the affordances—the border and drop shadow—are not visible. Complex menus also create challenges for responsive design, as there are too many options to collapse into a single menu.

More often section navigation displays on the internal pages, in a column on the left- or right-hand side of the screen. According to most user interface and eye-tracking studies, users quickly adapt to content navigation within either the left column or far right column of web pages—just be consistent in how you lay out your navigation on all pages. Left navigation columns are much more common and therefore have an edge in usability because all web users are familiar with them, but with the rise of “mobile-first” responsive sites with simpler two-column page layouts, the navigation column is often on the right side. That said, the right column is sometimes used for parenthetic “related links” or advertising. Given the user expectation that right columns contain advertising, any right-column menu you use should look very different from advertising, or many users may ignore your section navigation.

Breadcrumb trails for navigation and orientation

Breadcrumb trails are a powerful yet easy-to-understand navigation device of web pages. The name is derived from the metaphor of leaving breadcrumbs along your path to find your way back where you came from. In practice, a breadcrumb trail is a simple hierarchical list of web links showing the structure of a site, usually starting with the home page and ending with the major navigation page closest to your current location. Each step in the breadcrumb trail is a clickable web link, so that users have both a visual indication of their current location within the site and a clickable menu of major navigation sections for the site. In addition to its user interface advantages, the breadcrumb trail plays a potentially powerful role in adding major linked keywords to each web page, increasing the search visibility and keyword relevance of a page.

Interaction

With web interaction at its most basic, users interact with pages by clicking on links and submitting forms. This interaction initiates a dialog between the client, usually a web browser, and the server: the browser sends data and page requests to the server, and the server collects data and returns pages. Once the server delivers a page, all dialog is suspended until the browser makes another request. What the user does with the page is immaterial, unless another link is clicked or another form submitted. This client-server model does not lend itself to the type of interaction we have come to expect when working with computer interfaces. Take required fields, for example. In a basic web environment, once the user submits the form, the server checks the data and, if fields are missed, returns the form to the user to complete. This exchange can occur repeatedly if the user does not locate all of the required fields before submitting.

A more effective approach is client-side interaction, providing feedback along the way to help avoid errors, rather than having the user correct errors after completion. With a dynamic form, the fields are validated as they are completed, and the “submit” button is active only when all the fields are complete. On the web, client-side interaction is made possible through a combination of technologies, including HTML, JavaScript, CSS, and the Document Object Model, or DOM. The elements make up Dynamic HTML, or DHTML, which is a way to dynamically update page content, structure, and styling after the page is loaded in the browser.

Ajax, which stands for asynchronous JavaScript and XML, is a technique for providing both dynamic interface elements and dynamic page content, and it is frequently used for building web applications. With Ajax, the page sends requests for small bits of data in response to user actions—for example, zooming in on a map—and the data are displayed in an area of the page without requiring the entire page to reload. Ajax has performance benefits because no individual user action requires a full page reload. Ajax also provides much more in the way of interactivity by allowing for dynamic and responsive user interfaces.

Most modern web sites and applications are built using libraries and frameworks, such as Dojo, JQuery, and AngularJS. These frameworks offer Ajax and other utilities for building rich applications and interactions. They provide out-of-the-box widgets and components that development teams can use to provide interactive features, to the benefit of development teams and users. When many sites use the same libraries, usability is improved since users are familiar with how the components work. The product team benefits from regular updates to the library, which keep the components compatible with new devices and technologies.

Designing interaction

Because web applications place greater demands on the user, it is particularly important to focus on what is relevant to and valued by users, avoiding scope creep at all costs. In designing your application, use recognizable interface conventions and provide guidance to help your users be successful.

Users define relevance

Good interface design arises from restraint. All too often, applications are cluttered and complicated by the enthusiasm of their developers, who add in features and functionality because they can and because they might be useful to some users. Users also often get carried away in their requests for features, thinking, Wouldn’t it be great if the application did this, that, and the other thing, and not taking into account the complexity that inevitably results. In the end, users benefit more from simple designs than from a wealth of features. The cost of adding features that benefit a few users is too high to justify the negative effect on overall usability and ease of use. You are better off focusing on the most critical functions of an application and avoiding all nice-to-have or easy-to-add features. Address those critical features with a design that is uncluttered by unnecessary elements.

The 80/20 rule is helpful for efforts to address the primary needs of the target audience. Following this rule for interaction design, 20 percent of the web site features are used 80 percent of the time. The remaining 80 percent of the features that are in use or under consideration should be evaluated to determine whether they add enough value to the web site to justify their cost, both in resource allocation and in simplicity and usability of the user interface. Removing unnecessary functionality and content allows interaction designers to focus on providing exceptional experiences that appeal to the primary needs of the target audience.

Patterns improve usability

Design patterns are recognizable patterns for interaction, such as drop-down menus for accessing subsection pages and paging navigation for moving through a sequence of pages. Design patterns are designs that have been introduced and proven effective and then are widely adopted until they become conventions. After widespread adoption, the approach becomes a pattern that is readily recognizable by users, which improves usability. Users can leverage what they know and don’t have to create a new mental model for interaction at each site.

Design patterns for interface elements do not have to look the same, but they do need to share the same interaction model and features. Don’t employ a design pattern and change the way it works. Modifying an existing design pattern is worse than adopting a new approach because it conflicts with the users’ mental model for how the pattern works, and users will have to unlearn and learn how to work with your site.

Make sure to account for diverse modes of interaction when implementing design patterns, including people who use touch and keyboard navigation. For example, the established convention for interacting with a button using the keyboard is to use the Space or Enter key to execute whatever action is associated with the button. Some developers create buttons using a link, or anchor, element rather than a native HTML button. Links activate using the Enter key, and pressing Space on a link initiates a page scroll rather than activating the custom button. For interaction, design patterns are about how things function as well as how they look, and honoring conventions is an essential part of providing enjoyable and accessible user experiences.

People use different interaction methods

Modern web sites include functionality based on three modes of interaction: menu and hyperlink selection, form fill-in, and direct manipulation.

People who work with web sites have different methods for using them. Some people use only a keyboard, even when working with touchscreen devices like smartphones. Keyboards offer benefits, such as minimizing the physical effort and fine motor skills needed to work a web site. For people who are blind and cannot see the screen, the keyboard is the way to review and operate interactive components. Alternative input devices like voice-recognition software and switch devices operate by activating keyboard-based commands. Touchscreen devices are clearly designed for pointing, but it’s important to keep in mind that any interaction based on mouse-only events, such as a menu that appears on mouse hover, will not be accessible because there is no equivalent touch gesture.

Even complex direct-manipulation interactions, such as drag-and-drop, can be made to work with keyboard keys: directional arrows, the Tab key, the Enter key. Put aside your mouse and work through your interactive components using the keyboard only to make sure they can be worked using interaction methods other than a mouse.

Responsive sites must also take into account different interaction modalities on touchscreen devices. It’s safe to assume that most people use gestures to interact with web sites on touchscreen devices, although it’s possible to use a keyboard. In fact, using a Bluetooth keyboard and VoiceOver on your iOS device is one of the best ways to evaluate the accessibility of your mobile web site. But in most cases, the mobile context precludes the use of a keyboard, and most people interact using touch. Touch interaction precludes the use of anything that involves a hover event, such as menus or tooltips that display on mouse hover. But mobile interaction has additional nuances because of users who use touchscreen devices using screen reader, such as VoiceOver on iOS and TalkBack on Android, and also using the zoom features of the devices. These modalities have specific gestures that make mobile devices accessible to people with vision impairments.

Choosing form over function: Disabling pinch zoom

Design has always involved a tension between form and function. The expression “form follows function” is often used as a reminder to designers to make sure that the primary driver in decision making is supporting how something works rather than how it looks. This injunction is based on the idea that success in design is defined by how well the product performs in meeting functional requirements rather than aesthetic ones. With a platform like the web, in most cases, function outweighs form in terms of meeting user needs and achieving business goals. But that does not mean that form always follows function.

Case in point: disabling pinch zoom on mobile web sites. Pinch zoom is a gesture that allows users to zoom in and out of web pages on mobile browsers. It’s what allows us to zoom in to see which cousin photobombed our brother’s wedding photo. It’s what allows us to zoom in and tap the tiny text in the footer to call the restaurant and make a reservation. The web is full of crucial information that is difficult to see and controls that are too small to operate with a coarse pointer like a fingertip. People who have low vision require zoom to access content and functionality on mobile devices.

It’s possible through code to disable the pinch zoom feature, and some responsive and mobile sites employ this strategy on the premise that since the designs are optimized for mobile, zooming should not be necessary, and the zoomed view of the layout and content is not aesthetically desirable. As a result, users who have learned to pinch and zoom will not be able to use their customary strategies, which are part of muscle memory, to consume content and access functionality. People who require zoom to access content and functionality will be locked out entirely. The cost to usability is high, merely for the sake of aesthetics.

This dynamic is common on the web—removing link underlines, for example. Graphic designers avoid underlined text because underlining interferes with letterforms. Hyperlinks were originally presented as colored and underlined in order to be readily visible, and to ensure that people who can’t perceive color could distinguish links from surrounding text. When CSS provided the means to remove underlines, there was a collective sigh of relief among designers and a proliferation of color-only hyperlinks. Given the importance of links in wayfinding and interaction, the usability and accessibility costs for this principally aesthetic concern are high. All users have to seek out and maybe even hover over colored text to determine whether it’s a link. Users who can’t perceive colors may miss links altogether. On what is essentially a functional device, and one that is fundamental to participating in work and life, form really must follow function, to ensure that everyone can access the features of the web.

Providing interactive components

The basic interactive web components are hyperlinks and form elements, including text input fields, radio buttons and checkboxes, drop-down menus, and buttons. Over time the web has evolved to support much more complex functionality, as designers and developers have engineered support for rich interactions such as drag-and-drop and group selection. There are costs to moving away from standard HTML to custom components, including compatibility and accessibility. Modern browsers and assistive technology provide fairly standard and complete support for HTML. Engineering custom components requires some wrangling to produce something that is usable on all software and devices, via a keyboard or a pointing device.

For accessibility, interactive components must meet the following success criterion from the Web Content Accessibility Guidelines (WCAG) 2.0:

The guidelines note that the success criterion “is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.” In other words, if you use standard HTML elements correctly, you are providing an accessible user experience without additional code to accommodate assistive technology. For example, the following HTML checkbox provides programmatic information about its name (“I agree to the terms and conditions”), its role (“checkbox”), and its state (“checked”). This information is encoded, which means it’s available to software, such as assistive technology. When screen reader software reads information about the control, it can convey all details necessary, so that someone who can’t see the control can operate it successfully. In addition, the control functions as expected using the keyboard—the Space key toggles the state between checked and unchecked.

For a custom checkbox, the name, role, and station information must be added manually to the HTML code by the web site developer, and the behavior of the checkbox must be scripted, so the checkbox functions as an actionable element and responds to the correct keyboard commands. The custom code and scripts that power the custom checkbox must be regularly revisited and validated across operating systems, browsers, and devices.

Typically it’s design considerations that cause development teams to turn to building custom components. And there was a time when there were significant limitations as to what styles could be applied to interactive elements, such as buttons and checkboxes. However, modern web technologies afford a great deal of visual customization of native HTML elements. Given the overhead of managing custom code and the many nuances to providing accessible solutions across devices and means of use, we recommend favoring standard HTML components over custom controls and widgets. Choose a custom component as your last choice, having exhausted all standard options. And even then, think carefully about whether a certain visual design or distinctive behavior is worth the costs of veering off course. Users benefit from consistent and predictable user interface designs. The development team and client may feel it’s worth the overhead to craft a custom widget. Do your users?

Buttons

Buttons typically appear as rounded rectangles with a single word or short phrase, an image icon, or some combination of the two. Like elevator buttons or a doorbell, they often have a visual affordance that encourages users to tap, click, or press Enter to initiate the action indicated by the button.

Since links can be styled to look like buttons, some sites use an anchor element as a link. This can cause usability issues for screen reader and keyboard users. Even if a link looks like a button, it announces and behaves like a link. For example, pressing the Spacebar key on a link scrolls the page, whereas pressing Spacebar on a button executes the action. It’s important to understand the difference between buttons and hyperlinks—links enable navigation among pages, and buttons execute an action—and use the correct control for the task.

Menus

Menus are lists of options from which users select what best fits. In the context of navigation, menus are both informative, in revealing options, and functional, in providing a means to move from one area of the site to another, or to choose to access specific functionality. Menus use the design strategy of progressive disclosure, where only the most immediate and relevant layer displays initially, and additional options are revealed when the user selects the main menu item.

For form fill in, menus are helpful for collecting information in a standard format. They work with information where the possible responses are known, such as dates. Using a menu makes for cleaner data collection since the responses can be standardized in both substance and format, whereas users can enter the wrong information, or the right information in the wrong format, in a text input field. In some cases, menus can improve usability. They provide a list of acceptable choices for inputs where the options are not known—for example, choosing shirt size and color. But they can also be tedious with familiar information, such as birth year, or home state or province, where entering the information from the keyboard would be faster than scanning through a long list of options.

Inputs

Form fill-in using input fields and scrolling text areas allows users to type information directly into a field rather than choosing from a predefined menu of choices. Fields are required when the information is open-ended and therefore cannot be represented in a menu. Fields are sometime preferable for information that is easier to enter into a field than to choose from a menu. For example, even though dates are predefined, it may be easier to enter the information into a form field than to choose it from a set of menus. “Year of birth” menus, for instance, need to be enormous and can be awkward to manipulate. A simple input field is the easier choice.

Toggles

A toggle is a control that, when activated, switches some functionality between an on and off state. Toggles are commonly used in desktop software toolbars, to apply formatting such as bold or italic to a block of text, for example. On the web, toggle controls are used for form fill-in—a single checkbox functions as a toggle control, for example, with checked meaning “yes” and unchecked meaning “no.” But they are also frequently used for display-related interactions, such as showing hidden content and functionality. Toggles allow for simple user interface designs for complex functionality. The most important features are in the foreground, while features that are necessary but used infrequently are still close at hand.

WAI-ARIA as a last resort

WAI-ARIA (Accessible Rich Internet Applications Suite) is a W3C specification that builds on HTML, providing additional markup that can be used by assistive technologies, such as screen reader software, to allow users to access and manipulate dynamic web interface elements developed using Ajax, JavaScript, HTML, and other technologies. For development teams, ARIA may seem like just the thing to bridge the perceived gap between what’s possible with native HTML elements and what’s desirable for interaction design, as a means to make complex interactions accessible for people with disabilities. But even proponents of WAI-ARIA encourage you to first exhaust options for native HTML elements. In the W3C document Using WAI-ARIA in HTML, the “first rule of ARIA use” is:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state, or property to make it accessible, then do so.

This is due in part to the overhead that comes with creating and maintaining custom controls. The following list details all the aspects you must validate and maintain with custom controls—attributes that are available out of the box with native HTML elements. Controls that do not have these attributes will not be usable by some users.

Guiding interaction

A central goal of any design is to be self-explanatory—to tell people how to interact with functional elements. For web forms and interactions, design should guide users through the functional elements of the page and, using instructions, labels, prompts, and design patterns, explain what is expected and how the page works. The designer’s role of benevolent guide is critical to user success—more important in some ways than the design of the functional elements themselves. With gentle guidance, users can recover from mishaps better than when they have to puzzle out a confusing interface on their own.

Labels

Control labels must convey enough information to users, such that they know what will happen on activating the control. A clear sign of failure is if the user must activate the control to determine its purpose—similar to needing to follow a link to ascertain its destination. Icons can be effective labels when they are easy to decipher, either because their meaning is clear or because they are familiar, such as the text formatting icons used on most text editor toolbars. When the meaning is not clear, icons are best paired with descriptive text. The icons are easy to visually scan and recognize, and the text provides additional clarity about the purpose of the control.

For form fill-in, labels are essential guides, telling us what information to provide in form fields. HTML provides a means to attach form labels to form fields, so there is never any mystery about what information is being requested. The <label> element associates a label with its element using the id attribute:

<label for=”departdate”>Departing (YY/MM/DD):</label>
<input type=”text” id=”departdate” />

When form fields are marked up with labels, the relationship of label to field is available to software. For example, screen reader users can enter a form field and hear its label, along with any instructions contained within the label. Without the label, that information must be gleaned from browsing the surrounding text.

Do not use “placeholder” text for essential information, such as the field label. Placeholder text is appealing because the text displays within an input field and can provide guidance without using precious screen space. However, default text disappears when the user activates the field to enter information, which is just when the instructions are needed most. (Was that year, month, day, or day, month, year?) Also, placeholder text typically displays as low-contrast gray text on a white background, making it difficult to distinguish. Placeholder text is intended to be an auxiliary aid, to help with data entry. If the information is essential to successful form completion, put it on the screen, alongside the corresponding form element, so that everyone can benefit from it.

Help and instructions

Contextual help offers answers and guidance within the context of the page rather than sending the user to a help section of the site. A common implementation of this is through a “?” icon next to a new or potentially confusing feature. Contextual help is often provided via a dialog, panel, or tooltip. This method allows users to get help without having to deviate from the task at hand.

A web form often needs to provide instructions beyond simple form labels. Some types of information, such as dates and credit card numbers, for example, need to share a standard format. Ideally, the user can enter the information in a variety of formats, and the system will be smart enough to reconfigure the information to the required format. In reality, however, not all our systems are that smart, in which case we need to ask the user to enter the information in the required format. A date, for example, can be entered in a variety of formats, but your back-end system architecture may require a specific format, such as year, month, and day. Provide an example in the field label, for example, “Departing (yy/mm/dd).”

Feedback

The best way to handle errors is to keep them from happening. For example, users unintentionally delete files. One way to prevent this is to ask users to confirm their choice every time they ask to delete a file, which can quickly turn into nagging. A better approach is to allow users to go ahead and delete but to save all deleted messages in a location where they can be readily retrieved. Google keeps deleted files for its web applications in a Trash folder. It’s only when you elect to empty the trash that you are prompted to confirm your intention. Not all errors can be prevented, however, and interaction design involves responding to errors in a way that is informative and helps users get back on track.

Error handling can happen on the server, after the user submits the form, or inline on the client, as the user interacts with the form elements. Feedback in the server-side model typically takes the form of a returned page with an error message indicating that the form was not successfully received.

Inline error messages provide feedback as the user works through a form rather than after the fact, on submission—for example, a form with required fields where the fields are monitored and feedback is provided to the user during form completion, and the “submit” button is disabled until all required fields have been completed. Inline feedback is more usable than after-the-fact feedback because users can respond to errors as they work through the form rather than having to ascertain which form elements are in error, fix the error, submit the form again, and hope for the best. Instead, users can fix errors as they occur and feel confident their submission will be successful.

When an error does occur, let the user know in a way that is helpful. Provide specifics about what happened: “Your password is incorrect” rather than “Your username and password do not match.” Provide the explanation adjacent to the field in question—in this case, next to the password field. Ensure the error messages are accessible to assistive technology by encoding name, role, and state information into error messages (see section on responding to errors, above).

In responding to errors, make sure your error messages are tuned to users’ needs. Error messages are too often written in programmer speak, either too detailed and specific or too vague, offering little in the way of explanation and guidance on where to go next (“Operation failed: try again”). Give users just enough information about what happened. They don’t need to know that the error number is 404, but they do need to know that the page they requested cannot be found on the server. Provide guidance about what to do in response to the error. If the page cannot be found, offer search and a site map to help the user find it, along with links to the main sections of your site. And a little humor is always welcome.

Widget design patterns and libraries

The best designs use a common language for guiding interactions with digital products. Products that follow established patterns allow people to engage easily, and to successfully achieve their goals, without the overhead of learning how to work a new widget or control. For usability, there is little room for innovation when providing features that already have well-known and -understood interaction patterns.

Widget and pattern libraries are excellent resources to ensure that you are meeting user expectations in your interaction design. Design patterns specify what attributes are needed for different types of interactions. Widget libraries provide code and supporting resources you can download and embed in your projects.

Information Design

Concepts about structuring information today stem largely from the organization of printed books and periodicals and the library indexing and catalog systems that developed around printed information. The interface standards of books in the English-speaking world are well established and widely agreed upon, and detailed instructions for creating books may be found in such publication standards manuals as The Chicago Manual of Style. Every feature of the printed book, from the contents page to the index, has evolved over centuries, and readers of early books faced some of the same organizational problems that users of hypermedia documents confront today. Johannes Gutenberg’s Bible of 1456 is often cited as the first mass-produced book, yet even after the explosive growth of publishing that followed Gutenberg’s invention of printing with movable type, more than a century passed before page numbering, indexes, tables of contents, and even title pages became expected and necessary features of books. Web documents are undergoing a similar—albeit faster—evolution and standardization.

Although networked interactive hypermedia documents pose novel challenges to information designers, most of the guidance needed to design, create, assemble, edit, and organize multiple forms of media does not differ radically from current practice in print media. Most web documents can be designed to conform to Chicago Manual of Style conventions for editorial style and text organization. Much of what an organization needs to know about creating clear, comprehensive, and consistent internal publishing standards is already available in such general publishing style guides as the Franklin Covey Style Guide for Business and Technical Communication and The Gregg Reference Manual. Don’t get so lost in the novelty of web pages that basic standards of editorial consistency, business communications, and graphic design are tossed aside.

Designing information

Web pages differ from books and other documents in several crucial respects: hypertext links allow users to experience a single web page separate from its context. For this reason web pages need to be more independent than pages in a book. For example, the headers and footers of web pages should be more informative and elaborate than those on printed pages. It would be absurd to repeat the copyright information, author, and date of a book at the bottom of every printed page, but individual web pages often need to provide such information because a single web page may be the only part of a site that some users will see. This problem of making documents freestanding is not unique to web pages. Journals, magazines, and most newspapers repeat the date, volume number, and issue number at the top or bottom of each printed page because they know that readers often rip out articles or photocopy pages and will need that information to be able to trace the source of the material.

Given the difficulties inherent in creating web sites that are both easy to use and full of complex content, the best design strategy is to apply a few fundamental document design principles consistently in every web page you create. The basic elements of a document aren’t complicated and have almost nothing to do with Internet technology. It’s like a high school journalism class: who, what, when, and where.

Who

Who is speaking? This question is so basic, and the information is so often taken for granted, that authors frequently overlook the most fundamental piece of information a reader needs in order to assess the provenance of a web document. Whether the page originates from an individual author or an institution, always tell the reader who created it and what institution you are associated with.

What

All documents need clear titles to capture the user’s attention, but for several reasons peculiar to the web, this basic editorial element is especially crucial. The page title and major headings are also crucial for search engine visibility. The page <title> element is the most important determinant of keyword relevance for search engines, so craft your titles carefully if you want users to find your content.

When

Timeliness is an important element in evaluating the worth of a document. We take information about the age of most paper documents for granted: newspapers, magazines, and virtually all office correspondence are dated. Date every web page, and change the date whenever the document is updated. This is especially important in long or complex online documents that are updated regularly but may not look different enough to signal a change in content to occasional readers. Corporate information, personnel manuals, product information, and other technical documents delivered as web pages should always carry version numbers or revision dates. Remember that many readers prefer to print long documents from the web. If you don’t include revision dates, your reader may not be able to tell whether the version she has in hand is current.

Where

The web is an odd “place” that has huge informational dimensions but few explicit cues to the place of origin of a document. Click on a web link, and you could be connected to a web server in Sydney, Chicago, or Rome—anywhere, in fact, with an Internet connection. Unless you are well versed in parsing URLs, it can be hard to tell where a page originates. This is the World Wide Web, after all, and the question of where a document comes from is sometimes inseparable from whom the document comes from. Always tell the user where you are from, with (if relevant) your corporate or institutional affiliations.

Incorporating the “home” URL within the page footer is an easy way to maintain the connection to where a page originated. Once the user has saved the page as a text file or printed the page onto paper, this connection may be lost.

Every web page needs:

Most web pages should also incorporate these additional elements:

Include these basic information elements and you will have traveled 90 percent of the way toward providing your users with an understandable web user interface.

Mobile Interface Design

Mobile Internet technology is one of the fastest-growing and most exciting areas of modern computing and mass communications. In 2014, 58 percent of American adults owned a “smartphone” capable of running sophisticated applications (“apps”), and worldwide the number of Internet-connected devices exceeds the number of people; that number is expected to climb to more than 1.4 devices per capita by 2016. Although we call them “phones,” our smartphones and cellular-enabled tablets are actually powerful small computers that also happen to be able to make “phone calls” (two-way radio communications, really). Although smartphones and tablets can now do things that only powerful desktop computers could do just a few years ago, there are many practical, physical, and cognitive constraints on mobile users that affect virtually every aspect of the user experience with the tiny computers most of us carry around every day.

When mobile computing and smartphones became common after the introduction of iPhones and Android phones, most web designers and interface experts advocated special mobile-only sites that were stripped-down and simplified versions of full “desktop” web sites, on the notion that the typical mobile user was a harried, distracted person “on the go,” who needed just a few basic services and points of information, and that any “real” or complex interactions would get done later on a laptop or desktop computer. In fact, it quickly became apparent that most mobile users wanted a full user experience from most sites, that they were not always on the go when using their smartphones, and that for about 31 percent of web users the smartphone is the primary computing device.

Luckily this evolving sense of the mobile user coincided with two other important trends in web design: the rise of “responsive” web design using the new screen-sensing and layout capabilities of CSS3, and “mobile-first” content and design strategies that recognize that most of us now live in a multiscreen, multidevice world where sites should “respond” in intelligent ways to multiple sizes of displays and many kinds of usage situations. A decade ago it might have made sense to start your new site design with fixed-width sketches in Photoshop. That kind of desktop-oriented fixed-width thinking is irrelevant to current realities in a world where the average person uses many sizes and shapes of screens every day.

Today it makes far more sense to view typical use cases or “user stories” within a continuum of screen sizes or “viewports,” where in a typical day a person might do a quick review of a few emails on a smartwatch while getting up in the morning, check her regular news sites on a smartphone during the morning commute, review dozens of sites in a typical workday on a desktop computer with twin large monitors, and also review yet more sites from a laptop or tablet while attending a business meeting.

Designing the mobile user experience

Mobile user experience design is not too different from traditional forms of web design for larger screens, but almost every usage constraint and potential user experience problem is amplified by the difficulties of working in a small-screen/touch-screen environment. The increased cognitive load that small screens, mobile-use contexts, and small touch targets create is considerable, and calls for special attention to mobile design beyond just rearranging your content layout for smaller screens.

Mobile context

Although many mobile device users access their phones and tablets under quiet, controlled conditions, much of mobile computing is done in potentially distracting environments where intermittent use and disruptions are common, and even simple tasks are harder to accomplish than in the desktop world of larger screens, physical keyboards, and mouse or touchpad pointers. Aside from environmental challenges, small screens also impose more cognitive load on the mobile user because the increased scrolling needed tends to hide important navigation or content in the off-screen areas, forcing users to remember more about content or controls they have already scrolled past.

Make sure that information handy to mobile users is prominently displayed or easy to find in the mobile view of your site. Street addresses or store locations are important for local shoppers, and your phone number should be easy to find and click for no-dial access on a smartphone. Mobile conversion (visit and purchase) rates are about five times as high on tablets as on smartphones (5 percent versus 1 percent), suggesting that cognitive load, payment challenges, and other awkward logistics are still major issues in small-screen mobile web shopping.

Components of mobile UI

Mobile style sheets often simplify site headers and navigation for mobile displays, but navigation remains critical for mobile users. While simplification is generally a good mobile strategy, if you remove too many “you are here” cues and navigation links, the mobile user has no choice but to continually bounce between the home page—often the only available landmark in many mobile presentations—and pages deep within the mobile site. Footer-based navigation links can be a way to provide more navigation choices without cluttering the top of a mobile page.

The mixed desktop, tablet, and smartphone page-navigation metaphors define an emerging problem in mobile design. Don’t mix up desktop and tablet interface metaphors: tablet users are accustomed to horizontal “swipe” gestures in mobile app content and ebooks, but desktop web and mobile phone web users are not. Most responsive sites and desktop web sites use vertical scrolling.

Desktop screens are almost always oriented horizontally, but mobile devices offer equally convenient portrait or landscape modes, particularly with tablets and very large smartphones. Portrait versus landscape usage is about evenly split among tablet users, with about 54 percent of tablet users preferring the landscape mode of viewing web content. However, mobile phones tend to be held vertically by most users—as seen in the myriad vertical videos and “selfies” on the web—and therefore mobile web layouts should assume a portrait orientation for most use cases.

True “responsiveness” in the mobile environment means a lot more than just rejiggering your content boxes for smaller screens:

Also, you should assume that your mobile web users are competent adults who are doing exactly what they prefer to do when they look at your site in a mobile web browser. Don’t constantly nag mobile web users to switch to the “app” version of your content, or pop up annoying windows that advertise your mobile app. Offer the app alternative as a lower-key link or banner ad instead.

Screen sizes and orientations

The physical size of a mobile touchscreen has important usability design implications, because although screen sizes are quite variable, our fingers and thumbs are the same size they always were, and interface layouts that work very well on a small, vertical smartphone screen might prove to be awkward on a tablet with a much larger screen. This is particularly true for users who hold their tablets in both hands and manipulate virtual keyboards or buttons with their thumbs. The larger size of recent smartphone screens is also posing a challenge to one-handed touchscreen users, whose thumbs are too short to reach across the expanded screens dimensions.

As screen sizes increase, Fitt’s Law begins to operate in a more significant way in mobile interfaces. Fitt’s Law describes a universal constant in graphic interfaces: the time required to acquire a target and to use the target to take action is a function of the distance to and size of the target. In other words, small distant targets take more time to find, and may not be noticed at all. Clickable targets like buttons may benefit from slightly enhanced sizes in various responsive mobile designs, to be noticed, and on small screens to provide a large enough target to touch accurately.

Enterprise Interface Design

The web can provide a powerful framework for promoting group cohesion and identification with the large missions and goals of an enterprise, but only if the user interface, information architecture, and graphic design of the enterprise’s web sites consistently promote a common purpose and shared identity across all the major elements of the public-facing web sites and the organization’s internal sites and intranet. Most large corporations have well-established corporate identity programs that now include comprehensive web design and interface standards.

Providing a cohesive experience

Many smaller companies, federal, state, and local government sites, college and university sites, and nonprofit institutions produce chaotic, poorly organized web sites because the institutions lack consistent, widely implemented web publishing standards. Nobody sets out to produce a chaotic enterprise web presence, but an insistence on trying to optimize each individual site within the larger organization is a guarantee of disorder and confusion for users. You can’t optimize a library by writing a great book, and no single web site—no matter how well designed—will ever improve an enterprise’s overall web presence.

The only long-term approach to improving an organization’s web presence is a consistent approach to web interface design, one that explicitly recognizes the larger context of the enterprise and the web in general. Ideally this set of consistent standards becomes the “enterprise interface” across all forms of web information publishing and web-based access to applications. In today’s large organizations, web content can flow from dozens of major information sources. A consistent, comprehensive approach to the enterprise interface is the best way to maximize the return for the enormous investments that companies make in web publishing and web applications.

A chaotic web presence sends one consistent message about an organization: contempt for the user. Users spend 99.99 percent of their time on web sites other than yours, and potential readers couldn’t care less that you want your little part of the larger site to look unique. If your organization has web standards, always incorporate them into your site design and user interface. If you don’t have standards, lead an effort to create them. Research on the most effective corporate intranets and portals shows that users are most productive, most efficient, and overwhelmingly more satisfied with sites that employ a consistent, comprehensive interface and design standard throughout the organization’s web presence.

Coherence

A coherent interface presents the enterprise clearly and comprehensively, conveying an understandable picture of the organization’s structure and functioning, products and services to clients, internal communications and management policy, and overall mission and goals. Building a legible, easily navigable corporate web structure is more than just a graphic user interface issue. A well-structured site rich with useful content directly represents the depth and breadth of an enterprise more comprehensively than any previous medium.

Symbolism

As networked work environments have become the norm and various forms of telecommuting and remote access are routine, web-based work environments are the dominant force in creating and maintaining the corporate ethos, attitudes, and values. For most employees the organizational web presence has become the most visible and functional evidence of social cohesion and common purpose across the enterprise.

Positioning

A clear and recognizable identity program helps distinguish an enterprise from peers and competitors. This is especially critical on the Internet, where everyone has a web site and all web sites appear in the same limited venue (a browser window on the user’s screen). A user may visit a dozen organizational sites in a browsing session and be exposed to many graphic themes. Web users’ expectations of the Internet as a communications medium are determined mainly by what they have seen in other sites, and what they’ve seen is mostly like confetti: weightless, colorful, and chaotic. Will users remember your pages if your site looks like nothing else they’ve seen in your larger enterprise?

Cohesive, comprehensive design transcends immediate commercial objectives. Enterprises need to differentiate themselves not only in the products and services they offer but also as social entities. In too many corporate, university, and government sites, the lack of a comprehensive group identity and shared sense of mission is made painfully obvious by the chaotic condition of their web sites. An effective web presence can be a powerful tool for enhancing the status and competitive positioning of an enterprise, but only if the web site effectively projects a feeling of trust in the knowledge and competence of the organization that produced it.

Recommended Reading

Figures from Chapter 7: Interface Design on Flickr