articles

Introduction to Interaction Design

By Theresa Wilkinson, W-edge design
With Jennifer Square
Reprinted with permission from the STC Intercom magazine - July/August 2003 Volume 50, Issue 7.

I recently ran into a fellow STC member, Jennifer Square, in the elevator of a large company where I am contracting. We didn't have much time to catch up, so Jennifer e-mailed me later. Her e-mail signature contained an intriguing new job title: interaction designer. I had heard of interaction design but had never known anyone who actually did the work. I wondered what disciplines it encompassed. Was it just something that all good Web designers did anyway, unconsciously? How did it differ from information architecture? Did I do this in my job without realizing it? Was it something I could list on my résumé?

In this column, I will define interaction design by comparing it to information architecture, a related field. I'll also share Jennifer's description of interaction design.

Information Architecture vs. Interaction Design

Let's start with information architecture, since many readers are probably already familiar with it. In Information Architects (Graphis, 1996), Richard Saul Wurman defines an information architect as someone who "organizes the patterns inherent in data, making the complex clear" and "creates the structure or map of information which allows others to find their personal paths to knowledge." Although most information architects are Web designers, many technical writers also have experience in information architecture. And any technical communicator who puts the user's needs first shares the most important concern of information architects.

When I was a technical writer, I did a lot of information architecture work by organizing manuals in a manner I thought the user would find logical, grouping information together, creating indexes, and developing online help systems. I user-tested one of my manuals several times and, armed with feedback, honed the information so that my manual reduced the time to get an enhanced product up and running (and making money for my employer) from three weeks to a matter of hours. I did this work for many of the Web sites I developed. I was not aware that I was doing information architecture, because I had never heard the term. But my information architecture skills helped me succeed as both a writer and a Web designer.

In his article "Names are for tombstones, baby," George Olsen explains how interaction design differs from information architecture: "Information architects are concerned about the structure of the content," while "interaction designers are concerned about the structure of the behavior." Despite this difference in emphasis, the duties of most information architects and interaction designers overlap. Some Web designers, for example, not only design and define the site layout, navigation, labels, and site content but also build and code the site, and identify areas where the site could function better.

Interaction designers are concerned with how an application or Web site functions. They investigate whether the application or Web site performs the intended task in a predictable manner. They ask questions such as, "Does the Save button save the information or give you an error message?" and "Does the shopping cart on the Web site actually register the items when the user clicks the 'Add this item to the shopping cart's button?"

Another helpful description of interaction design comes from Dave Donaldson, an information systems technical specialist in Columbus, Ohio, who has worked with interaction designers. Dave tells me that interaction designers "identify the behaviors of an application to help drive the design and development. They bridge the gap between the user interface and development. They will take a wireframe and mock up the screen in HTML to help anticipate unexpected and expected behaviors. They can identify early in the process how an application will behave, which tells the designers and developers how they should design the system. Thus, the developers design a system the way it should behave, not the way the developer thinks it should behave."

An Insider's View of Interaction Design

Following is Jennifer Square's description of an interaction designer's duties:

Each day, an interaction designer battles deadlines, politics, personalities, and conflicting interests. You might ask, how is this different from anything else at work? But as a writer, you probably weren't in the spotlight; you probably weren't making too many waves. You probably did not have to make sure everyone approved of your work. In many ways, you were probably a lone ranger of the writing territory. If you changed a word here or there, nobody noticed.

As an interaction designer, you, your career, and your credibility are in the spotlight. Your work is where the rubber hits the road. Everyone (managers, leaders, customers, the engineering and marketing departments) sees and experiences the user interaction. If you make a mistake, chances are someone will find out about it, and someone will let you know. If you have a success and users love your application, someone else will inevitably get the credit. You must work and negotiate solutions with business teams, systems teams, and end-users. You must see the big picture, create the vision, or write the strategy, but you also must worry about text and style: For example, should your manuals hyphenate "e-mail" or not?

You have responsibility for a lot: understanding the capabilities of the technology and its behavior, business processes, the user's goals and tasks, and the vision or goal state of your application. Your main focus is not colors, fonts, or anything involving the user interface design. Interface design is much like packaging in retail. Interaction designers should leave the fonts and colors to the graphics design group. Your primary goal is to understand the application's behavior and the capabilities of the technology, and make sure that the behavior is the primary deliverable. You also have to keep the vision of the application in mind, as managers, leaders, and other people will say, "We need to deliver, so what's the best solution for today?"

Interaction designers are also responsible for making sure that technology is used for business process improvement and does not recreate confusing and outdated mainframe paradigms that may have been used in previous applications. Understanding all of this can be accomplished by simple contextual inquiry with your own eyes. It is therefore important that interaction designers camp out with users to see how their work is accomplished.

Thinking Like a User

The most important skill for both information architecture and interaction design is knowing how to think like a user. You need to constantly ask yourself how users would find information and use the system or product. Since most tech writers already think this way, they have a good foundation for success in either of these fields. In my next column, I'll discuss how you can justify interaction design at your company and perhaps move into a new career.

References

Baxley, Bob. Introducing Interaction Design," Boxes and Arrows.

Heller, David. "Why I'm Not Calling Myself an Information Architect Anymore," Boxes and Arrows.

Marion, Craig. "What is Interaction Design and What Does It Mean to Information Designers?"

Morville, Peter, and Lou Rosenfeld. Information Architecture for the World Wide Web. Sebastopol, CA: O'Reilly & Associates, 1998.