Web Anatomy: Introducing Interaction Design Frameworks

by Robert Hoekman

There are two problems that seem to reappear at the beginning of every web application design project.

First, the task of translating a high-level understanding of an application’s goals into low-level design details can be a brutal experience. It’s usually like trying to turn a vapor cloud into a brick wall with one hand tied behind your back and the other one lacking a magic wand. Figuring out where to start can be the most difficult step in the entire process, and even when you think you’ve got it all sussed out, how can you be sure you’re not missing something crucial? How can you be sure you’re truly meeting user needs while you’re busy supporting business goals?

Second, we want to design highly usable and self-evident applications so our customers can be effective, but we also want to devise innovative, compelling, and exciting interactions to dazzle our users and make waves in the market. Sadly, these two things are often mutually exclusive, as “cool” and “usable” can make for terrible bedfellows. And which approach wins is often a circumstance of who’s leading the design: the aesthetics-driven visual thinker, or the usability-minded conservative.

Happily, at the core of the solution to both of these problems is a very simple idea. See, like the human body, every web app is made up of a group of systems that work together to create the larger whole. And each system contains a collection of individual parts, each with its own purpose and function. If we take a close look at the anatomy of successful (and unsuccessful) web applications, we can not only identify the elements that are most typically used to meet user needs in a variety of contexts, but also learn everything we need to know about human psychology to improve upon these standards and take our designs above and beyond without sacrificing usability.

In other words, if we simply look at what’s already working well, and why, we can give ourselves two things we desperately need: a starting point for the design, and insight into to how to create better-stronger-faster interactions that are just as easy to use as the old classics.

The Problem with Patterns

In case you’re wondering, no, this is not an article about design patterns.

See, design patterns can be wonderful tools and should hold a permanent place in every application designer’s arsenal, but they have limitations. Design patterns offer guidelines for the solution of very specific problems. What they don’t do is tell how those problems relate to and affect other problems.

For example, the pagination pattern tell us that search results can be spread across multiple pages simply by adding paginated links to the bottom of each results page. This usually includes a Previous and Next button, as well as numbered links that provide access to the next several results pages, and some sort of visual indication of which page is currently being viewed. A prime example of this appears at the bottom of every Google search results page.

This design is used so frequently by web users that virtually every other search system out there has emulated it, making it a hugely successful pattern that has been documented in countless pattern libraries, both public and private.

But these documented patterns—which we’re supposed to use as a baseline for our own designs-fail to deliver a few key pieces of information. First, why did Google choose to put only 10 search results on each results page? Second, why does Google’s pagination offer links to only 5 subsequent pages by default, and not more? Third, how does it fit into the larger system?

To answer these questions, we can’t look only at the pagination design. We have to look at the whole search system framework. By extension, we can’t rely purely on design patterns for the solutions to all our design ills—we have to look at how the patterns make up systems, and how systems make up whole applications.

In other words, we have to look at the interaction design frameworks.

Solving the Whole Problem

Whereas a design pattern is a common solution to a specific, recurring problem (such as pagination interfaces), an interaction design framework is a set of design patterns and other elements used together to guide the design of a complete system or site context.

For example, as I outlined in my video training course, Designing the Moment: From First Impression to Conversion (Peachpit.com), a “signup framework” is comprised of several design elements, all typically used to encourage users to sign up for an application:

Elevator pitch: a short statement about the app’s value proposition (i.e. Blinksale.com’s “The easiest way to send invoices online”)
Investment breakdown: a quick listing of features and benefits that offers users a sense of how complicated it will be to start being successful with the app
Call to action: statements that tells the user what to do next, phrased as a command (i.e. “Sign up now!”)
Blank slate: the first step in using the application, which should be filled with instructive elements rather than left blank
Conversion form: i.e. a registration form

Each one of these items can, by itself, be considered a design pattern. The “elevator pitch”, for example, is used to quickly and efficiently let people know what a site or application might offer. But although an elevator pitch answers a question in the user’s mind and therefore solves a problem, it’s not a very meaningful problem. Rather, it’s part of a much larger problem—the problem of how to convince people to sign up for your shiny new web application.

Instead of supplying a narrow solution to a narrow problem, frameworks handle more complex problems. They offer guidelines for the design of whole contexts.

When a user arrives at a new site and is trying to figure out whether or not to sign up, the signup framework makes a clear pitch, answers questions, offers a way to get started, and provides a way to register for the site. No single design pattern can handle this. It’s the combination of these elements that really solves the problem.

Identify the elements used by successful sites to solve whole problems and you’ve got yourself a framework to serve as the starting point for your own application. Instead of staring at a blank screen and wondering where to begin, you can write a list like the one above and get started on designs almost immediately.

Above and Beyond

Before you start yelling about how standards are the death of innovation, however, remember that frameworks can also offer insight into how to kick things up a notch or three.

Consider major online retailers. You may have noticed they all use an extremely similar information architecture. On Target.com, for example, if you enter through the homepage, you look around for links related to what you want (i.e. Sports Equipment), identify categories that may offer what you want, scan search results full of products, spot an item you want to know more about, and then you click through to the details page for a better look. (Granted, the high art of Googling has all but eliminated the need to follow this process while shopping online, but that’s a different story.) This basic, core task flow is mirrored on every major retail site on the web.

Why?

Because the online version of the shopping experience matches our long-established mental model of shopping—in fact, it’s practically identical to how we shop in real life. There’s nothing magical about it. Target, BN.com, Amazon, and may others simply supported normal human behavior.

The reason this matters is that someone had to notice the behavior, decide to support it online, and then design something that enabled it. These retailers decided to emulate real-world shopping behavior almost note-for-note, but they didn’t have to. Once they understood the psychology, they could have invented wildly different solutions that solved the problem in a new and exciting way.

And therein lies your opportunity.

The very psychology that led to the design of every standardized solution out there can also lead to other, much more compelling designs. Put this psychology at the center of your decision-making process and you give yourself the ability to design incredible things that still work well for users.

Simply put, the point of a framework is not to limit innovation, but to inform innovation.

Solutions Galore

By looking at the web as a collection of anatomical systems and identifying the ones that relate to your own projects, it’s possible to not only jump-start your design process, but also glean the insights you need to devise cutting-edge solution without sacrificing ease of use.

So give it a shot. Take a look around successful sites and see what they have in common. How alike are their search systems? Account profiles? Persistent navigation? What elements do they all use to ensure users can get oriented? How do they convince people to sign up?

Through frameworks, we get not only clear guidelines based on current standards, we also get a better way to see the possibilities and start putting together superior user experiences.

Published here on February 2, 2009.