Part 1 of a 12-part series about interaction design for web applications
—John Heskett in Toothpicks and Logos: Design in Everyday Life
The focus of this series is on the challenges inherent in the task of translating established product requirements into a browser-based interface. Along the way, we’ll discuss the activity of interaction design as it relates to the Web and the relative advantages and disadvantages of the Web as an interactive medium. In addition, we’ll examine a variety of solutions to common interaction design problems. Although the next eleven articles are already loosely mapped out, if there are particular topics you would like to have covered, please let me know and I’ll do my best to work them in.
And so we’re off. I hope the journey is a fun, useful, and educational one for us all.
We’re in this together
Ours is a world, an economy, and a profession that has embraced the idea of specialization of occupation on a scale heretofore unknown. Where six years ago someone who designed software could readily lay claim to the title “interface designer,” the explosion of the Web and other interactive mediums has split our profession into a variety of increasingly granular specialties.
Although this has sometimes been both necessary and useful, it has also resulted in a cacophony of competing titles, responsibilities, and consulting rates. As a result, even though we all approach our work from the same user-centric orientation, specialists working on one aspect of a design may be ignorant of the issues and compromises being made by other specialists working on other aspects of the design.
In particular, information architecture and interaction design have often been sequestered from one another. Where information architecture has tended to focus on content-centric sites, interaction design has tended to focus on functionality-centric sites. Now however, the two often find themselves in meetings together thanks to the proliferation of websites featuring both large volumes of content and sophisticated functionality.
Therefore, seeing as how we’re going to be in meetings together, it seems only polite to introduce ourselves to one another.
Structure vs. behavior: teasing apart IA and ID
A good place to begin is the definition of information architecture offered up by two of Michigan’s better minds. In their recently published second edition to “Information Architecture for the World Wide Web,” Sirs Rosenfeld and Morville offer a lengthy definition of the field which focuses on four key themes:
- Information
- Structuring, organizing, and labeling
- Finding and managing
- Art and science
Other than the fact that “art and science” is endemic to all forms of design, their definition describes a fairly specific universe of design issues and challenges. In contrast, the field of interaction design concentrates on the following:
- Human/machine communication – At its most fundamental, interaction design serves to translate the conversation that goes on between the technology and the user. In the role of translator, interaction designers are required to understand the subtleties and colloquialisms of both parties, ensuring that they can readily and efficiently communicate with one another.
- Action/Reaction – Not surprisingly, the action/reaction dynamic of interactive media sits at the heart of interaction design. This requires the designer to understand and anticipate how interactions unfold over time, designing for the wide range of permutations that can occur.
- State – As part of its role as translator, interaction design is also concerned with ensuring the user understands the current state of the application. In the same way that humans use body language and social situation to govern and predict behavior, interactive systems communicate state so that users will understand what type of operations are possible or appropriate at any given time.
- Workflow – In addition to facilitating the completion of discrete tasks such as selecting a payment method, interaction design is also concerned with the completion of multi-task goals such as browsing, selecting, and purchasing an item. Like a film director connecting individual shots into scenes, and scenes into movies, the interaction designer uses individual screen elements to create pages, pages to create complex operations, and operations to create a complete application.
- Malfunction – As with all forms of communication, misunderstandings and mistakes occur. Therefore it is also part of the designer’s role to anticipate and mitigate those problems, ensuring that both the user and the system can easily recover.
Well-designed interactive products balance each of these concerns with the respective limitations and capabilities of both people and technology. Such products allow people and technology to carry on a complex and elegant dance relying on multiple, simultaneous forms of communication. The role of the interaction design, therefore, is to choreograph and facilitate the dance in a manner that makes everyone feel like Fred Astaire.
Such choreography, of course, requires an understanding of both the stage and the dancers. As a result, the best interaction designers draw from a variety of disciplines ranging from perceptual psychology to computer science.
Looking ahead
With that brief introduction to the field of interaction design behind us, we can start to examine more specific and thorny topics. Next month’s installment will include a comparison of web applications to traditional content-based sites as well as a consideration of the relative advantages and disadvantages of the Web as an application platform.
While I’m really glad to see a series that focuses on interaction design issues, I’m concerned about a couple of things, and would love to see some discussion:
1. Structure vs. behavior: teasing apart IA and ID
Trying to clearly define these as separate practices doesn’t make much sense to me, and seems to drag us back into the terminology debate that this community loves to rehash.
Isn’t “Structuring, organizing, and labeling” intimately tied to (if not the same as) “understand[ing] the subtleties and colloquialisms of both parties, ensuring that they can readily and efficiently communicate with one another”? Aren’t the issues of “finding and managing” equivalent to those described under “action/reaction” and “workflow”? Structure and behavior do not act independently, and shouldn’t be considered independently when designing systems (an application, web site, or whatever).
It’s not that IAs and IDs need help understanding the boundaries of their practices or better tools for working together, but that these things are intermingled (for the better), irrespective of the job titles of those involved in the process. The specific tools/practices of IA and ID exist along the same continuum, and it doesn’t do much good to tease these apart — some contexts require more IAish tools and others require more IDish tools.
2. A Focus on the Web
“The focus of this series is on the challenges inherent in the task of translating established product requirements into a browser-based interface.”
Although the idea of Interaction Designer as a job role/title gained currency during the dot-com boom, ID is certainly not tied to the platform of a browser (or even the Internet). As far as I’m concerned, browser-based interfaces are, for the most part, an unfortunate sidetrack in the progression of software design. While browser-based interfaces are an important topic, to tie this whole series of articles to this facet of Interaction Design is A Bad Idea. I would hate to see an important series of articles about Interaction Design only help to marginalize the profession into the ghetto of “web design.”
I don’t really want to rehash the debate about IA being a distinct specialty from ID so I’ll leave it at this: I don’t think you’d hire the same person to design an application site like Ofoto as you would to design a content site like CNN. While the two disciplines clearly have to work together, complex IA problems are different from complex ID problems and require a different set of skills and knowledge. Therefore, it’s worthwhile to talk about them independently, especially if the purpose of the discussion is to improve how they work together.
To your second point about the series being focused on interaction design for the Web, that’s certainly the plan as it stands. Although I agree that interactive design spans a variety of mediums, the Web is not only one of the most important of those mediums but also one of the most misunderstood. Whether or not we like it, browser-based interfaces are going to be with us for the foreseeable future. Rather than writing them off as “an unfortunate sidetrack” we should apply our skills and knowledge to make them as useful and satisfying as possible.
Perhaps we should have titled the article “Bringing Interaction Design to the Web”.
I agree that teasing apart IA and ID is a fruitless practice. With the the belt-tightening across the Internet business spectrum, my IA role increasingly includes information architecture, interaction design, user interface design, content design, and all the requirements gathering and strategy normally assocated with a business consultant as well. Not to mention sales! If there are people out there doing only ONE of these things, I’m happy to hear it. But I don’t think it does us any good to try to separate our skills into definable containers that map to job listings. If you’ve noticed, the job listings now require everything from designing task flows to understanding PERL. And I don’t see that changing any time soon.’
I’ll look forward to the remainder of the articles.
Kelli
It seems like it’s time to break up the brick-and-mortar architecture profession. Rather than having a single profession, we need to break it into:
– Commercial
– Residential
– Functional
Wait! Maybe we don’t need to cast this world into the dark shadows of technicalities just yet. Enter the magic concept of “specialization”. Oooh… imagine a world where architects are architects, and they magically focus their skill and expertise on the problems of specific industries.
Whoa! I better stop now before I am hunted down and pinned to the rack for being a puny simpleton.
I’m confused. Are people actually saying that it’s pointless to do a set of articles on interaction design because the same people do IA and ID? This is a completely irrational argument in my mind… whoever does it, there is clearly stuff—task flows, error messages, etc–. inherent in ID that are separate from hierarchy/ taxonomy/ search issues that are common IA concerns. While I agree that a specialization in ID is a luxury that isn’t applicable to most of us, if you’re going to argue that there shouldn’t be a series of articles on ID because people don’t focus on it, than you might as well argue that a series of articles on deliverables or an article on user research is worthless because IAs do more than deliverables or user research.
There’s knowledge and tools important to ID; I for one would be happy to learn more about them.
Formal personas documentation? Not necessarily. But as Adam K. says, you need to have at least an idea who you’re designing for.
This is true even for “traditional” print design. One of the key things that got hammered into me in design school is that “art is about expression, design is about communcation.”
That’s to say, art is essentially a monologue, you do it regardless of whether anyone’s listening. Design (or journalism, or writing ad copy) is more like giving a speech. The communication’s still essentially one-way, but you do try to be aware of who your audience is and how to best get your message through to them.
I’ll up the ante a bit — and throw in my contribution to the meme pool — and say that interaction design is like conversation. Your work needs to not only to “speak” to the user/audience, but also _listen and respond._ The latter two are in fact a defining difference of interactive design.
So you can no more do interactive design without being aware of/engaged with the person(s) you’re designing for than you can hold a conversation with an empty room.
Most excellent new thread to the discussion. Thank you Ms. Wodtke!
Couldn’t agree more with both Adam and George’s comments. Design in general and certainly interactive design in particular, is fundamentally about communication. Therefore as professional communicators it’s up to the designer to ensure that their message is heard and understood by the receiver. It’s necessary then to have a firm, conscious, and articulated vision of who that receiver acutally is.
When I was working on ClarisWorks, all of us used to talk about whether the product would be appropriate for our mother. The unfortunate thing is that not only were we all lacking in knowledge of each other’s moms, we were also prone to shifting ideas of who even our own mother were. A problem that only years of therapy could effectively address.
The issue wasn’t that we didn’t have an idea of who we were designing for but rather we didn’t have a vision that WAS WRITTEN DOWN. The genius of the persona methodolgy isn’t the idea of directing your communication towards an archtypal user. The genius is that it requires you to faithfully record and articulate who that archetypal user is so you can make informed, conscious, and consistent design decisions.
So to answer Christina’s question and paraphrase George’s point: no, you can’t do interaction design without personas because designing in the absence of a conscious, articulated vision of your audience isn’t really design.
Why we just focus on understanding personas and not understanding situations when we move toward an experience perspective?
I think is difficult to break the boundaries of task performance inside a discipline-structure project development. I mean that it is difficult to determinate sometimes which job is for interaction designer or the experience designer or the information architecture or whoever.
But if we consider that we need to understand our audience to be able to design interactive products, then we need to understand aspects such as psychology, sociology, philosophy or technology. And can we understand this aspects of our audience without understanding another aspects such as context of use, ecology of artifacts or business strategy (for example)?
Klaus Krippendorff suggest to understand design as a making sense activity that focus on meaning. Where meaning is always construct by the different design contexts. In his work he focus in artifacts of industrial design and suggests four design contexts that will help to define the overall meaning of the artifact. Designing interactive products maybe the four design contexts will change but will still the same idea that the meaning of the artifacts is construct by the different design contexts variables that model interactive artifacts such as user cognitive model, business plan, context use….
With this i’m just trying to integrate, in a more formal way, the research process inside the design process and not just focussing on personas but rather in all facts that affects the meaning of situations. By situation i mean: the combination of circumstances at a given moment. (user and context circumstances)
An example of a integrative solution: http://bolullo.com/roberto/projects/topicoct2002.pdf
… And also how far the interaction designers need to understand about the user and context that model an interaction? I think this will depend on how people understands interaction and the different implications of design.
I think Interaction designers need to understand the enrionmental, philosophical, sociological, psychological and technological aspects that model the specific situations and therefore the user experience. And later focus on contributing to create the overall experience by focusing on the aspects related to the behaviour of the artifacts.
Just want to throw my two cents in about the difference between IA and interaction design. I tend to agree with JJG when he calls them “two sides of the same coin”, and it’s clear that folks who do one seem to have a facility for the other, but I do think the disciplines and practice are distinct, and I simplify it this way:
Information architecture is about content
Interaction design is about behavior
Ideas drawn from rhetoric are quite applicable, but with an important caveat — they’re generally focused on _communication_ not conversation.
At the simplest level there’s five parts:
* the implied audience (in our case personas/scenarios)
* the author’s intent (what did you mean to say — i.e. Twain’s line about the difference between lightning and the lightning bug)
* the actual artifact (which can be interpreted in a “objective” manner, i.e. how many times was a word used, percentage of a painting that uses red, etc., although these tend to be the least interesting observations)
* the audience’s interpretation of the artifact (i.e. does the reader buy into the author’s intended effect — the essence of “camp” comes from the mismatch of intented and interpretation)
* the implied author (i.e. who the audience imagines the author to be, which in our case is important to branding)
Literary critics have gotten quite baroque in their theories and tend to focus on one to the exclusion of other, but those five factors are the essential ones.
As Bob mentioned, thinking of your audience/users isn’t new — as a journalist I was told to explain things so Auntie ‘Em in Kansas could understand it. As a print designer, creative briefs told me who the target audience was.
What’s different about personas (and scenarios which are equally important) is they’re both deeper and more formal both in the way that they’re developed and the way that they’re communicated among the team.
To me, one of the exciting things is taking some of the techniques from IA/ID applying them back to “traditional” fields, like graphic design and writing. In essense, they help craft a much tighter version of the traditional creative brief.
I love the idea that interaction is like a conversation, although in reality it is more often a clumsy dialogue between strangers. As mentioned above, conversation implies contribution, listening, interpretation and consideration. Is that really possible between a rational system and what is fundamentally irrational, a user? I think that personas, and subsequently personas within scenarios, give us a “best guess” at imposing reason on the chaos. The “one size fits all” mentality works as well in interaction design as it does at the Gap. I think at least we need to think about S, M, L (and for the US market) XL.
I guess, ultimately, good interaction design facilitates dialogue between the user and the system. It acts as both interpreter and translator.
On a related issue, Kelli mentioned above that separating IA and ID is a fruitless practice because “my IA role increasingly includes information architecture, interaction design, user interface design, content design, and all the requirements gathering and strategy normally associated with a business consultant as well. Not to mention sales!” Unfortunately, I feel it is this approach in our industry that produces so much garbage on the web. Just because you can, doesn’t mean you should. The reason we need to discuss and agree upon roles, is to be able to bring appropriate talents to bear at the right moment. As a graphic design professional for twelve years I have to know the ins and outs of my profession and everyone in it, designers, writers, illustrators, photographers, production, reprography, printers. Am I capable of playing any of these roles? Probably. Should I? Of course not, because it would detract from the end result.
How can we have a meaningful discussion about ID, and learn something from each other, unless we differentiate it from other roles? The discussion so far has been enlightening. I for one am looking forward to the rest of this series.
To the point about IA and ID being distinct. I agree that they are different tasks, but depending on your job/project/title, they may bump up against one another enough that the distinction is pointless (at least to clients).
IA = Content
ID = Behavior
It’s just not that clear cut to me. If I worked somewhere in which they were separate disciplines or I was in an academic environment with skilled practitioners performing very different kinds of analysis, then I might think so. But designing Web sites for retailers is a different proposition. I know that in order to create the content for IA, we spend a lot of time assessing behavior so we can know which content should be presented and where. Similarly, creating the interaction is about allowing users to find the content they need exactly when it is needed, without unnecessary road blocks or confusion.
Having separate articles about these different areas is welcome. But the lines drawn around these different disciplines often seem unnecessary to me.
How ’bout we just call it design? 😉
Hi
this article really helpful
it’s my first time in the site and i’m very familiar with this.
At my current gig, those being hired to focus on information architecture, interaction design, interface design, usability and everything in between, to ultimately create interactive products, are called Experience Designers. Can you guess the cool new acronym for that one?
At first, I thought it was a bit silly to create yet another title for a role that, until recently, was understood by most people I knew in the industry as IA. But after just a few days in the role, the title is starting to make a lot of sense to me. If you are focusing on any one of the aforementioned tasks in your job, you are working to improve user experience. And if you are doing all of those tasks, then you are in effect designing experience.
What I’m getting at is that I believe that most here are designing the entire user experience, whether their actual title is IA or IxD or whatever. But more important than job titles and acronyms, is the need to define the separate tasks that create a solid and thoroughly designed user experience because all of those tasks need to be addressed in your ideas, processes and deliverables.
So tomorrow, we may call all of this something different, but the concepts will remain the same. And today, thinking about the IA process as 4 general themes and the IxD process in 5 concentrations definitely helps me to make sure I cover all of those thoroughly when I design. And to think of the master list of tasks as 2 separate processes (whose threads often run in parallel) helps to keep a complicated problem and a tight schedule trackable and conquerable.
But imho, I do think that it’s a bit early for any organization that is gearing up for web projects to specifically hire both IAs and IxDs as distinct roles and god forbid, staff them on the same project. They can throw whatever acronyms they want in their title, but they better be covering both processes. In product design, this may be different.
Btw, I think the wikipedia helps as well, if you look at it as a start in defining this profession (http://en.wikipedia.org/wiki/User_experience, http://en.wikipedia.org/wiki/Interaction_design and http://en.wikipedia.org/wiki/Information_architecture).
Thanks for a great article, looking forward to the rest.
This is a great article. Where can we find the rest of the series?
Sorry, but I think a twelve-part series is excessive, verging on obnoxious.
“I don’t think you’d hire the same person to design an application site like Ofoto as you would to design a content site like CNN.”
I wouldn’t hire a *person* at all, in either case. I’d hire a team of smart generalists, each capable of educating the other members of the team with regard to the nuances of their own area of greatest focus.
Erin, that is not at all clear.
What’s more, it’s not as if B&A is hard up for material, that I’m aware of; I know of at least one instance where a thoughtful, relevant, eminently appropriate piece was rejected outright on the grounds that it was “unfocused.”
I have a hard time seeing where a journal that can tolerate a twelve-parter can dismiss *any* submission as unfocused.
I’m not trying to be a s*&t-disturber, believe me. I’m just trying to get a handle on what B&A thinks its audience wants, and how someone I don’t remember being at any of the initial discussions can speak to what we “set out to create.”
I now return you from this spike of meta to your regularly-scheduled read.
A series of article on interaction design is welcomed, and that Bob is focusing on the web is mete: it is his specialty. I would vigorously suggest anyone with a software POV to contribute.
http://www.boxesandarrows.com/about/writeforus.php
IA’s tend to write more– maybe it is their content origins? But B&A is a place for all the structural design arts, from Interaction design to Infromation design.
Bob gets his twelve says, just as Jesse and Dan get to columnize their insights on a regular basis. In fact I laud Bob for his courage in comitting to a year of sharing his learnings. We should be grateful, not sniping. Writing is hard work. Let’s argue about his content instead. Disagree with his words, not his right to say them.
Finally, I am going to remind you all to keep it civil (see warning below comment form). Disagree, but be polite, and take personal arguments offline where they belong. I am quite comfortable deleting anyone who is rude, as comfortable as I am keeping dissenting views up. Disagree, but try to stay smart, not mean.
Thanks, and on with interaction design.
To kick it, I’d like to ask: can you do effective interaction design without creating personas?
Okay, I’ll bite. Christina asked: “can you do effective interaction design without creating personas?” No, I can’t do effective interaction design without personas. In designing a “computer-human” interaction, there is always some model of the human involved in that interaction. It can be arbitrary, self-referential, or intentional (a persona). If the value of interaction design is in creating intentional behavior in systems (i.e., things happen by design rather than by accident), the human element of the system should also be explicitly described.
There are some nuts-and-bolts aspects of interaction design that you can do without an analysis of the specific audience (by applying basic design principles and good sense), but why? Even if you take just 5 minutes to create a sketchy persona based on flimsy information, at least you then have a target and rationale for the decisions you make.
If you’re not designing for a persona, then who are you designing for?
hello, happy to chance upon this place. Got here by way of V-2.org. Can Christina cite an example of an “effective interaction design w/personas”?
Very interesting! Sounds like design activity may be interpreted as a rhetorical problem of effective dialogue, involving a necessary balance among the speaker’s intent/vision, the audience’s (or persona’s) needs/expectations, and the argument’s logic/rationale/value…hmm…
So perhaps having a persona (conceptual model of an intended audience type) facilitates the development of a meaningful dialogue, and thus, a more effective (balanced?) interaction design solution…?
Keli, while I understand your desire to combine these individual skills under the single moniker of “design”, that desire simply doesn’t mesh with the reality of the disciplines. Although things can get fuzzy near the boundaries, once you get away from the borders, the distrinctions become quite clear.
For example, the situation you stated, “designing Web sites for retailers” is but one narrow type of a Web-application which is itself but one narrow type of computer application, which is itself but one narrow type of an interactive product, which is itself but one narrow type of an interactive experience. Interaction designers work up and down that entire food chain sometimes with and sometimes without the need for information architecture.
While it’s true that I’m a “designer” in some generic sense of the word, that doesn’t mean that I’m qualified to be an industrial designer, a type designer, or a graphic designer anymore than being a doctor instantly qualifies me to do everything from surgery to dermatology.
If you’re interested in learning more about interaction design and the unique community of practice, you might want to check out this new group of professionals.
Hi Bob,
I’m familiar with the interaction design professionals and I understand your distinctions. My point is just that this discussion is an internal one, of import to the practitioners and rarely for those for whom the work is done (at least in my experience). Also, I was only referring to the distinction between interaction design and information architecture for the Web–not conflating ALL types of design distinctions (i.e., graphic design vs. industrial design, etc.).
But your analogy between doctors and designers is a curious one. The title “doctor” doesn’t mean one can go off and perform any type of medical procedure, specialty aside. But all doctors do receive a standard education and then specialize beyond that point. Designers seem to me a broader category with less uniformity in training and education and certainly less agreement on what consists of a “specialized discipline” or even what they should be called. I guess that’s my point–is it necessary to pin that down? And if so, for whose benefit?