Guerrilla Interaction Design (part 1)
By Loren Mack on Jan 03, 2008
Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.
Recently I've been noticing a bit of difficulty among my peers at Sun, as well as other friends I have in the business of design. It seems somewhat widespread that creating good designs, and then having them correctly implemented is a bit of a battle. It makes me think about how leaders of unpopular political resistances must feel as they fight for their position. Speaking their minds, and deploying their Guerrilla fighters to lead the resistance. And here I am, on the side of the Usability Resistance, trying my best to convince the people, overthrow the "usability want-nots", and keep my Guerrillas fighting the good fight.
This reminds me rather of a method I and my team have used in the past to design user interfaces. I call it "Guerrilla Interaction Design". It's a way of creating usable GUIs quickly, under pressure (and sometimes under fire). To describe it properly, I should outline a more conventional user-centered design timeline just for reference - which goes something like:
1. Talk with your local, handy-dandy product manager about what they'd like create as a new program, or what they'd like to do to improve an existing one.
2. Get out of the office and go observe users doing what the new program might do, or using the existing one.
3. Figure out what might meet their needs, or improve the experience.
4. Go back to the office and document what users are doing today, and what might be an optimized way of doing it in the future (or possibly what they really need to do).
5. Draw some pictures and create a story.
6. Discuss this with the folks from step 1, and iterate, iterate, iterate.
8. Create a paper storyboard, or medium fidelity prototype that someone could review or use to attempt the task with the new, optimized design.
9. Go back out to the field and usability test the design with similar (or the same) users. Observe and document the results and then...
11. If you're lucky, all the rough edges are smoothed out and you have a design that delights the users, makes the product manager happy, and is possible to implement by the developers.
12. Deliver your design, and remain "on-call" for potential "gotcha's" that may come up and need quick decisive design action!
Whew! That's a lot of steps! It approximates what most designers might tell you when explaining how to produce a good design, and is a pretty consistent and standard way of achieving a predictable result.
Now... do it in three days...
To be continued...