Guerrilla Interaction Design (part 2)
By Loren Mack on Jan 07, 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.
Three days is not a lot of time to create a design. It's not a lot of time for anything really. But, in three days a Guerrilla Interaction Designer can crank out quite a bit of design work. And the best part is - no guns! Not even a squirt-gun!
Now I know most of you are thinking "NO WAY!! You simply CANNOT do any good design work in that amount of time!" And, hopefully, most of you will be surprised with my description of how it works. Let me first describe the Guerrilla so we can then understand the process:
The Guerrilla has extensive experience in GUI design in general, and has an experiental arsenal of design solutions to draw upon.
The Guerrilla is at one with his product manager and the product.
The Guerrilla has seen and solved similar problems for most of the requirements.
The Guerrilla is confident in his or her knowledge that any improvement at all is an improvement, and that quick iteration for short release cycles is better than hanging around with actual gorillas.
The Guerrilla is lightning fast and accurate with his or her weapons of choice (my favorite is StarOffice Impress).
And finallly, The Guerrilla is content to kill off one or two bits of infidel design or poor usability so that eventually only one or two bits remain.
It's not really a "Zen" thing, but more of a "I just drank a case of Full Throttle energy drinks" thing. Coupled with an agile and open-minded development team, this model can work pretty well. So now that we know a little about the Guerrilla, perhaps the method will make sense.
There are phases that are simply left out for the sake of quick turn-around times, and there are phases that are done differently. Let's take a look:
1. Discuss the product requirements or potential problems and fixes with the product manager (no more than 2 hours).
2. Based on the Guerrilla's expert opinion, sketch a paper design and review with the product manager (no more than 4 hours).
3. Discuss it with development management to make sure there's nothing too scary to implement, and potentially ignore protests at this point (an hour or less).
4. Grab your favorite WMD (work-tool of masterful design) and get to work! Create the design based on the initial drawings and follow-up conversations with the product manager and development (try to keep this under a day and a half).
5. Show the design to product management, and if that's all hunkey-dory, find a live body (hopefully with some domain knowledge) and walk through the design; look for serious "gotcha's" or bewildered stares. Resuscitate the victim (participant) if necessary. Wash, rinse, repeat (can take up to a day depending on how many live bodies you have at your disposal).
6. Finalize the design and deliver to product management and development management. Bring a flak-jacket in the event that development is uncomfortable with the design, and intends to torture you as a POD (prisoner of development).
7. In the likely event that both recipient parties approve (or mostly approve), and if there is time left in your 72-hour span, wrap the design in some documentation (old newspaper works pretty well) and move on to your next target.
I know it sounds a bit slap-dash, but keep in mind that some improvement is better than no improvement. I wish I had a nickel for all the "full design" projects I've worked on, only to find that by the time I had the design, development was done or the market had shifted (and so, the requirements as well). I might have enough for a fancy latté or something.
While this idea works and fills an important niche, it's key to keep in mind that you're not trying to reinvent an operating system. It works because most if not all the problems presented to the Guerrilla have been seen and solved. His or her experience, coupled with the idea of incremental improvements help Guerrilla UI Design make sense and be effective as a way of designing. It's not always the best answer, but it can help arrive at better answers pretty quickly.
And that's what we want right? Quick solutions to the shifting sands of usability...