software design – Page 3 – 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.

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.

25 March 200927 March 2009

Why products stay pre-chasm

I’ve spent some time working with legacy products—software for which the core code was written before “usability” was a term developers had heard of, back when developers were still called programmers.

I remember my first conversation—held last century—with a developer about his users and the usability of his legacy product. The product-adoption curve, with the chasm I used Geoffrey Moore’s book, Crossing the chasm, to introduce the idea that there are different types of users. The chasm (illustrated) shows five groups of users. The area under the curve represents the quantity of potential users, in the order in which they will typically adopt the product. Users who are technology enthusiasts and visionaries either enjoy or don’t mind being on the bleeding edge because of the benefits they get from using the product, according to Moore. Usability isn’t one of the typical benefits to the left of the chasm, where new products are first introduced. Wider adoption follows only after the product is made to cross the chasm—but this takes a concerted effort on the part of the development team.

What delays a product from crossing the chasm?

Revenues that are sufficient to let the company putter along.
Team members who themselves are tech enthusiasts or visionaries. This occurs, for example, when a nutritionist who also knows how to program develops software for nutritionists.
Team members who have infrequent exposure to newer user experiences. This could include someone who still uses Microsoft Office 2003, eschews social-networking applications on the web, or uses Linux.
Product managers whose roles are weakly defined or absent, making it more likely that new features get developed for the technical challenge of it, rather than for the user need or the business strategy.
Sales reps who ask for more functions in the product in order to make a sale—and a development culture that goes along with this.
Managers whose vision and strategic plan leave out user experience and usability.
Team members who have been on the team for decades.
Organisations that don’t use business cases to help them decide where to apply business resources.
Organisations with poor change-management practices—because moving a product across the chasm is more likely dramatic and disruptive than smooth and gradual.
Designers who are weak or absent in the process, so that “design” happens on the fly, during development.

If you recognise your work environment or yourself in this list, do you want to change things? If you do, but don’t know how, what actions can you take to learn the answer?

23 March 200923 March 2009

Which user involvement works

User-centred design (UCD) advocated involving users in the design process. Have you wondered what form that user involvement could take, and which forms lead to the most successful outcomes?

I recently came across data that Mark Keil published a while ago. He surveyed software companies and correlated project outcomes with the type of user access that designers and developers had.

Type of contact with users		Effectiveness
	For custom software projects
	Facilitate teams, hold structured workshop with users, or use joint-application development (JAD).	██████████
	Expose users to a UI prototype or early version to uncover any UI issues.	██████
	Expose users to a prototype or early version to discover the system requirements.	████
	Hold one-on-one semi-structured or open-ended interviews with users.	████
	Test the product internally (acceptance testing rather than QA testing for bugs) to uncover new requirements.	██
	Use an intermediary to define user goals and needs, and to convey them to designers and developers.	██
	Collect user questions, requirements, and problems indirectly, by e-mail or online locations.	█
	For packaged or mass-market software projects
	Listen to live/synchronous phone support, tech-support, or help-desk calls.	████████
	Hold one-on-one semi-structured or open-ended interviews with users.	██████
	Expose users to a UI prototype or early version to uncover any UI issues.	████
	Convene a group of users, from time to time, to discuss usage and improvements.	████
	Expose users to a prototype or early version to discover the system requirements.	██
	Test the product internally (acceptance testing rather than QA testing for bugs) to uncover new requirements.	██
	Consult marketing and sales people who regularly meet with and listen to customers.	██
	At trade shows, show a mock-up or prototype to users and get their feedback.	█
Not reported as effective in this 1995 source
	Conduct a (text) survey of a sample of users.
	Conduct a usability test to “tape and measure” users in a formal usability lab. (This study precedes such products as TechSmith Morae.)
	Observe users for an extended period, or conduct ethnographic research.
	Conduct focus groups to discuss the software.

Although Keil’s article includes quantitative data, his samples are small. I opted to show only the relative usefulness of various methods. My descriptions, above, are long because the original article uses 1995 terms that have shifted in meaning. I believe some of the categories now overlap, due to changes in technology and method. For example, getting users to try a prototype of the UI in order to uncover UI issues sounds like the early usability testing that I do with TechSmith Morae, yet the 1995 results gave these activities very different effectiveness ratings.

For details, see the academic article by Mark Keil (Customer-developer links in software development). Educational publishers typically require a fee for access.

These methods also relate to research I’m doing on epistemology of usability analysis.

22 March 200922 March 2009

Are usability studies experiments?

When I conduct usability studies, I use a laptop and Morae to create a portable and low-cost usability lab. I typically visit the participant on site, so I can look around. I provide a scenario that participants can follow as they try using a new software feature. Morae records their voices, facial expressions, on-screen actions, clicks, and typing. The raw data gets saved in a searchable and graphable format. Afterward, I review the recorded data (I rarely have written notes) and make evidence-based recommendations to the feature’s project team.

For example, in one usability study I realised that the order of the steps was causing confusion and doubt. The three-step wizard would disappear after step, so users could modify their data on the screen. Users thought the task was completed with step 2, so the reappearance of the wizard for step 3 caused confusion. I recommended we change the order of the steps:

Change the order of the steps

Changing the order fixed the “confused users” problem. But was this scientific? Aside from the fact that I’m researching human subjects rather than test tubes, am I following a scientific model? At first glance, the usability test I conducted doesn’t seem to follow the positivist model of what constitutes an experiment:

A positivist model

For example, unlike the test-tube lab experiment of a chemist, my usability test had no control group. Also, my report went beyond factual conclusions to actual recommendations (based on my expert opinion) for the next iteration.

I can argue this both ways.

On the one hand, my usability test does have a control group if I take the next iteration of the product and repeat the usability test with additional participants, to see whether my recommendations solved the problem. I could compare the task-completion rates and the task duration.

A model of usability testing

On the other hand, if I were asked to determine whether the product has an “efficient” workflow or a “great” user experience—which are subjective measures—I’d say a positivist-model experiment is inappropriate. To measure a user’s confusion or satisfaction, I might consider their facial expressions, verbal utterances, and self-reported ratings. This calls for a research design whose epistemology is rooted in post-positivist, ethnomethodological, situated, standpoint, or critical approaches, and has more in common with research done by an ethnographer than by a chemist.

If you liked this, you may also like Epistemology of usability studies.

21 March 200920 March 2009

Internet Explorer leapfrogs Firefox?

Previously, I wrote about GUI—when to copy it and when to design it. When your competition has something better, I recommended you design, to leapfrog your competitor. Here’s an example of two competing web browsers:

At first glance, the new Internet Explorer 8 address bar looks like a copy of Firefox’s existing awesome bar, but click the image for an enlarged view. You’ll see that:

The on-the-fly suggestions are grouped as History and Favourites.
Each group lists only five items, by default.
To remove an item (think stale links and mistyped URLs), highlight the item and then click the × that appears.

Compared to Internet Explorer 7, Firefox had a better address bar. And just as clearly, the additional features of the Internet Explorer 8 address bar are an attempt to leapfrog Firefox. After the public has used IE8 for three months, it’ll be interesting to hear whether users think Microsoft succeeded.

Read the related post, GUI: Copy it or design it.

16 March 200926 March 2009

What “standard” GUI means

If you decide to forego the design stage and reuse or copy an existing GUI or interaction design, your life is easier.

But how do you know when you have a standard to follow?

An obvious place to find standards is in the precedents set by your own Development team. If your standards are not documented, consider a BarnRaising afternoon, once a month, until the high priority standards are documented.

And while many of us have enjoyed the comfort of a style guide to follow, there’s more flexibility now, as Milan Guenther wrote in Photos for interaction:

The barrier between web pages and desktop software is beginning to disappear, and modern rich client user interface technologies such as Silverlight/WPF, Air, or Java FX enables designers to take the control over the whole user experience of a software product. Style guides for operating systems like MacOS or Windows become less important because software products are available on multiple platforms, incorporating the same custom design independently from OS-specific style guides. Software companies and other parties involved begin to use the power of a distinct visual design to express both their brand identity and custom interactive design solutions to the users.

But not everything needs to be reinvented. There are plenty of common user tasks that the operating system supports with default GUI, including Open, Save, Print, Search/Replace, Font, Color, and Page Setup tasks. These also defaults serve as patterns for the custom GUI that you design—the visible objects, and the invisible ones, such as:

mental models
workflows

The two traditional operating systems give us plenty of standard controls to meet any design challenge, including buttons, boxes, sliders, progress indicators, notifications, and much more. If you develop for MacOS, Apple publishes various guidelines, including for user experience. If you develop for Windows, the Vista UX Guide is updated regularly, with new sections for ribbons, touch, pen, and printing.

sample-controls

Despite everything I just said about following standards, I’m also a big believer in changing things that are broken. An example: on my desk I can have two sheets of paper, copies of the same document. On my desk, they don’t need to have different names—even if each sheet has different comments written on it by different people. On my computer, the same two documents must either have different names or be in different folders. Surely the computer can keep track of both, uniquely, without forcing the user to choose different names? The unique-name requirement is an example of architecture dictating the interface. Alan Cooper wrote about this and other examples of tail wagging the dog in About Face: The essentials of user-interface design.

If you’re wondering when to copy/reuse, and when to design, check out my blog post, GUI: copy it or design it?