What is an Interaction Architect?

(originally posted on the InteractionArchitects Yahoo! group)

My articulation of an Interaction Architect (if that’s the term we end up choosing) is:

An architect focusing on the design elements of a system’s presentation architecture.

The following paragraphs detail how I define the bolded phrases in that.

How many of you have encountered Jesse James Garrett’s Elements of User Experience (diagram and book)?  I think he defines a useful topology for the different sorts of efforts involved in our work… it’s been criticised as incomplete or inaccurate by some – and it is focused on web site design- but I believe it provides a nice way to seed the conversation and places meaningful definitions on the different elements.

One of the major things to note about his breakdown is the absence of explicit evaluation elements, such as those that come to my mind when I think Usability Professional.   It deals with those elements that I think of as Design and assumes that evaluation is included in each element’s own process.  (And I think that, because of that, I would call his diagram The Elements of User Experience Design instead.)

I use a model for product innovation and design that has four iterative stages:

discovery –> ideation –> articulation –> evaluation —
^——————– refinement ————————-

(or, somewhat naively, requirements –> design –> prototype –> test –> iteration –>…)

There are experts in each of these stages, and that’s where I see the distinction between the kinds of work.  An expert in a particular stage has knowledge of and applies techniques from the others, but concentrates on their stage.

Requirements Analyst is the discovery expert.  God help us if he/she thinks that the requirements specs are the product, or that traceability tools lead to useful/usable products, but if I’m gonna get audited by the FDA because my product plays in the space, I need one of these folks around to dot my I’s and cross my T’s.  (This is my secondary role, and in my organization I’m considered an expert, but this organization has lots of room to grow here.)

Designers are the ideation and articulation experts.  I’m endlessly fascinated by the generative power of a designers mind, no matter whether they specialize in graphic design, industrial design, mechanical design, chemical design, or interaction design.  Ideas are spouted, rejected, tweaked, inverted, etc. in fast cycles of creative energy, and they master the tools for communicating those ideas to others.  (This is my primary and preferred role.)

Usability Professional to me focuses on the Evaluation portion of this.  A U.P. can’t do a good job without understanding and using techniques of discovery, ideation, and articulation as well, but their core expertise, and where I will ALWAYS defer to them, is evaluation.  Quantitative and qualititative analysis methods, from the front end ethnography to the back end usage tracking.  Killer. (I do some of this, but I enjoy and exploit other experts in my organization for the deeper bits.)

Architect can play any of these roles, when necessary, at a high level of competence, but not with the depth and facility of one of the experts.  An architect balances the need and effectiveness of the other elements within the business, market, and product/system context.  Oversees the interplay and can be critical to the ultimate success of the organization and its products.

I also think of the particular system/product as having more or less content in three different architectural areas:
Presentation Architecture (which Jesse captures well in his model)
Data Architecture (data and transactioning, information architecture, load balancing, etc.)
Technical Architecture (technology, mechanics, algorithmic complexity)

For example, a system like Amazon.com has a HUGE data architecture component, an important but smaller presentation architecture, and a relatively small technical architecture.  A massively parallel-processing gene-folding analysis system is big on technical architecture, moderate on data, and tiny on presentation.  The systems I work on, an integrated environment for automation control development, is high on presentation and technical architectures and low on data architecture.  (The model I use also captures the scale of a system versus others for comparison.)

This leaves room for Usability Architects and Requirements Architects in the Presentation Architecture component of systems, and other types of architects taking responsibility for the other architectural components.  In large systems/organizations, individuals may specialize so the role fits the position.   In smaller ones, one person may play multiple, but wear a particular hat on a particular day.