Design, process, business – Page 7 – Usability research and analysis

21 April 200918 April 2009

Teamwork reduces design risk

It takes a range of skills to develop a product. Each skill—embodied in the individuals who apply that skill—brings with it a different focus:

Product managers talk about features and market needs.
Business development talk about revenue opportunities.
Developers talk about functionality.
Usability analysts talk about product- and user performance.
Interaction designers talk about the user experience.
QA talks about quality and defects.
Marketing talks about the messaging.
Technical communicators talk about information and assistance.
You may be thinking of others. (I’m sorry I’ve overlooked them.)

What brings all these together is design.

Proper design begins with information: a problem statement or brief, information about the targeted users and the context of use, the broad-brush business constraints, Design as a team some measurable outcomes (requirements, metrics, or goals), access to a subject-matter expert to answer questions about the domain and perhaps to present a competitor analysis.

Design continues by saturating the design space with ideas and, after the space is filled, analysing and iterating the ideas into possible solutions. The design process will raise questions, such as:

What is the mental model?
What are the use cases?
What is the process?

The analysis will trigger multiple rapid iterations of the possible solutions, as the possible solutions are worked toward a single design:

Development. What are the technical constraints? Coding costs? Effect on the stability of the existing code? Downstream maintenance costs?
Usability and experience. Does the design comply with heuristics? Does it comply with the standards of the company, the industry, and the platform? Does paper-prototyping predict that the designed solution is usable?
User experience. Will the designed solution be pleasing due to its quality, value, timeliness, efficiency, innovation, or the five other common measures of customer satisfaction?
Project sponsor. Is the design meeting the requirements? Is it reaching its goals or metrics?

It’s risky to expect one person—a developer, for example—to bring all these skills and answers to the table. A team—properly facilitated and using an appropriate process—can reduce the risk and reliably produce great designs.

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.

10 April 20094 April 2009

Ten-year-old advice

Fresh advice, still:

“Usability goals are business goals. Web sites that are hard to use frustrate customers, forfeit revenue, and erode brands.

Executives can apply a disciplined approach to improve all aspects of ease-of-use. Start with usability reviews to assess specific flaws and understand their causes. Then fix the right problems through action-driven design practices. Finally, maintain usability with changes in business processes.”

—McCarthy & Souza, Forrester Research, September 1998

8 April 200913 April 2009

How to test earlier

Involving users throughout the software-development cycle is touted as a way to ensure project success. Does usability testing count as user contact? You bet! But since most companies test their products later in the process, when it’s difficult to react meaningfully to the user feedback, here are two ways to get your testing done sooner.

Prioritise. Help the Development team rank the importance of the individual programming tasks, and then schedule the important tasks to complete early.

If a feature must be present in order to have meaningful interaction, then develop it sooner.

For example, email software that doesn’t let you compose the message is meaningless. To get meaningful feedback from users, they need to be able to type an e-mail.

Developers often want to start with the technologically risky tasks. Addressing that risk early is good, but it must be balanced against the risk of a product that’s less usable or unusable.

If a feature need not be present or need not be working fully in order to have meaningful interaction, then provide hard-coded actions in the interim, and add those features later.

For example, if the email software lets users change the message priority from Standard to Important, hard-code it for the usability test so the priority is always Standard.

If a less meaningful feature must to be tested because of its importance to the business strategy, then develop it sooner.

For example, email software that lets users record a video may be strategically important for the company, though users aren’t expected to adopt it widely until most laptops ship with built-in cameras.

Schedule. For each feature to be tested, get the Development team to allocate time to respond to usability recommendations, and then ensure this time is neither reallocated to problem tasks, nor used up during the initial development effort of the to-be-tested features. Engage the developers by:

Sharing the scenarios in advance.
Updating them on your efforts to recruit usability-study participants.
After developers incorporate your recommendations, retesting and then reporting improvements in user performance.

Development planning that prioritises programming tasks based on the need to test, and then allows time in the schedule to respond to recommendations, is more likely to result in usable, successful products.

6 April 20096 July 2015

Please exit your comfort zone

People approach business problems in different ways. Some people want to identify the many possible solutions, up front. Others want to fully understand and assess one solution before considering the next solution. And still others want to start implementing a reasonable solution immediately, to see how well it works, and then, in learning from experience, modify that idea to make it work better. This difference in people’s natural tendency or impulse is called conative style—it’s the default way they direct their effort.

But a person’s default behaviour isn’t the only way they can direct their effort. People can adopt a different conative style—for a while. Most people in the workplace have done this successfully. However, when the pressure is on, people tend to resort to their preferred conative style, as they instinctively seek some comfort. And workplace problems often come with pressure, don’t they?

The other thing workplace problems often come with are project teams, inevitably made up of people who have different conative styles. That’s actually a benefit—Dr Meredith Belbin claims that teams team diversity is essential to success for projects in general. For design projects, specifically, team diversity is also important. But consider these pitfalls that design teams naturally face:

Time-and-cost constraints and other pressures mean the team members naturally adopt their default conative styles.
Team members have different conative styles, so they unintentionally work at cross-purposes. One want to generate candidate solutions, another wants to start building, and a third wants to compare and assess.
The team members with the strongest personalities have disproportionate influence.
The contributions of quieter voices get missed, causing disengages team members and overlooked ideas.

This natural dynamic can actually put great design outcomes out of reach. That’s because:

Design is more likely to succeed when many ideas are generated up front, and analysis is delayed until after all ideas are generated.
Idea generation is an ideation conative style, but analysis is a judgement conative style.
Ideation and judgement are opposite conative styles.

Design is stressful for people who have a judgement conative style and haven’t had previous success with ideation. Since, under pressure, people resort to their preferred conative style, Five Sketches™ has specific things to encourage non-designers to engage in generative activity (to generate ideas without analysing them). Developers are great at analysis, logic, reason, examination, which are typical of a judgement conative style, so during Five Sketches training, we present a model of the conative styles that appeals to their judgement: we plot the styles, we provide data from of previous projects (as social proof), and we provide a timeline that shows them ideation will be a temporary activity. During the ideation stage, there are specific actions and reminders to keep people on the ideation side until it’s time for everyone to move to the judgement side of the ideation-judgement axis. Over the space of several hours, this is what happens:

Experience shows that it works. After a brief foray outside their comfort zones, developers and other non-designers get to return to their preferred conative styles. The benefits: design outcomes are better; stakeholders are included and heard; requirements are met; and the development schedule is the same or shorter.

4 April 20096 April 2009

Design can change the culture

I was reading a comment by Creative Sage CIO and CEO, Cathryn Hrudicka, about corporations that want to use social media to reach their market:

The process of trying to become a more “transparent” organization, so they can use social media tools, pushes many organizations—companies, nonprofits, trade associations—into change, especially if they have had a very bureaucratic and non-transparent culture before. That can mean many levels of changes, which usually bring up issues between executives or managers and their teams, and it can affect relationships between staff or team members. Individuals often need to be coached to adapt to the new practices or even to drive them more effectively. Some leadership and teamwork issues come up, too.

It reminded me of a company that changed after I was asked to introduce an ideation-design method. The management team wanted the method to do double duty—a way to empower and encourage the development team.

Prior to this, it seemed team members had been discouraged from taking design initiative. Half the team was disheartened or miserable, the other half of the team was disengaged to the point where they wouldn’t offer a design suggestion even when asked by their boss. Initially, some team members took a wait-and-see approach, but after training and several successful project experiences, the majority of developers became increasingly comfortable with involvement in product design.

It took commitment from key managers to invigorate the team, and it took considerable time. They still use Five Sketches™ today.

If you liked this post, check out a recent post about Google’s corporate culture.

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.

29 March 20094 April 2009

Design and engineering culture

I’m sure Douglas Bowman’s blog last week was widely read. His post was a kind of public exit interview, titled Goodbye Google.

Goodbye Google As Bowman left Google, he pointed out the pro-engineering bias in its approach to problem solving—including problems of design. Two of several examples he gives:

[…] a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. […]

Bowman would like to see more weight put on design principles. His blog includes a link to Wikipedia’s article on design elements and principles, which lists:

•	unity	•	harmony	•	contrast
•	balance	•	repetition, rhythm, pattern	•	variety, alternation
•	emphasis, dominance, focal point	•	proportion, scale	•	functionality
•	attraction	•	artistic unity	•	genuineness in media and form
•	proximity	•	colour

I don’t think design principles are beyond an engineer. I do think engineers need to be taught how—and when—to think about these details.

As we discovered during the development of Five Sketches™, this kind of detail is often outside the comfort zone of an engineer. However, I can affirm that even engineers who initially produce work with little design insight or creativity have managed to astonish me with amazing design results within a year. And that’s after only occasional participation in Five Sketches™ design sessions.

So, yes, engineers can learn to participate in design, with success and predictability, though I would caution that Five Sketches™ works for engineers because it was developed for and with them, to meet their needs.

At Google, to bring about such a cultural change, Bowman would have needed the unwavering support of at least one senior executive. Even then, as Bowman himself acknowledged in his goodbye message, a company as large as Google does not change direction easily.

If you liked this post, read about how a company’s use of social media influences its corporate culture.

27 March 200922 March 2009

User mismatch: discard data?

When you’re researching users, every once in a while you come across one that’s an anomaly. You must decide whether to exclude their data points in the set or whether to adjust your model of the users.

Let me tell you about one such user. I’ll call him Bob (not his real name). I met Bob during a day of back-to-back usability tests of a specialised software package. The software has two categories of users:

Professionals who interpret data and use it in their design work.
Technicians who mainly enter and check data. A senior technician may do some of the work of a professional user.

When Bob walked in, I went through the usual routine: welcome; sign this disclaimer; tell me about the work you do. Bob’s initial answers identified him as a professional user. Once on the computer, though, Bob was unable to complete the first step of the test scenario. Rather than try to solve the problem, he sat back, folded his hands, and said: “I don’t know how to use this.” Since Bob was unwilling to try the software, I instead had a conversation (actually an unstructured interview) with him. Here’s what I learned:

My observation		For this product, this is…
•	Bob received no formal product training. He was taught by his colleagues.	Typical of more than half the professionals.
•	Bob has a university degree that is only indirectly related to his job.	Atypical of professionals.
•	He’s young (graduated 3 years ago).	Atypical of professionals, but desirable because many of his peers are expected to retire in under a decade.
•	Bob moved to his current town because his spouse got a job there. He would be unwilling to move to another town for work.	Atypical. Professionals in this industry typically often work in remote locations for high pay.
•	Bob is risk averse.	Typical of the professionals.
•	He is easily discouraged, and isn’t inclined to troubleshoot.	Atypical. Professionals take responsibility for driving their troubleshooting needs.
•	Bob completes the same task once or several times a day, with updated data each time.	Atypical of professionals. This is typical of technicians.

I decided to discard Bob’s data from the set.

The last two observations are characteristic of a rote user. Some professionals are rote users because they don’t know the language of the user interface, but this did not apply to Bob. There was a clear mismatch between the work that Bob said he does and both his lack of curiosity and non-performance in the usability lab. These usability tests took place before the 2008 economic downturn, when professionals in Bob’s industry were hard to find, so I quietly wondered whether hiring Bob had been a desperation move on the part of his employer.

If Bob had been an new/emerging type of user, discarding Bob’s data would have been a mistake. Imagine if Bob had been part of a new group of users:

What would be the design implications?
What would be the business implications?
Would we need another user persona to represent users like Bob?