Common Sense Rules for Interaction Design

After three years working with online commerce, I've noticed some common sense rules about designing the commerce interaction. I've been consulted on the "head scratcher" customer complaints, I've spent countless hours placing test orders and testing code revisions, and I've tracked and campaigned for the resolution of problems over the course of years, and I'm still amazed at how much trouble people can have with even the simplest of interface functions. The lesson is that any interface requires ongoing and devoted attention, because when users have trouble with an interface, the interface is usually to blame.

The design and architecture for a commerce site can be complex, as long as it is necessarily complex. I've listed my rules for successful commerce interaction design.

Designers Work Hard, So Users Don't Have To

Designing (and programming, implementing, and especially testing), is difficult work, requiring mastery of a slew of technical skills. Building a super user experience may be quite difficult, and building it correctly may be too difficult for mere words to describe, but -- hey -- without a positive user experience your users will click away, never to return.

Users should not have to spend much time learning a new system, a new lexicon, a new set of patterns and rules and iconographies, just to buy something on the web.

Designers (and programmers, implementers, and especially testers) work hard so that users don't have to.

Provide Plenty of Choices

It doesn't mater if the best minds in the world have come up with a hyper-intuitive interface. In the first place, the property of being intuitive doesn't adhere to non-human things -- only people are intuitive. Interfaces can be intuitable, that is, easy to learn and understand, but such interfaces are actually pretty rare. Somebody will have trouble with even the greatest and bestest and most intuitable interface, guaranteed.

In the second place, user interfaces are intended to be used by users; designers, coders, and developers are not true, real-life, fresh-off-the-street users. These experts are much too close to the project to correctly orient themselves from the perspective of either a beginner or a goals and tasks driven end user.

Any attempt to construct the single best method to complete any task and achieve any goal is unlikely to succeed because end users are not all alike. End user baggage ranges from unfamiliarity with computers to unfamiliarity with the web to unfamiliarity with the concept domain. End users are not stupid, but they can come from a bunch of very weird places.

People are different. People possess a wide range of attitudes towards, well, everything. Introverts vs. extroverts, happy vs. sad, left-brainers vs. right-brainers (vs., no-brainers), dog lovers vs. cat lovers. People are so different, that it's difficult to predict exactly what will make any particular person satisfied -- and of course, any particular person's satisfaction threshold may vary when mapped across time.

So, provide multiple solutions to any problem, multiple tools for any task. Some simple ideas:

If you have a document or data collection, provide different ways to query against it. Provide separate interfaces for simple search and advanced search. Don't focus so much on restrictive field searches.
Allow for searches and index or table of contents browsing.
For commerce sites, allow multiple pathways through your commerce functionality. Many sites provide a standard set of steps to complete transactions, and provide shorter sets of steps for people who register and save some of their information in a profile.
Provide the ability to edit and change saved information from different places and from different steps in a transaction.

Use Predictive Logic

Use predictive logic to guess what information the user will need to have available in the interface. At any step in a commerce interaction, the user will be faced with decisions -- make sure that only those decisions relevant to the tasks at hand are enabled or supported. For example, if a user is at the last stage in the commerce flow, and is faced with the form for credit card information, don't provide the user with superfluous options for exiting the page. Don't place a link for "What's New Today", don't place a link to the chat room, don't place anything that is not important or reasonable to this particular stage in the commerce transaction.

True predictive logic would be built into the system, so that pages are served and options populated based on user-specific states and modes, but in truth most predictive logic is applied by a designer or architect during the creation of the system. Examine the necessary steps and decide just what should be available on each page. Identify the flows or paths through your commerce functionality, and trim the information "eye-candy" from those paths. Remove anything that would distract the user from completing their purchase.

Systematically, move logic checks and error handling forward in the process. If form data will be validated at the point of order submission, and can potentially fail the submit if data is incorrect, try and check before the point of submit. If a user must enter in a shipping address on one screen, and then enter in credit card information on another screen, and finally submit the order on yet another screen, don't fail the order if the zip code doesn't match the state code -- check for state-zip compliance when the address is entered.

Remove Obstructions

Obstructions are barriers or impediments that interfere with a user's ability to complete a task or accomplish a goal.

Some common examples of obstructions are broken links, broken pages (pages that show up blank or with unreadable code), and broken CGIs or applications. These kinds of problems should be caught during standard quality assurance testing; after all, these problems speak to the most trivial definition of code quality: does the code work?

Some less obvious obstructions are commerce flow problems, confusing form control arrangement or labeling, and excessively specific search logic. These kinds of problems should be the responsibility of a proactive quality assurance team involved at all phases of the design and development process. Ask the questions "can our users understand this interface?" and "can this interface be made simpler?" and you've started to address such usability-based obstructions.

I find that obstructions such I've described here fall into two rough flavors, differentiated mainly by degree and intention: arbitrary obstructions and inadvertent obstructions. Arbitrary obstructions are usually the result of somebody making a decision for you, without your input. Any application you buy off the shelves of a software store will have rules that you just don't understand or just plain don't like. Dismiss such concerns as due to the historically bad usability of shrink-wrap software, but the fact is that somebody defined the behavior and interface logic, and that somebody wasn't you. Web sites and web-centered software are not immune from arbitrariness:

When the Borders.com site was first launched, the system architects from our contract implementation company used a three server system, with a standard web server assigned to port 80, a secure server assigned to port 443, and a third server running CGI programs on port 8080. According to the Internet Assigned Numbers Authority, ports 80 and 443 are both legal and valid for their role -- no problems there. Port 8080 is also a valid HTTP port assignment, but the problem is that this is a little known port, and many system administrators close this port down when configuring firewalls. With the port closed down, no data from this port address at a web server is allowed through the firewall. So for Borders.com, that meant some customers behind firewalls were denied access to our process on that port, specifically search! The fault was not ours, but belonged to those less experienced sysadmins. The original design decision was ill-advised though technically justifiable. The architecture was fixed when Borders realigned the port assignments with a reverse proxy.

Inadvertant obstructions come from decisions too, but these are usually more mundane issues. Putting content headers into graphical text is a very common annoyance, hiding important information out of the reach of text parsers and text-only viewers. Cramming too much information onto a page in search of the perfect "portalesque" experience makes finding the right information needlessly hard. The decision to lay out a page using tables burdens those users who can't display tables -- what do blind users do with a table-structured page that's read aloud?

I built philosophe.com using two tables side-by-side, rather that one table with two columns, precisely because columns are meaningless to some users. With these two tables, if a non-table-rendering device is used, the first block of information, which is the left navigation list, displays first -- this is fine, makes the page a little long perhaps, but it is still usable as a table of contents. The second table contains the body content, and displays after the first table. This might be long, but it is parse-able.

At a very simple level, any problem that interferes with users' completion of their tasks is an exclusionary problem; I believe that the core role of a web quality assurance team is to identify anything about the site that will exclude a user or set of users. Any exclusion should be a purposeful exclusion -- restrict your users according to conscious decisions, not by accident or happenstance of code style. A quality assurance team should understand its web site's audience well enough to know its needs, and should understand its web site architecture and code enough to know its limitations and inabilities.

Accommodate Common Behaviors

The very nature of the web and its attendant protocols allows users to control much of the display and rendering of web pages. A user can specify the font type, font color, font size, background color, link (vlink, alink) color, and other less common display-based tweaks. A user can turn off the display of graphics.

Users can specify what level of SSL the browser will accept, what secure certificates are permissible, and whether to allow the transmission of data over non-secure channels. Users can choose to accept or refuse cookies, and whether to enable JavaScripting.

And of course, some browsers and/or systems don't support certain functions. When was the last time you ran a Java applet on a Windows 3.1 box?

Study your audience and their common behaviors, because if you create a barrier that blocks browsers with certain user-specified configurations or limits, you will interfere with the interaction experience of some of your users.

Here's an example of an arbitrary obstruction and failure to accommodate common configurations: Net.commerce 2.0 doesn't support command chaining, so in order for a commerce application to perform several functions in a row, a new function call must be made to each functions code module. Let's say you have an order online form where a customer enters in credit card information and submits the payment, and say you one function that validates the format of the payment information (card number algorithm, required elements, etc.) and another function that passes vetted information to a middleware application. Without command chaining, you can't perform a data check and then pass the data to middleware, you must instead perform the first function, and then create a call to the second function. Net.commerce 2 requires the web server to request a page that calls that second function. Specifically, the sequence would go like this: form submit calls function 1 which outputs an HTML page which has a JavaScript page reload that calls the second function.

Ah, but what if the user's browser doesn't support JavaScript or has JavaScript turned off? The user can't complete an order.

Provide a Reasonable and Appropriate Interface

Any interface should be appropriate, which means that an interface should be designed to accommodate the expected users, their goals, and their tasks. This is commonsense in theory, but often difficult in application because designers and coders can get so close to the creation of the interface that they lose track of the actual user. Work around the clock on a design and you'll never notice that your neutral stance has slipped away and you're actually coding for your own understanding and experience level.

An interface designed for people new to the interface, or to the domain, or to the internet in general should not be especially complex; an interface designed for programmers with long familiarity with command-lines and shell-scripts probably shouldn't rely heavily on cartoon characters or verbose inline help text.

Any interface should also be reasonable, which just means that the interface shouldn't be too extreme, unless the nature of the interaction is extreme -- a blood-and-guts high-twitch video game would be understandably extreme.