Tales: Guerrilla Interaction Design in Action!
By Loren Mack on Mar 20, 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.
...Please read with toungue in cheek...
Hopefully, somebody read my previous post on this topic. I know I did. And without being too narcissistic, I must say I rather enjoyed it. Truly I can be a witty boy at times, and with humility as well.
So, for all of you who agreed with enthusiasm, thank you. Send me money. For those of you who may be skeptical, I'd like to share a recent GID project in the hopes that it may help win you over to the right side. Vive la résistance utilisabilité!
We should begin with understanding how the project started. My boss asked me to talk with some folks from another team that wanted some help from xDesign. They asked for some help with a wizard for creating XML documents. A perfect opportunity to use the Guerrilla Interaction Design process, as...
The Guerrilla is at one with The Wizard
Turns out as well that these folks were no ordinary developers. Both of them flexible and open-minded, they were interested in solving the problem in the most usable way, rather than the easiest to implement way. Score!
After about 45 minutes of discussion, they were able to give me a clear picture of what the problems were and why they were problems. I also learned during our initial meeting that they were definitely open to outside ideas, and seemed encouraged with a few concepts we discussed in the meeting. Frag Damage Multiplier! As you may recall from my previous posts...
The Guerrilla has seen and solved all Wizard design issues
The problems were reasonably straightforward from their description, but the solution wasn't what they were expecting I think. However, after delivering the initial sketches, they seemed very enthusiastic with the direction. They immediately understood the advantages of the approach and seemed pleased. These folks were obviously skilled masters at software development, and from some very realistic screen mockups were able to see the elegance in the solution, since as we all know...
The Guerrilla has mastered speed and accuracy with the WMD (work-tools of masterful design)
So that we all can see the problems, let's take a look at the previous design and identify the issues. Here's the first screen from in the wizard which is relatively straightforward:
And the second screen - again, nothing unusual or complicated:
The third screen however proved to be the nefarious culprit of designer dissappointment, the critter of corruption, the minion of... well, you'll get the picture:
It wasn't a bad looking screen at all. Nicely laid out, and functional, it didn't really look like a problem. But it was. What the user needed to do here didn't fit in the implementation, and that means it wasn't really usable, and we all know "poor usability" must die (or at least go really far away, like Antarctica or somewhere).
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
So "What's the problem?" you ask...
There's no way to see all selected files together in a single list.
The user needs to select XML schemas (files if you will) to be used when creating their XML document. They can get these files from the machine they're using at that moment, or from known namespaces (think of it as another kind of directory structure), or from the Internet. They'll likely need a few files, and will also likely want to be certain they select everything they intend to.
The current interface makes it hard to see all the selections in one spot. There's a potentially huge list, and displayed in tree-table it's likely the user will need to scroll up and down (excessively) to be certain they've selected everything they want.
The memory load on the user can be excessive.
Many of you have heard the phrase "Seven, plus or minus two". For those of you that haven't, it refers to the average short-term memory storage for most humans. Think "memory" like a horizontal tube, and the "things to remember" like baseballs. Most people have a "memory" tube that's 7 +/-2 baseballs long. For each thing they need to remember short-term, think of it as putting a baseball in the tube. After ~7 balls are in the tube, adding another ball will push the first one out (equivalent to forgetting, and in my particular case my "tube" is only about 5 baseballs long and getting shorter by the minute).
In this interface, if the user needs to select more than 7 or so schemas, they'll likely need to make a paper list and check them off. Extra work, and extra memory load for those who don't "quite" need the list. And the best part is this is something a better design can eliminate completely.
The layout and controls take away space from the list (the primary benefit of this screen).
The "Primary Schema" and "Root Node" fields pertain to only one schema, or selection in the table. Displaying them separately from the actual selections blurs the relationship to the schema list. It would likely cause the user to look at the list, and then at these fields, and then back to the list in order to be certain they've selected the right schema as primary.
Selecting schemas, and then selecting one again to be primary is redundant, and in this case unnecessary.
So, with all this we now have three infidel bits of "unusability" that must die, like villains tied to the tracks of The Design Train, or prisoners dangling over a pit of pointy-sticks (pointing up of course). Tune in next week, when our hero... Nah, I'll tell you about it now.
The new design, Guerrilla style...
Redesigning this screen of the wizard wasn't difficult. The previous points about unusability indicate three basic ideas:
- The list should contain what the user has selected and not everything they can select from, alleviating the need to remember what was already selected.
- The selection process will likely require drilling into hierarchical folder structures (directories) and could be deep; the space available to view these structures needs to be at least as big as the list.
- Once the selections have been made, it's likely that the information about primary schema and root node in the list can be shown in as part of the list, keeping the viewable space large as possible.
Here's the design we ended up with:
The re-work of this screen uses some different design ideas and techniques to improve the usability:
If you click on the image below you can see a short animation of the screen in action:
So here we are, with another brilliant design (thank you thank you) that solves many of the problems which made the previous design feel clunky.
It wasn't that the previous version was poorly done or ugly - in fact it was very well done and it was clear to me the development team paid a lot of attention to the use and layout of controls, the consistency and polish. It was simply that something about it didn't feel right, and when the re-work was presented, the developers said "That's it! We couldn't quite describe what was wrong, but this definitely right."
This entire exercise lasted from a Thursday afternoon to the following Monday morning. Three days. This included creating a presentation storyboard showing before and after images, explaining the design problems and solutions, and even an additional entry screen (piece o'cake) as a last-minute addition. It was also one of a few projects I had on my plate. And, of course this is all possible because...
Inside every Interaction Designer there is a usability "Guerrilla", ready to attack, maim, dismember, and kill bits of infidel design or poor usability