sketching – Usability research and analysis

5 May 202218 November 2022

Divergent thinking and collaboration

Divergent thinking—thinking in an unusual and unstereotyped way—*is what’s needed in software design. Divergent thinking isn’t the same thing as creativity—it’s an essential part of creativity. It is the ability to see:

lots of possible ways to interpret a question
lots and lots of possible answers to a question.

User-experience designers engage in divergent thinking when they explore multiple ideas and try to “saturate the problem space.” But your entire development team can benefit from this—and save your project months of rework.

Continue reading “Divergent thinking and collaboration”

27 June 200926 June 2009

Design requires courage and trust, not just user involvement

Designing is usually a rewarding activity, but the path from start to finish can be filled with frustration and even panic. I’ve seen design processes work—and come to the realisation that “My own designs benefited from rapid iteration!”

The benefit of design These humbling experiences helped me learn to trust the process, even in the face of frustration or panic. It’s these experiences that give me the courage to follow the design process, even when it isn’t clear how to resolve the tension between conflicting design constraints.

In the face of an unknown, individuals and especially teams tend to turn to knowns. If needed, they’ll manufacture the known data, by deferring the choice to users. Here’s part of what Larry Constantin wrote about courage in software design, in a paper that advocates for user involvement at the right time:

Most damning and least recognized among the limitations of user-centered design is the way it subtly discourages courage. Courage is one of the central tenets of extreme programming and agile development methods. […] User-centered design makes it too easy for designers to abdicate responsibility in deference to user preference, user opinion, and user bias. In truth, it is hard to stick with something you know works when users are screwing up their faces at it. What if you are wrong? What if you are not as good a designer as you thought you were? It takes real courage and conviction to stand up for an innovative design in the face of users who complain that it is not what they expected or who want it to work just like some other software or who object to certain sorts of features as a matter of course. It takes responsible judgment to know when to listen to users and when to ignore them.

In the many design sessions I have facilitated, three times I’ve seen that lack of courage expressed by a participant. Each time, it sounded like a mix of panic and frustration:

The solution has been on the wall since the first round!

The design sessions I facilitate ask participants to saturate the design space with lots of ideas. They each bring five sketches—five substantially different ideas—and then, after sharing their ideas with the other participants, they rapidly iterate the first 15 or 20 sketches to develop even more. All this takes place before any analysis.

When the goal is to saturate the design space—to identify as many solutions as possible in a short time—there’s more to influence the design once the analysis begins. Inevitably, the design that the team decides on was not already on the wall. Motivated design participants quickly learn this, and—in most cases—become advocates of the process.

For most development teams, the Five Sketches™ process I introduce is a departure from the status quo, so it takes courage for their team members to take a stand, to say “I will use this process” for design problems that need it.

9 May 20093 May 2009

Speed sketching vs. art/perfectionism

For a Five Sketches™ design session, I ask design participants to bring at least five substantially different ideas to the table, in the form of sketches. A common initial reaction is: “…But I can’t sketch!”

Many design participants believe they cannot draw. To be honest, I believe that about myself. People who feel they cannot draw tend to extend that belief to encompass design sketching, as well. However, I have learned to distinguish between drawing (below, left) and sketching a software design (below, right).

Drawing versus sketching

Software design does not require drawing, only sketching. From experience, I can tell you that sketching is easy once you realise that the goal is to produce only rough and low-fidelity ideas, not decorative and high-fidelity pictures.

Occasionally, I encounter a design participant who has trouble with sketching. I once had a participant who was so self-conscious of her sketching ability that she was paralyzed during the rapid iteration phase, when the design participants are quickly mashing up the sketches with borrowed and new ideas to produce additional sketches. I noticed that this participant was always busy—talking or wiping the board or replacing the snacks—but never sketching. This avoidance, and the underlying mental block, was an impediment to the whole team. Like all generative design processes, Five Sketches™ relies on its participants to saturate the design space with ideas. If a participant isn’t participating, it increases the project risk.

To pre-empt this mental block and to reduce the project risk, during Five Sketches™ training, I now introduce a quick speed-sketching exercise. Speed sketching is a race against the clock. With pen and paper ready, before each round, I give the participants five seconds to think, and then:

10 seconds to sketch a cell phone.
8 seconds to sketch a sandwich.
6 seconds to sketch an airplane.
4 seconds to sketch a ship.
2 seconds to sketch a house.

After each sketch, the participants look at the other sketches. I ask them to identify the details that make the sketched object recognisable. There isn’t time to draw a high-fidelity rendering, so the sketches are rough and have few details.

Interestingly, with few details the sketched objects are still clearly recognisable. Participants learn that detail and fidelity aren’t needed. By the last round of sketches—the “2 seconds to sketch a house” round—participants have seen that everyone’s ability to produce sketches is about equal, and they usually conclude: “I sketch well enough for others to grasp my ideas.” Generative design requires lots of ideas—disposable ideas—not fancy drawings.

Jason Santa Maria says a similar thing in his Pretty Sketchy blog post, in which he declares that sketching is not about being a good artist; sketching is about being a good thinker.

1 May 200924 April 2009

Sketch, wireframe, prototype

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.

divergence-and-convergence

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:

29 April 200922 April 2009

Low-fi sketching increases user input

Here are three techniques for eliciting more feedback on your designs:

show users some alternatives, so more than one design.
show users a low-fidelity rather than high-fidelity rendering.
ask users to sketch their feedback.

To iterate and improve the design, you need honest feedback. Let’s look at how and why each of these techniques might work.

Showing alternative designs signals that the design process isn’t finished. If you engage in generative design, you’ll have several designs to show to users. Users are apparently reluctant to critique a completed design, so a clear signal that the process is not yet finished encourages users to voice their views, but only somewhat.

Using a low-fidelity rendering elicits more feedback than the same design in a high-fidelity rendering. Again, users are apparently reluctant to critique something that looks finished—as a high-fidelity rendering does.

hi-fi_vs_low-fi_sketching

The design is the same, but it feels more difficult to criticise the one on the right.

Asking users to sketch their feedback turns out to be the single most important factor in eliciting feedback. It’s not known why, because there hasn’t been sufficient published research, but I hypothesize that it’s because this is the most indirect form of criticism.

Where’s the evidence for sketched feedback?

The evidence is unpublished and anecdotal. The problem with unpublished data is that you must be in the right place at the right time to get it, as I was during the UPA 2007 annual conference when Bill Buxton asked the room for a show of hands. Out of about 1000 attendees, several dozen said they had received more and better design-related feedback by asking users to sketch than by eliciting verbal feedback.

When you ask a user: “Tell me how to make this better,” they shrug. When you hand them a pen and paper and ask: “Sketch for me how to make this better,” users start sketching. They suddenly have lots of ideas.

My own experience agrees with this. In Perth, Australia, I took sketches from a Five Sketches™ design session to a customer site for feedback. I also brought blank paper and pens, and asked for sketches of better ideas.

Not surprisingly, the best approach is to combine all three techniques: show users several low-fidelity designs, and then ask them to sketch ways to make the designs better.

15 April 200918 April 2009

Are five sketches too many?

I first heard Bill Buxton talking about sketching in Texas, at the UPA 2007 annual conference. I was running around with a video camera asking people what they thought of Bill Buxton’s presentation. Everyone loved it, including his ideas on sketching and design. But almost everyone I spoke to also said Buxton’s requirement for five sketches was several sketches too many.

Buxton’s probably heard this objection a few times, because he addressed it at Mix09, last month in Nevada. He said:

I can hear your clients and your managers saying: “Well, Mr Buxton may have told you that you have to be able to do five different versions for every single question you’re asked—each one equally valid—but we can’t afford it because we’re already behind schedule. We don’t even have time to do one solution, and you’re telling me we have to do five?”

What are you going to say to them?

It’s a good question. Buxton also had an answer. “Doing multiples is critically important” because it’s how you saturate the design space with enough ideas to rapidly iterate to the best design solution. The challenge, says Buxton, is to balance “doing multiples” with the budget, with dollars, time, and personnel.

It comes down to technique.

Sketching is a fast, inexpensive, and therefore disposable way to capture ideas. And five really is key. In my experience, when I asked design participants for two or three sketches, they each brought “two”—actually versions of the same sketch where one had an extra squiggle or mark on the page. This is not how you saturate a design space. It has to be at least five—hence the name, Five Sketches™. The sketches have to be fast. They have to be low fidelity. The sketches have to be disposable.

Sketching is the right tool. You also need the right team, working at the right time. The right team has an understanding of generative design and knows that there’s a time to sketch, a time to iterate and analyse design ideas, and a time to code or program. (A team of three or four design participants can learn and practice everything but the programming in a half day.) In my experience, design participants—developers, QA staff, marketing staff, support staff—can sketch and produce great software and web designs as effectively as a graphic designer or industrial designer can.

Again: it comes down to technique. And since sketching is cheap, you can’t afford not to design.

14 April 200913 April 2009

Why pen+paper is better

When solving a software-design problem or a web-design problem, you get the best results from following a design process. I’m not referring to something I made up. I’m referring to something that people who are trained in “Design” will recognise as a design process. And such processes inevitably include divergence and convergence.

Divergence is the stage when the designer or design participants come up with ideas. Lots of ideas. Not just comfortable ones, but ideas that push at the edge of the envelope. Ideas without judgement.

Convergence is the stage when ideas are judged, rapidly iterated, assessed, and checked against the requirements.

In my experience, divergence is best done by sketching, with a pen on paper:

ideation-methods-on-a-graph

Sketching on paper with a wide-nib pen is best because this “technology” is familiar—it’s easy—and inexpensive. Everyone can Wide-nib marker have a pen and paper, so there’s no need to wait your turn. Sketching is fast, so designers have little invested in any one sketch. Modifying or iterating any one of the ideas is easier to accept. Most importantly, for inexpert sketchers, the sketching process intrinsically discourages high-fidelity work and the wide-nib pen discourages sketching the fine detail that detracts design participants from getting the ideas out, fast.

Software that’s intended to help people “sketch” detracts from a good result. The software often lets users build prototypes with a great level of interaction detail. The problem with this: attention to detail is a distraction at the divergence stage. When filling the design space with ideas, it’s sufficient merely to evoke the idea and share it. Ambiguity actually helps the team see more than one idea in the same sketch; each interpretation of the idea can be iterated. Software that’s not intended to help people to “sketch” slows them down at the divergence stage—just when we need ideas to flow quickly. Divergence is about filling the design space with lots disposable ideas.

Read my blog post about why ideas are disposable.

2 April 200918 April 2009

Ideas are disposable

Having a good design idea is not an amazing event. Sketching works People have good design ideas all the time. What is amazing is having lots of good design ideas, so that they can be combined and iterated into the best possible design.

Here’s why ideas are disposable:

Sketching lets you capture lots of ideas, quickly and inexpensively.
The more ideas you try for, the sooner you learn that it’s easy to come up with five or more ideas.
The easier it gets to have lots of ideas, the sooner you realise the value of any one idea is minimal.

Minimal value = disposable.

This is one of the keys to the success of Five Sketches™. Once you learn how easy ideas are to have, you can saturate the design space, iterate the design, and produce excellent design outcomes at will.

24 March 200924 March 2009

Common tasks losing usability

There’s been a loss of usability for people who type text.

Like me, you may have experienced these unwelcome experiences:

After typing a long message in Facebook, when I click send, I get a page error and my entire message is lost.
After typing a post in WordPress, if the server has gone down or I press an unintended keyboard shortcut, I lose my entire post.

By comparison, if Word stops responding, it will (try to) offer me my unsaved changes when I reopen the document.

With users increasingly doing their work in browsers, why don’t browsers remember the text we were typing? Or why doesn’t the operating system? Or why doesn’t the weblication make backups? Or the server?

When my actions in a browser fail, imagine a message such as this:

This hints at just one possible solution. In the spirit of Five Sketches™, I bet you can come up with at least five more ways to support users after they’ve lost the work they typed in a browser.

15 March 200913 May 2022

Generative design vs. Five Sketches™

© Leah Buley, from her presentation on SlideShare Leah Buley talked about generative design at the South by Southwest Interactive conference today [in March 2009]. Buley feels design methods are lacking in the set of professional tools we use for software development: “We don’t have so many good, reliable, repeatable design techniques.” I agree with her.

Buley tells how, in her first design session at Adaptive Path, she was handed a pen and paper, and told to sketch. The point was “to crank out a lot of ideas in a short time.” That’s what generative design is all about: saturating the design space with ideas. Design programs teach generative design, but there’s no generative design taught in programs for developers, QA staff, technical communicators, product management, or marketing.

There are already several design methods for software development teams to choose from, including Buley’s wonderful grab bag. Others I know of are Five Sketches™ (obviously) and Design Studio, both of which focus on the complete process of producing a design, start to finish, with all its challenges. Microsoft’s Bill Buxton told the UPA 2007 conference that he insists on generative design, and I’d love to see that in action. Each method differs slightly, but they all work because….

Why do they all work? Because of generative design. Generative design addresses what Buley calls her “dirty secret.” She freely confesses, about her design work before Adaptive Path: “I had very little confidence that what I was presenting as the design was in fact the one, optimal solution to the problem.” My experience teaching Five Sketches™ tells me that once you’ve participated in a generative-design process, you’ll know that you can have that confidence.

A related question: when will computer science programs teach Basic Design Methods to developers?