Tag: standards

Posted on

After you publish, test and review

As a consultant to business and government, I know my clients often see publishing as a project that has a start, middle, and end. Once they’ve published their app, their data, or their text and media, they often express relief that the job is finished and then want to forget about it.

The thing is, they’re not finished. If the app, data, or content is mission critical, they must not simply forget about it.

To illustrate what can happen when people publish and forget, here’s a simple story. It’s from the perspective of a customer or “user” of some material that was published by others. In this story, I am one of those customers.

Continue reading “After you publish, test and review”

Posted on

Train yourself in frustration, confusion, and inefficiency

For professional reasons, I like to mess around with software. It’s a form of training, because some of the messing around leads to frustration, confusion, and inefficiency. And that’s good.

My hope is that my experiences will help me to better understand what I put various groups of software users through when they use the software I helped design and build.

An easy way to mess around is by changing default settings. For example, my iTunes isn’t set to English. This helps me understand the experience of users who learned one language at home as children and now use another language at work as adults. It’s not just beneficial to experience the initial pain of memorising where to click (as I become a rote user in a GUI I cannot read), but also the additional moments of frustration when I must do something new—an occasional task whose command vector I haven’t memorised.

Relating to the language challenges that some users face

Another easy way to mess around is to switch between iMac and Windows computers. It’s not just the little differences, such as whether the Minimise/Maximise/Close buttons are on the left or right sides of the title bar, or whether that big key on the keyboard is labelled Enter or Return.

Switching between operating systemsIt’s also the experience of inefficiency. It’s knowing you could work faster, if only the tool weren’t in your way. This also applies to successive versions of “the same” operating sytem. This is the frustration of the transfer user.

It’s noticing how completely arbitrary many design standards are—how arbitrarily different between operating systems—such as the End key that either does or doesn’t move the insertion point to the end of the line.

Another easy way to mess around is to run applications in a browser that’s not supported. I do it for tasks that matter, such as making my travel bookings.

All this occasional messing around is about training myself. The experiences I get from this broaden the range of details I ask developers to think about as they convert designs into code and into pleasing, productive user experiences.

In a separate IxDA discussion thread, a few people reacted to this blog post:

  • Try a Dvorak keyboard instead of a Qwerty keyboard (Johnathan Berger).
  • Watch children’s first use of a design (Brandon E.B. Ward).
  • Use only the keyboard, not the mouse (CK Vijay Bhaskar).
  • Sit in at the Customer Support desk for a day (Adrian Howard).
  • Search Twitter to find out how people feel about a product (Paul Bryan).

See also the comment(s) below, directly in this blog.
Posted on

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:

Click to enlarge

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.

Posted on

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:

© Boxes and ArrowsThe 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?

Posted on

GUI: copy it or design it?

I’m a big believer in following the standards for GUI and interaction design. But when do you copy or reuse an existing design, and when do you design something new? Here’s my guideline for when to design and when to reuse or copy the GUI and interaction:

Reuse When… Design
…there is an external standard.
For example: the Vista UX Guide recommends […].		  
…there is a GUI or interaction precedent in your software.
For example: we distinguish between Import and Open.
   …the precedent uses an out-of-date interaction style.
For example: the users cannot drag an object to move it.
  …the precedent uses an incorrect mental model.
For example: user preferences are saved in a text file.
  …usability tests say the precedent reduces performance.
For example: 70% of occasional users do this wrong.
 …the developer wants to re-use existing GUI.
For example: use a variable to change the dialog-box title.
 …competitors have implemented the feature better.
For example: when they zoom in, it’s smooth, not stuttered.
 …the market has a certain GUI expectations.
For example: iPhone promoted gestures, others had to copy.
  …the product requires a certain strategic direction.
For example: all data must be sharable, locally and remotely.
  …there aren’t sufficient resources to design.
For example: “There’s no time in the schedule for design.”

Reuse your existing design ordesign it using Five Sketches™.
Copy the competitor’s design orleapfrog their design.
  If you ship a feature with poor interaction or poor usability, where’s the user value and where’s your credibility? Not all design processes are lengthy. Five Sketches™ takes about a day for most features that you’re tempted not to design.

Here’s an example: did Internet Explorer leapfrog Firefox?

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

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.