- developers’ failing to implement products as designed—Why a company would invest in good interaction design, then squander their investment by allowing developers to ignore design specifications is inexplicable. However, this happens all too frequently in Engineering-driven organizations. Powerful engineers may override UX Design—sometimes even at the expense of sacrificing business goals or doing what would be best for a company’s well-being and continued existence. Overcoming this challenging problem requires evangelizing the value of user experience to business leaders, organizational change management, persuading developers to implement our designs, and educating our peers in other disciplines about good design principles and guidelines.
- designers’ inadequately specifying behavior—It sometimes happens that excessive time pressures prevent designers from modeling, designing, and specifying behavior adequately. However, we can overcome this problem by helping our product teams manage the scope and schedules for projects. Unfortunately, inadequate behavior specifications too often result from poor design documentation standards and practices or designers’ inability to clearly communicate behavior. Solving these problems is solely the responsibility of UX Design and is the focus of the remainder of this column.
Making Time for Specifying Behavior
To ensure time pressures don’t prevent designers from specifying behavior adequately, try doing the following:
- Encourage your development team to adopt an agile development process, which minimizes shifting requirements and the unpleasant consequences they can have for designers’ schedules. (Of course, the challenge an agile process poses for designers is the need to envision a holistic design solution, while designing only small parts of a product during a given development cycle.)
- Ensure designers have adequate time during each development cycle to produce high-quality interaction design documentation by balancing the scope of requirements and the duration of each cycle.
- Create resources that make the production of design specifications more efficient, including templates for interaction design specifications, design patterns, design guidelines, style guidelines for specifications, image resources for standard icons and controls, and boilerplate text—both for specifications and for user interface elements like interactive user assistance and error messages.
Taking Responsibility for Designing and Specifying Behavior
Some deficiencies in the quality of interaction design documentation today could be attributable to the fact that, before the Web, few designers got the opportunity to design elements of operating systems’ user interfaces. The designers who specified those user interfaces were responsible for the majority of all interaction design, and their companies produced the detailed UX guidelines that documented the standard interface elements, interactions, and behaviors everyone else used in their user interface designs. Designing an application’s interactions using standard interface elements did not require very detailed interaction design specifications, because their behaviors were standard, well known, and often implemented in existing code. Of course, designers also needed to design some unique interactive elements for most applications, and their designers were responsible for providing detailed interaction design specifications for those elements.
Ajax was a game changer. Initially, there weren’t standards for any Ajax interactions—though many emulated operating system standards. The innovative interaction models Ajax enabled and the complex rich Internet applications (RIAs) that used them needed very detailed interaction design specifications. It soon became apparent that annotated wireframes were inadequate for documenting such complex interactions. But the use of wireframes for Web application design has persisted. Often wireframes omit many essential details of complex Ajax interactions and behaviors. When interaction design documentation fails to specify the behaviors of applications adequately, designers abdicate detailed interaction design to the developers. It’s time to take back responsibility for detailed interaction design!
Interaction Design Deliverables
In my experience, there are only three types of interaction design deliverables that adequately express behavior for implementation by engineers:
- storyboards—Whether a designer produces a series of high-fidelity screen images or wireframes, storyboards should show every state for an application user interface in sequence. To describe interactions and behaviors adequately, storyboards must be heavily annotated. However, if the annotations for each screen or wireframe are limited to a single page, the space constraints pages impose can make it difficult to include sufficiently detailed documentation or, if you use oversized pages to make room for all the necessary information, the storyboards can be hard to print or, for remote teams, to view online. Plus, it’s difficult to express animations and transitions in words.
An Example of What Could Go Wrong with Inadequate Specifications
In my column “First, Do No Harm,” I discussed what happens when applications violate design principles such as the following:
- Remember users’ settings. Violating this principle destroys users’ work, so provides one of the more egregious examples of doing harm to users. In that column, I used Comcast’s Fancast Browse TV Listings page, shown in Figure 1, as an example of an application that violates this principle in several ways. This Fancast page does a poor job of saving users’ settings both within and across sessions. In fact, users may have to reset some settings repeatedly during a single session. Among other problems, for example:
- If a user is looking at TV listings for a particular date and time, then has to restart his or her browser, the application does not retain the user’s previous settings for date and time across the sessions.
- Problems with the Date and Time drop-down menus on the Fancast Browse TV Listings page that I’ve described under the next design principle are also examples of failing to remember users’ settings. While these menu settings are usually fairly easy to reset, having to reset them repeatedly becomes annoying.
- Give users a sense of being in control. The Fancast Browse TV Listings page also provides an example of violating users’ sense of control. The order in which the page lets users perform specific interactions is very constrained—and unnecessarily so. For example:
- If a user chooses a time on the Time menu, then chooses a different day on the unlabeled Date menu, the time reverts to the current time—at least it did when I starting writing this column. Now, inexplicably, it’s reverting to primetime, or 8PM.
- If a user chooses a date on the Date menu, then clicks the PRIMETIME link, the date reverts to the current date.
Figure 2 shows the Date and Time menus on the Fancast Browse TV Listings page. These menus exhibit some other basic interaction design problems, as follows:
- The Date menu has no label, but displays the selected date, which is inconsistent with the behavior of the Time menu.
- The Time menu displays its label rather than the selected time, which is inconsistent with the behavior of the Date menu.
- The Date menu is an odd cross between a drop-down menu and a drop-down list, with the selected value appearing on it.
- When a user clicks a date on the Date menu, the date changes, but the menu does not close as it should, so a user must click outside the menu to close it, sometimes repeatedly.
- When a user clicks a time on the Time menu, the time changes, but the menu does not close as it should, so a user must click outside the menu to close it, sometimes repeatedly.
The video in Figure 3 demonstrates some of these problematic interactions. For consistency, both of these menus should have labels rather than displaying a user’s current selection. The current date should appear elsewhere on the page.
I have no idea why the Date and Time menus on the Fancast Browse TV Listings page have these usability problems. While it’s possible there were no designers who were responsible for interaction design on this project, I really doubt it—both because Comcast is a large company and because the visual design is quite good, with the exception of a few elements that don’t align properly in a grid. It’s also possible that this page did not get built as designed. However, it seems more likely that a designer either specified incorrect behavior for the menu interactions or simply failed to specify their behavior at all. Whatever the cause, the Browse TV Listings page provides an illustrative example of how behavior can go wrong. Now, let’s see how we might remedy these interaction design problems.
Redesigning the Date and Time Menus
To provide an example menu behavior specification, I’ve redesigned the Date and Time menus and a few other features of the Fancast Browse TV Listings page that are closely interrelated with those menus, as shown in Figure 4.
As Figure 4 shows, I’ve changed the following elements on the Fancast Browse TV Listings page:
- There was originally no title on the page and, since I’ve removed the display of the selected date from the Date menu, I needed to display the selected date in a new location, so I created a page title that serves both purposes:
BROWSE TV LISTING FOR [DAY], [MON #].
- I changed this text and moved the text to a new location:
Your settings (Change): [ZIP code] OR
When a user is signed in, this text:
Your settings (Change): Comcast - [City] (Digital) [ZIP code]
To: Your settings: Comcast - [City] (Digital) [ZIP code] (Change)
(Note—Change is a link that displays an overlaid dialog box, in which a user can provide a different ZIP code and select a Comcast service.)
- I provided a static label for the Date menu and reduced the width of the DATE menu button, making it the same width as the TIME menu button.
- I adjusted the vertical spacing between the elements, so it’s consistent and a bit tighter. Thus, the new design provides more information without taking up any additional vertical space.
- I adjusted the vertical alignment of all the elements on the same line with the DATE and TIME menu buttons, so they have the same baseline.
- I adjusted the vertical alignment of the label for the CHANNEL menu button, so it has the same baseline as the times heading the columns of TV listings.
- I adjusted the alignment of the times in the grid, so they align with the columns of TV listings.
Note—Some text strings include variable text, which is conditional, so differs depending on state, and appears within brackets. For example, [DAY], [MON #] might be MON, JAN 4, [City] might be San Francisco, and [ZIP code] might be 94123.