Tag: design

Posted on

Standard OK-Cancel button order

I have two stories about command buttons.

Quite a few years ago, a team member walked me through a new dialog box. He entered some data, and then unintentionally clicked the Cancel button. He made this error twice in a row, thus losing his changes twice in a row. I pointed out that the OK and Cancel buttons were in the wrong order. The developer switched the buttons to the Windows-standard layout (below, right), and the user-performance problem was solved.

A few years later, on a different project, not only were the buttons in non-standard order, they used non-standard wording and they used coloured icons. My request to follow the Windows standard was met only half-way and then sent for Beta testing before I saw it again. The buttons were now in the correct order, but the button names were changed, and the names and icons were still non-standard. Beta testers loudly protested the change. (Beta testers are often expert users, and experts abhor any change that slows them down.) At the time, the company was only a few steps up the Neilsen Corporate Usability Maturity model, so instead of completing the change to Windows-standard OK and Cancel buttons, the buttons were rolled back, to appease the protesting Beta users. I found out too late to retest with Windows-standard buttons, so there was no data to convince the developers. For me, it was an opportunity to learn from failure. :)

Why is non-standard so hard?

Try this Stroop test (right). Ignore the words. Instead, identify the colours, out loud. No doubt, the second panel went slower and took more effort.

Try the variation, at left. Find the first occurrence of the word Blue. Next, find the first occurrence of the colour █.

Just as mismatches between text and colour slow your Stroop-test performance, mismatches between standard and non-standard OK and Cancel buttons slow user performance. Our Beta users clicked the wrong buttons—a huge waste of their time—because the new solution didn’t follow any standard. The Beta testers were right to protest, but wrong in their demand to revert to the original non-standard state. (See: Customers can’t do your job.)

Users learn GUI patterns—patterns that are widely reinforced by user experience—and users expect GUI to behave predictably, so it’s unwise to deviate radically from the standards, unless there are product-management reasons to do so.

I’ll write more about following standards versus designing something new in the coming few posts.

P.S. It looks like Jakob Nielsen got here before me.

Posted on

Heuristics at the design stage

On the IxDA’s discussion list for interaction designers, Liam Greig posted his “human friendly” version of a heuristics checklist based on Nielson’s originals and the ISO’s ergonomics of human-system interactions.

Here are  just the headings and the human-friendly questions, which are useful at a project’s design stage.

A design should be…

  • transparent. Ask: Where am I? What are my options?
  • responsive. Ask: What is happening right now? Am I getting what I need?
  • considerate. Ask: Does this make sense to me?
  • supportive. Ask: Can I focus on my task? Do I feel frustrated?
  • consistent. Ask: Are my expectations accurate?
  • forgiving. Ask: Are mistakes easy to fix? Does the technology blame me for errors?
  • guiding. Ask: Do I know where to go for help?
  • accommodating. Ask: Am I in control? Am I afraid to make mistakes?
  • flexible. Ask: Can I customize my experience?
  • intelligent. Ask: Does the technology know who I am? Did the technology remember the way I left things?

Sometimes, at the analysis end of a Five Sketches™ ideation-design session, the design participants see more than one path forward. Use heuristics to frame the discussion of how each path rates, to reach a decision faster.

The heuristics can be about more than just usability. You can also assess coding costs, maintenance costs, code stability…. And, of course, you must also assess potential designs against the project’s requirements.

Posted on

Designing *with* developers

Today, Joel Spolsky blogged about development process and design. He makes a couple of points I agree with. As an example, he says that developers don’t know how to do everything. He says it first by describing his lack of skills in an early job at Microsoft, and later by describing the lack of skills in very experienced developers:

Joel SpolskyYour garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU’RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining what it must be like not to be able to memorize 16 one-letter command line arguments. These programmers then have a tendency to get attached to their first ideas, especially when they’ve already written the code.

At this point, reading Spolsky’s blog, I’m like the eager school kid with his hand up: “Oh, oh, I know the answer!” Five Sketches™ was specifically developed to prevent the people-attached-to-their-first-ideas problem and to ensure collaboration between developers and other members of the team.

Software products are developed by teams, but, as Spolsky goes on to say—about developers—some team members have more power those who work alongside them, because developers control the code. He tells this story:

Joel Spolsky       A programmer asks me to intervene in some debate he is having with a [non-developer peer; in this story it’s a Program Manager who performs a design function].
       “Who is going to write the code?” I asked.
       “I am….”
       “OK, who checks things into source control?”
       “Me, I guess, ….”
       “So what’s the problem, exactly?” I asked. “You have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?”

Spolsky’s solution is to rely on the ability of others [in this case, the Program Manager] to convince the developer to make necessary changes. But requiring stakeholders and colleagues to engage in persuasion is risky; the variables include not only technical skill and experience, but also credibility, and rhetoric, persuasion, and interpersonal communication skills of both parties.

I recall when we first developed our ideation-design process, on an interdisciplinary team. We had Sharon to debrief each of us, to find out what had worked and what hadn’t, and then we addressed the shortcomings and frustrations in the process. This is how we developed Five Sketches™. And this is why it works … with developers … and with people from QA, Marketing, Tech-Comm, and so on.

By the way, you can read Joel Spolsky’s entire blog post here.

Posted on

Customers can’t do your job

Agile methodology can produce usable products, as long as you know what you’re doing. A common pitfall in agile is this incorrect assumption that you’ll get a usable product simply by building what the client tells you to build.

When there is some question about how to make a feature usable, customers may have something to say, but their answers are more likely based on opinion and emotion rather than on design experience and behavioural observation.

Brazilian blogger and computer-science- and HCI expert, Francisco Trindade, gives this illustration: If you had asked people how they would like to search for Web pages in the pre-Google era, how many would have asked for a blank page with a text box on it…?

Can customers design? Probably not.Trindade says that, regardless of whether this ask-the-client behaviour is laziness or a responsibility-avoidance strategy, people who design software need to “stop pretending that the client has all the answers, and trust a little bit more in themselves to create solutions.”

Creating solutions? That’s a job for developers and the Five-Sketches™ method, or any other design method they’re comfortable with.

Posted on

From napkin to Five Sketches™

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 usable products
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:

  1. Design requires three steps.
  2. Not everyone is comfortable with each of those steps.
  3. 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 preferences or 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.

Posted on

Rigid UCD methodology fails?

I received an e-mail from someone at the 2008 IA Summit about Jared Spool’s declaration that UCD is dead:

——Forwarded message——
From: P
Date: Sun 13/04/2008, 2:54 PM

Hi Jerome,

I’m at the iA Summit in Miami right now, and hearing about all of the things that are going on makes me think of you. One of the interesting sessions was Jared Spool’s keynote speech. He conducted research into what makes certain companies better able to produce effective designs. He used this model to talk about the various approaches departments do to facilitate design:

Things that facilitate design

He said all design involves a process, whether it’s been formalized or not. Interesting, though not surprising: companies that have dogmatic UCD leadership or use a rigid UCD methodology are unlikely to create anything innovative. To innovate, you want to apply techniques in sometimes surprising ways to solve problems that they were not intended for (those are the “tricks”.)

OK, I’m going back out in the warm (hot!) weather.

– P

Of course, the lack of process doesn’t guarantee innovation, either, nor does it guarantee you’ll be able to repeat your (accidental) successes. I believe a successful design process must involve some form of generative design—as Five Sketches™ does—that’s based on knowledge of user condition. I also beleive that, once you’ve internalised those two things, you can use almost any form of facilitation to design good products.

Posted on

A sketch must be disposible

The strength of sketching is that it’s a fast way to capture ideas.

Since a low-fidelity sketch is fast—pen on paper, as shown—it’s also low cost. And low cost means it’s relatively disposable if it turns out you can’t use that idea.

If you don’t like my first 5 ideas, that’s OK. I can have more ideas, easily and at low cost. And so can you.

A variation on this theme: iteration is also painless. With relatively little invested in a sketch, modifying an idea costs marginally more.

The payoff is that you can quickly saturate the problem space with ideas, before you analyse them. This is a key part of why Five Sketches™ works so well for development teams who are in a hurry to start programming.

It’s important to keep sketches cheap. Here’s a video of a cool sketching tool that, if used as a design aid, would greatly increase the project risk. That’s because this cool tool is expensive to install, expensive to learn (it requires training) and expensive to use (it allows only 1 user at a time). All this will reduce the number of sketches in the problem space—and it’s risky to design without considering all options.

The Assist Sketch Understanding System (ASUS) design environment: a computer interprets a sketch and then simulates a cart rolling down a hill.
Posted on

Make your project win

Here are two usability stories that are currently underway.
The first project

This weekend I got a Skype call from a usability consultant at a very large firm that is, in turn, working on a project for a very large insurance company. The usability consultant was just assigned, but the team is nearly finished building an online application form for household insurance. He told me:

  • The design is due Friday. Developers will start building it on Monday.
  • how-easy-it-itThe design is restricted by a related piece of the site that’s already being built (offshore).
  • Customers must answer potentially hundreds of questions, and the company wants every answer cumulatively displayed on screen. It’s not clear why, so designing alternatives means shooting in the dark.
  • Customers must provide their complete personal and confidential identification-before they get a quote or decide whether to buy. It’s not clear why.
  • After answering all questions and providing personal information, many customers will be deemed ineligible to buy insurance online, due to answers that sounded innocuous to me.
  • There’s no time to test the design by Friday.
The second project

Today I spoke to a manager at a different company. Their current project is software that makes work schedules. So far, the team has:

  • Asked users for problems in the current product.
  • Weighed the severity and frequency of user problems. The worst problems related to starting a new schedule, figuring out where to enter data, and understanding how the data and settings influence the schedule.
  • The worst problems became top priority in the current project.
  • A major GUI redesign is underway. This includes step-by-step workflow support, drag-and-drop interaction, and replacing data-entry spreadsheets with dialog boxes or task panes.
  • The product manager wants usability testing done on the redesigned GUI, while there’s still time to make changes.

What can you do to ensure your projects are like the one in the second story?

Posted on

Design Studio vs. Five Sketches™

I came across a software-design approach similar to Five Sketches™. It’s called Design Studio, and was developed in the USA. I was intrigued to learn about Design Studio. When separate teams develop a similar response to the same challenge, it validates both solutions. In this case, the challenge is to support software developers as they design the mental models, interaction, and GUI for their products.

Video no longer availableDesign Studio was presented at a 2007 conference, and you can watch it on video: but the BrightCove video is no longer available to watch.

If you have information about Design Studio, please comment, below. Found it! Jeff White and Jim Ungar presented their Design Studio method at the IxDA 2008 conference, in a presentation titled User Interface Design in an Agile Environment: Enter the Design Studio.

Posted on

Choose: usability or features?

I was talking to a B2B product manager who told me “The industry we target sees little difference between our product and our competitors.” Their plan is to differentiate their product from its competitors. My question: to make your software different from that of the competition, should you mainly add new functionality or mainly improve the usability?

LeapfroggingBob Holt addresses this question in his article, Death by 1000 cuts. He asks: “As the worlds of our customers and our own business models continue to change and evolve, should we be changing the balance between improving the usability of our current products and adding new functionality?” Holt answers his own question: “I say absolutely yes. After all, it wouldn’t it be a shame if our revenues bled out through a thousand little cuts while we are rushing around trying to build the next Big Thing?”

But the same product manager I mentioned above also told me: “I firmly believe that you cannot win only by addressing usability. You must also look for the future of the market—that is, you won’t innovate past your current box—to avoid getting leapfrogged.”