« heh | main | experiencing interface »
When I sat down to write my book, I asked myself the question "What are the key things an information architect should know to be effective?" In the book, I realized that interaction design was a tool IA"s needed, and touched lightly on it, with a strong bias to personas as the way to do it.
Now I'm working with my fellow managers at Yahoo to ask the same question. My team of interaction designers is pretty general as a rule, and they all know quite a bit of different stuff from each other. Their deliverables all look different and their processes are a grab bag. So I'm working my way through to figure out what people are doing, what's working, what isn't working and what should be used to make better products. Big fun!
So one of the things I'm working on in particular as part of this process is collecting methods and approaches that are useful in the practice of interaction design. These might include Information Architecture techniques, but I would assume they also have a few tricks of their own.
So starting from Bob's definition of Interaction Design, what are the things an ID needs to know? Please leave me your two cents, I'll add mine as I keep digging, and perhaps we'll have a little list before long.
Here's a quick start:
requirements gathering
needs analysis
conceptual modeling
personas, scenarios
task analysis
user flow/use case design
...
I think the element of time is important here. For example, the personas might indicate how experienced a person is both with the UI and with the subject domain. This information could be used to adjust the "speed" of the interaction design.
For example, a person experienced with the UI could tolerate fancier interaction and perhaps fewer conventions. A person experienced with the subject matter might need fewer or different levels in a taxonomy. It's also an example of were IA meets interaction design.
In addition to defining the user (through personas, user profiles, and the like) the interaction designer needs to define the environment in which the software will be used. I generally call this "environmental profiles."
This includes the computing environment (desktop, laptop, palmtop, mobile phone, OS, software like browsers...) as well as the surrounding environment (office, home, kiosk, library, street...). Related to these is the frequency and amount of use. How often, and for how long, is each session?
Understanding the environment, its capabilities, limitations, and impacts on the interaction are key to being able to properly design the interaction.
Couldn't agree with Michael more (actually I often agree with Michael Moore but that's an entirely different thing). Interaction designers essentially function as translators, taking the product requirements and designing the most effective way of communicating the necessary functionality to the user. A good Interaction Design understands both the limitations and abilities of both parties and is able to find effective means of merging those into a common language.
An obvious pragmatic result of this is that interaction designers must be able to express themselves interactively through prototypes -- a skill that isn't as necessary for IAs or visual designers.
A good interaction designer combines computer programming with human psychology.
An interaction designer is someone who can abstract all the information and produce concrete examples. They need to be able to jump form general human behaviour to technological implementation and back in a split second. You need to be able to picture the whole system to the smallest detail.
The other skill is the ability to understand what the clients needs to understand the project. Many clients cannot abstract their thinking enough to understand how important wireframes are. Their opinions/comments can turn 180degrees when you go from wireframes to interactive prototypes to visual design to final deliverable. You need to be able to control the system through the many stages (which means you work the WHOLE project, not just the first phases or whatever).
An interaction designer must also understand how to work with designers, writers, and programmers. The best ones have experience in all forms. Can you easily explain to the writer that the content will change based on where the user came from, explain to the programmers that what needs to be modular, and the designers to explain the visual phsycology of their users?
About documentation: I think we're killing ourselves. We all have the big list of documents to chonicle our work but nobody but the internal staff care about them. Clients don't understand how to read the documents and project teams want them becasue the IA is taken off the project their phase is completed.
The clients have hired you to solve a problem, not document your process to solving it. They want to see results and your deliverable documentation should reflect this. My experience has led to developing many stories/scenarios, a site map or user flow, and showing a design immediately. These are the documents that the client can understand.
Remember the famous discussion between Kent Beck and Alan Cooper. They are both right! Both advocate the use of stories/scenarios and showing working models immediately and often to the customer. I have been working towards process akin to a marrige of goal-oriented and agile development methods and it's working out greatly! The key is: develop scenarios with client -> show client a working product that solves the scenario.
"What are the things an ID needs to know?"
Here's one: visual design.
Although it's very nice to be able to find a job where as an ID you're not responsible for any of the look of a product, those jobs are pretty few and far between. In my experience, its the very very rare client that really accepts that you're not there to make the thing look pretty.
It's much easier to explain believably, "I do all this stuff, but I'm really not a programmer" than it is to say, "I do all this stuff, but I'm not a visual designer." Many people will understand that you're not coding something, but very few understand that you're not going to make it look good as well.