Software development that uses a waterfall method is likely to deliver the wrong thing, too late. The intent of the Agile method is to deliver working software sooner, so the intended users—our clients and their customers—can provide feedback that steers us to deliver the right thing.
Over the past month, I’ve come across the same discussion several times: “When designing a website or product, do you use wireframing or prototyping?”
The first part of my answer is: “Make sure you sketch, first.”
At the design stage, sketching, wire-framing, and prototyping are not equal. Sketching is useful at the divergent phase of design because it lets the design participants express and capture lots of different ideas quickly and anywhere that pen and paper will work. Nothing is as fast as running a pen across a sheet of paper to capture an idea—and then another, and another. And since sketching is intentionally rough, everyone can do it.
Responding to the problem statement, first saturate the design space with lots of ideas, and then analyse and rapidly iterate them to a design solution.
I also believe sketching is great for the convergent phase of design, but there are potential hurdles that design participants may encounter. It can be challenging to convey complex interaction, 3D manipulation, transitions, and multi-state or highly interactive GUI in sketches without learning a few additional techniques. This is unfortunate, because having to learn additional techniques reduce the near-universal accessibility of sketching.
The second part of my answer, therefore, is that “if you need to learn additional techniques to make sketching work, feel free to choose wireframes or prototyping as alternatives when there are compelling reasons to do so.”
I should point out that the three techniques—sketching, wireframing, and prototyping—are not mutually exclusive. Wireframes and paper prototypes can both be sketched—especially for simple or relatively static GUI designs.
There are no validity concerns with the use of low-fidelity sketches, as these readings show:
In 2007, a flash of insight hit me, which led to the development of the Five Sketches™ method for small groups who need to design usable software. Looking back, it was an interesting journey.
The setting. I was working on a two-person usability team faced with six major software- and web products to support. We were empowered to do usability, but not design. At the time, the team was in the early stages of Nielsen’s Corporate Usability Maturity model. Design, it was declared, would be the responsibility of the developers, not the usability team. I was faced with this challenge:
How to get usableproducts from software- and web developers by using a method that is both reliable and repeatable.
The first attempt. I introduced each development team to the usability basics: user personas, requirements, paper prototyping, heuristics, and standards. Some developers went for usability training. In hindsight, it’s easy to see that none of this could work without a formal design process in place.
The second attempt. I continued to read, to listen, and to ask others for ideas. The answer came as separate pieces, from different sources. For several months, I was fumbling in the metaphorical dark, having no idea that the answer was within reach. Then, after a Microsoft product launch on Thursday, 18 October, 2007, the light went on. While sitting on a bar stool, the event’s guest speaker, GK Vanpatter, mapped out an idea for me on a cocktail napkin:
Design requires three steps.
Not everyone is comfortable with each of those steps.
You have to help them.
Some key design ideas, conveyed to me on a napkin sketch in a Vancouver bar.
The quadrants are the conative preferencesor preferred problem-solving styles.
I recognised that I already had an answer to step 3, because I’d heard Bill Buxton speak at the 2007 UPA conference, four months earlier. I could help developers be comfortable designing by asking them to sketch.
It was more easily said than done. Everyone on that first team showed dedication and courage. We had help from a Vancouver-based process expert who skilfully debriefed each of us and then served us a summary of remaining problems to iron out. And, when we were done, we had the beginnings of an ideation-and-design method.
Since then, it’s been refined with additional teams of design participants, and it will be refined further—perhaps changed significantly to suit changing circumstances. But that’s the story of the first year.
How to get