What's in a name, continued...
July 17, 2001
It's interesting to see the parallel "what is it that we do?" discussions emerging, in this case it's the Society of Technical Communicators (whose largest special interest groups are information design and usability), who are pondering the differences between "information design" and "information architecture," and how these two differ between print and web. It's got perspectives from a number of notables—and among the more interesting comments is Lou Rosenfeld statement that he's not an information architect.

There's also an oldie, but goodie from Web Word predicting the death of usability as a separate profession, with a rather pointed, and well-deserved, critique of the usability specialist community.

My own thoughts are that "ID/IA" have evolved significantly since the terms were first created. The structuring of information and the visual display of information are two parts of a larger (unnamed) whole. Just as within UX's "community of practice" there are different disciplines, within this profession their are people and projects that will lean one direction or another.

The thing that's missing from the STC discussion is a recognition of that interaction is the key difference between for print and for the web, and therefore adds a new dimension to the job. Consequently, I think "interaction design" is a separate discipline, although many of it's methods have a high degree of overlap with ID/IA, and most projects I've worked on have been a mix of "interaction design" and "information architecture/design."

Changing subjects, Web Word's thoughts tied into some of the comments made during a presentation on usability at the AIGA Experience Design (Advance for Design) summit, that usability is less a job than a hat various people should wear during the development process. In fact, I've heard rumors one famous usability expert publicly said the same thing during the recent Usability Professionals Association conference—which I doubt went over well.

But I think the point is important. Usability is something I think about throughout the development process. Consequently, it's an aspect of what I do and not a separate job. Certainly there's a need for someone else to test my work, but this can be done by someone who's also knowledgeable in usability even if they're not a usability specialist. (There's still a need for dedicated usability specialists on some larger projects, just as you might need any other specialist for large, complex problems within their domain, or as an in-house consultant to help teams within large organization.)

I've been struck the number of usability specialists who complain about being ignored by their organization, but are content to remain in the role of QA and to merely diagnose problems rather than recommend solutions—or who recommend solutions but can't be bothered to learn enough about design and technology to understand how feasible their recommendations might, or might not, be. And who also seem to think that saying rather usability is The Right Thing To Do is enough to sway businesses, rather than demonstrating how usability can add value.

In some ways, usability is too important to be left in the hands of usability specialists—which is why it's becoming part of other jobs throughout the development process and leaving a shrinking pool for the usability specialist. ::

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Your thoughts…

wow. Your final statement: "In some ways, usability is too important to be left in the hands of usability specialists" is sure to provoke some intense discussion. I am not sure Usability practitioners or specialists would agree with you at all. This potentially marginalizes these people in much the same way Visual designers have felt marginalized by many firms or teams.

I would say that in some ways I do agree with some of your points, but feel that part of what the usability specialist should be doing in their teams, is getting all team members to take on the mindset and some techniques and they can act as arbiters as well as testing specialists. Many have specific cognitive knowledge and experience that I, as a ID/IA/UX designers do not have. They can help me think the right way (user first, try these techniques, look for these issues and why, etc) but I can't necessarily replace their core skills just as they don't have the experience or expertise as designers.

I think it is important to note, that just because you have usability specialists on the team, it doesn't negate the need for the designers (all kinds) to think of the user first and about usability as well.

erin @ 07.17.2001

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

It's true, I was being a bit provocative... And I'm sure the usability community will disagree with me. Flame away.

Good usability specialists can and should do all the things you describe. Those tasks are probably especially important now when we're still all-to-often have to convince both management and other members of the development team to think about users when designing.

But long-term once we (hopefully) take being user-focused for granted, I think a lot of the "lobbying" tasks you've described fall away. True good usability people do have a deeper understanding of cognitive knowledge and specialized experience -- but there's also a lot of mediocre usability people who spout The Rules without any real understanding.

However, while specialized knowledge is sometimes needed, a lot of it is just common sense. To quote John S. Rhodes' whose Web Word essay I cited: "Usability in the trenches, when you really get down to it, requires having people around who have great attention, are compassionate about users, and can listen....there are so many simple and effective usability techniques, that almost any moderately trained person can do usability testing" (Rhodes' emphasis). And certainly for more complex projects you need people with more specialized skills in a variety of disciplines, usability specialists included.

Unfortunately, too many usability specialists act like they're the high-priesthood, too often don't understand how business works, and too often do (bad) research that's more suited for academia than the working world (yeah, I'm being provocative again...if you're one of the good usability, I'm not talking about you...) and Rhodes' points in the essay are well taken. I don't think I'm marginalizing usability specialists as much as they're marginalizing themselves.

And in some sense I think they realize they're being marginalized, since reports from the recent Usability Professional Association suggest there are people within the field who are trying to promote "big U" Usability that encompasses all of user experience. Unfortunately, equating "usability" with "user experience" makes the same mistake as calling it "big" "information architecture," as I've talked about at length.

George @ 07.17.2001

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

[...] the role of QA and to merely diagnose problems rather than recommend solutions

minor quibble: QC (quality control) is diagnosing problems (looking at symptoms and realising something is wrong), QA (quality assurance) is recommending solutions (prescribing better processes, habits, diets, exercise regimes, etc).

(IIRC-SCMIIW)

eric @ 07.19.2001

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Re: "The thing that's missing from the STC discussion is a recognition of that interaction is the key difference between for print and for the web, and therefore adds a new dimension to the job."

Readers interested in this theme may find two articles I wrote for the Philly Metro Chapter of STC's newsletter interesting. The first is What Is Interaction Design and What Does It Mean to You? (slightly updated version here), and the second is The Information Designer's Palette of Interactive Techniques (expanded version here).

I found it a bit curious that while Intercom (STC's monthly) picked up and reprinted my previous two articles, on EPSS and Performance-Centered Design, the editors didn't seem to feel that the second two merited reprinting.

Craig Marion @ 07.26.2001

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copyright © 2001 All Rights Reserved.
Any problems with the site?

Note: This site will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device.