Tag: software design

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

Users are not used to it

For several years, I did usability testing on CAD-style software that was full of legacy code, some of which preceded Windows 98.

Some of that legacy code dealt with CAD objects that displayed on screen. To work with these objects, users had a choice of menu commands and toolbar buttons, supplemented by dialog boxes. For example, to move an object, users could not simply click and drag it; they would choose a command, click the object, and then, in a dialog box, enter the distance to move the object.

That’s the way CAD programs worked when that legacy code was originally written.

Over the years, during my usability testing of various features, I noticed a growing trend toward direct manipulation. That is, to work with an object, users would try to click it or drag it. They would do this without thinking. Even long-time users, faced with a new feature (studies from 2005-2006), would try direct manipulation first:

  • 100% of the test subjects clicked a cube, trying to select it.
  • 100% of the test subjects dragged a point or line, trying to move it.
  • 100% of the test subjects clicked in the window, trying to create a point.
  • 100% dragged across points, trying to select them.

But the new features were built on the legacy code, so had the command-driven interaction style. A simple click on the object was usually a dead end for users.

And the users would say: “Darn,” and then look for another vector—another pathway—to complete the task.

The reasons we didn’t provide direct manipulation:

  • “Our users are used to the way it is now.” Clearly, usability-test results negated that argument. Users are not so accustomed to old-style interaction, because their first instinct for new CAD tasks in an existing product was direct manipulation.
  • “There’s not enough bang for the buck” because the opportunity cost (the cost of skipping other possible projects) was deemed too great. It’s hard to argue with this, as a usability analyst. The company opted for more features, and may have increased its risk of being leapfrogged by the competition, as discussed in an earlier blog.
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

Functional sophistication, not complexity

Some software companies add ever more features to their software as a way to differentiate it from its competitors. Lucinio Santos’ lengthy analysis of sophistication versus complexity includes this graphic:

functional-sophistication-not-complexity

An excellent example of simplification is the Microsoft Office ribbon. Many users who upgrade dislike the ribbon for months because of the sheer amount of GUI change it imposes, but the ribbon successfully simplifies and makes existing features more discoverable.

Incidentally, the Office ribbon was designed by a design team using generative design. I facilitated a ribbon-design project that used a team of developers Five Sketches™—a method that incorporates a generative design.

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

Complicated GUI is fixable

According to usability guru Jakob Nielsen, the worst mistakes in GUI design are domain-specific. Usually, he says, applications fail because they:

  • solve the wrong problem.
  • have the wrong features for the right problem.
  • make the right features too complicated to understand.

Nielsen’s last point reminds me of what a product manager once told me: many users of highly specialised software think of themselves as experts, but only few are. His hypothesis? Elaborate sets of features are too numerous or complex to learn fully.

Cookie on a plateOne of my projects involved software for dieticians. The software allowed users to enter a recipe. The software would calculate the nutritive value per portion. Users learned the basic settings for an adequate result. They ignored the extra features that could take into consideration various complex chemical interactions between the recipe ingredients. The extra features—the visual and cognitive complexity—got ignored. Ironically, their very presence increased the likelihood that users would satisfice, or avoid the short-term pain of learning something new. When the product was developed, each extra bit seemed a good idea, and they may also each have helped sell the product. But, good idea or not, those extra features needed to be removed, or hidden from the majority of users, or redesigned.

Resolving the “extra features” problem
  1. If the extra features are superfluous, remove them. Usage data can help identify seldom-used features, and many of our products are capable of collecting usage data, though we currently only collect it after crashes and mainly during Beta testing. However, removing a seldom-used part of an existing feature is a complex decision, and one for the Product Manager to make. The difficulty lies in determining whether a feature would be used more if it were simpler to use. In that case, it may not be superfluous.
  2. If the extra features are used only occasionally by relatively few users, then hide them. The suggested GUI treatment for an occasional-by-few control is to expose it only in the context of a related task. Do not clutter the main application window, menu bar, or the main dialog boxes with controls for occasional-by-few tasks. Hiding the controls for an occasional-by-few task is supported by the Isaacs-Walendowski frequency-commonality grid:
    3.   If the
      feature is…    		 Used
    by many    		 Used
    by few
    Used
    frequently    		 GUI treatment:
    •  Visible.
    •  Few clicks.    		 GUI treatment:
    •  Suggested.
    •  Few clicks.
    Used
    occasionally    		 GUI treatment:
    •  Suggested.
    •  More clicks.    		 GUI treatment:
    •  Hidden.
    •  More clicks.
  3. If the extra feature is to be a core feature, simplify it. I’m talking about a feature that the Product Manager believes would be used frequently or by many if users could figure it out. Burying or hiding such features isn’t the answer. You need to find ways to reduce complexity by designing the interaction well and by organising the GUI well. For this, Five Sketches™ can help.
What are the requirements, really?

All this begs the question: who can tell us which features are the extra features (the features to omit), which ones are occasional-by-few (the features to hide), and which ones are used frequently or by many users (the features on which to focus your biggest design-guns)? Nielsen says “Base your decisions on user research” and then test the early designs with users. He adds:

People don’t want to hear me say that they need to test their UI. And they definitely don’t want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support. The general idea seems to be that real programmers can’t be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.  …More.

Conclusion: conduct user research and use what you learn to inform the design.

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

Amabile’s creativity myths

While developing Five Sketches™, I was asking questions about how best to support developers who also need to design. Where do good ideas come from? What environment lets creativity grow? And the big worry: is the Five-Sketches™ method enough to stimulate creativity and lower the barriers to creativity?

©2007 Fast CompanyHarvard Business School’s Teresa Amabile devotes her entire research program to the study of creativity and business innovation. Fast Company magazine (Dev 2007) reports that, by gathering and analysing 12,000 daily journal entries from 238 people working on creative business projects “in the wild,” Amabile and her team became academic myth busters who disproved these long-held beliefs about innovation in the workplace:

  1. Creativity comes from creative types. A myth!
  2. Money is a creativity motivator. Another myth!
  3. Time pressure fuels creativity. It’s a myth!
  4. Fear forces breakthroughs. Also a myth!
  5. Competition beats collaboration. Another myth!
  6. A streamlined organization is a creative organization. A myth!

I was especially pleased to read about the first of Amabile’s myths, because I’ve seen analytical and logical types produce inspired designs while engaging in a supportive, friendly, facilitated-design process.

Want to know more about these six myths? Read the Teresa Amabile interview in Fast Company magazine, online.