Liessi Haussler
All too often, organizations defer documentation until the product is complete, by which point valuable insight becomes hindsight and it’s too late in the process to make changes that would have greatly improved the user experience (not to mention the documentation). As a technical writer, I’ve often been frustrated by this approach, especially when it results in having to write apologist workarounds to combat inconsistencies. Jerome Ryckborst got so tired of being the “mop and bucket” at the end of his company’s software development cycle, he decided to devise a methodology that allows the extended team to get involved at the design stage, replacing eye rolling and told-ya-so’s with a supportive process that improves the work of developers and rewards participants with pride of ownership.
When Jerome shared his innovative—and fun—Five Sketches™ methodology with STC Canada West Coast at the April 2008 program meeting, it was a reminder that technical communicators are awesome user champions, and as such, can offer unique perspectives on process and design.
Development tends to follow the path of least resistance (in time and effort) from the developer’s point of view, with matters affecting user experience often treated as non-critical enhancements. Such an approach may produce the straightest and shortest possible route to development but it tends to produce a metal frame with wheels rather than a smooth, luxurious ride. Five Sketches offers a solution that even the smallest teams can use to develop products that are technically sound and usable.
Design by collaboration is not a new concept and to be fair, many organizations fully appreciate and encourage contributions from their team. What interested me most about Five Sketches, however, is that participants are obligated to “saturate the creative environment” by arriving with no less than—you guessed it—five distinct ideas. This sounded quite daunting at first but the rules of the game make this not only possible but essential.
Given a specific problem statement, each participant separately sketches five solutions, then shares, combines and adds to those sketches several times before any analysis begins. Drawing from the Six Hats™ approach, sketches undergo a number of evaluation processes that praised, analyzed and critiqued as the team considers developer concerns, usability standards, and market requirements, then resketched to help select a single way forward. Rather than coming to the table entirely vested in a single concept and prepared to fight to the death for its adoption, everyone goes through the same process of having to churn out a handful of rough drafts, intentionally drawn in fat markers to prevent excessive detail. As much as we may love our own ideas, it’s so much easier to let them go when they’re a dime a dozen.
Since each participants brings many ideas, and since the team also iterates and combines the ideas, no one gets to claim total ownership. This diffuses the tendency for each person to defend their territory, and makes it easier to respond to design critiques. This method was developed for and with teams of developers from Canada, USA, Australia, India, and South Africa. Although Five Sketches was developed for and works very well with software and web-page design, it’s not difficult to imagine where similar thinking would benefit the development of many other product categories. To find out about Five Sketches in detail, visit Jerome’s excellent blog on the subject at http://www.fivesketches.com.