May 2009

Volume 24 Number 05

Usability in Practice - Useful, Usable and Desirable: Usability as a Core Development Competence

By Dr. Charles B. Kreitzberg, Ambrose Little | May 2009

Contents

THE COGNITIVE VIEW
Useful—The Foundation of User Satisfaction
Usable
Desirable
Usability is Much More than Skin Deep
Usability: Do it Early and Often
Wireframes
It Doesn't Slow You Down
Your Personal Journey
THE SOFTWARE VIEW
Useful
Desirable
What About Developers?

THE COGNITIVE VIEW

Dr. Charles B. Kreitzberg

Every now and then I need an "elevator speech" to explain why design matters. An elevator speech, in case you haven't come across the term, is an explanation that can be delivered in the time it takes to get from the lobby of an office building to the 10th floor. I usually tell people that as a user experience designer my job is to design interactive products that are useful, usable and desirable. The phrase useful, usable and desirable resonates with me because it captures the outcome we hope for with every development project.

Most every interactive product we develop—whether it's an application, a game, a Web site or a mobile device—is some form of tool.

And no tool can be successful without being useful. Creating useful products has been a fundamental goal of the development community from the beginning and a lot of good thinking has gone into figuring out how best to understand and document requirements. Getting the functionality right, however, is only part of what makes a tool useful.

Figure 1 The E3T Model

Useful—The Foundation of User Satisfaction

Recently I came across the phrase "usability exposes usefulness" and I thought it was an interesting comment. Finding functionality and being able to use it in the way you want requires a usable design. Obviously, the more usable a tool is, the better it works and the more useful it is. So if we want to build truly excellent products, they must be usable; you can't really make a truly useful tool if it's not really usable.

Desirability refers to a person's affective (emotional) feelings about a product. Many factors affect the desirability of a product. Four of the most useful are shown in a model I developed which I call the "E3T model." E3T refers to the four dimensions shown in Figure 1.

How important is desirability? It's obvious that products we develop for sale be highly desirable, to attract and retain users. But even within the business world, people are demanding more from software products, and they know good design when they see it. (Figure 2 explains the elements of the E3T model).

So if your goal is to create useful, usable and desirable products, you will need to integrate usability thinking into the development process. In another installment, we will talk about how to fit user experience design into an agile development process. In this article, I want to focus on creating a high-level design.

Usability is Much More than Skin Deep

Often developers think of usability as the product's skin. While some aspects of usability are related to the visual design, much of it is below the surface.

Fourteen years ago, in his book About Face, Alan Cooper made a distinction between two software models: the technical model and the manifest model through which the software "represents its functioning to the user." I prefer the term UI Model to Manifest Model, but whatever term you use, it's an important distinction.

While the technical model is built of such items as objects, methods, algorithms, and data structures, the UI model is built around tasks, people, and business objects. Obviously there needs to be alignment between the technical and UI models. Developers are, of course, most comfortable with the technical model and tend to focus on it. As a result, in most development environments, a formal UI model is never constructed. Instead, the developers agree on a basic framework and the UI is constructed in an ad hoc manner when the screens are coded.

Bringing user-centric design into the development process means that you (or someone on the team) will gather information about the users and produce a UI model of the product.

Usability: Do it Early and Often

Developing a high-level design early helps ensure that everyone working on the project shares a clear idea of what the end result should be.

I think about the UI design in two stages: a high-level conceptual design and a detailed design. This approach is analogous to the way that functional requirements are developed: first a high-level functional spec is created and then detailed (field-level) requirements are defined.

Breaking the design into high-level and detailed designs is particularly important in an agile environment where some details may not be defined until late in the development process. The high-level design serves as a framework that ensures consistency of the UI. The detailed design can then be spread across the iterations.

Wireframes

The high-level design is usually presented as wireframes and a style guide. Wireframes are drawings that show how screens would look and how the user would interact with them. A style guide is a document that provides the rules for constructing screens. It covers such issues as control placement, standards for labels, colors, and fonts. It should also provide rules for data display. The goal of a style guide is to ensure that all screens use consistent elements.

A variety of tools are used to create wireframes. A popular tool is Visio which produces mockups quickly. But Visio suffers from a number of limitations. It's a generalized drawing program rather than one designed to for creating screen mockups. And it has limited ability to apply behaviors to the screens which limits its ability to show interaction. Recently, more specialized products have emerged. Axure and iRise are two examples that offer more sophisticated screen layout capabilities.

But it seems to me that in a .NET environment, it makes sense to create wireframes in Visual Studio, using the same controls that will be used in the product. You can use master pages to create a consistent framework and build in limited functionality to show how interactions would work and end up with a UI prototype that looks and acts like the real thing.

It's important not to go too far with your prototypes. Like almost everything in UX design, wireframes are refined iteratively. At early stages they can be schematic and you can add detail as you learn more about the users and their requirements. Many developers tend to put too much sophistication into wireframe prototyping. Remember that in the early stages you are building a high-level design. You probably don't need a database, or data validation. The UI prototype is intended to create the illusion of a working product; it's not an early iteration of the actual code.

I call the UI prototype I create at this stage a key screen prototype because its purpose is to show the main (or key) screens, the navigational flow, and the information architecture.

There are three ways you can use the key screen prototype. A primary use is as a communications tool to make certain that everyone involved in the project is on the same page. Many problems that plague software projects have their origins in poor communication and misunderstandings between the development team and the business clients. Developers often overestimate their customers' ability to understand what they are agreeing to. The result is that problems are not discovered until late in the project when it's harder and more expensive to deal with them. If you can show a model of the product early in the development cycle you can clearly show stakeholders what the product will look like and how it will work.

When demonstrating wireframes to stakeholders in a review session, I find that it is best to show them in terms of task flows. Showing a screen and inviting the participants to criticize it tends to elicit a lot of off-the-cuff opinion which can be counterproductive. Instead, I demonstrate flow by showing how a user would perform major tasks. Later, I'll work one on one with trusted partners to discuss details.

It's important to decide how to handle the visual design. Some designers prefer to keep the wireframes schematic so that stakeholders don't respond to a visual design they dislike by criticizing other aspects of the design. In the early stages, I typically use schematic wireframes and create separate screens to display the visual design. However, once we agree on a visual design, I integrate it into the wireframes to make the UI prototype as realistic as possible.

A second use of the wireframes is to support usability testing. The goal is to make certain that that the UI is intuitive and makes sense to the users. While it is certainly possible to get useful information from a paper prototype or by displaying drawings on screen, I prefer to make the interaction as natural as possible—after all, that's what you are testing. It is useful to make menus, buttons, and links work so the user can browse from screen to screen. If controls link to screens not yet designed or that I cannot support (such as search results) I'll take the user to a placeholder screen. I design the sample content so it makes reasonable sense as the user goes from screen to screen but limit the work by not making it 100% realistic or consistent.

A third use of the wireframes is to provide a mock-up of the product to facilitate the creation of content such as sales and marketing collateral and user support content. The key screen prototype can help content authors get started earlier and make their jobs more efficient. Often my prototypes are taken to trade shows where they are shown to prospective customers to get their reactions.

The benefits of creating a wireframe UI prototype are so overwhelming that I cannot understand why it has not become a universal practice.

It Doesn't Slow You Down

It's common for developers to be concerned that the UX design processes will slow the project down. There is no question that if you start the UX design too late there is a high probability of conflict. It is far better to start the UX design process well before the technical design. Done this way, UX design will speed up the development project. Having a set of wireframes and customers who understand what they are getting can eliminate missteps and rework. If you are working in an agile environment, having a great set of wireframes for iteration zero will jumpstart the entire process. And the UX design is not extra work. You would still need to talk with users, develop screens and review them. UX design almost always brings the cost of projects down, sometimes a lot and it improves customer satisfaction a great deal.

Your Personal Journey

The decision to make user experience design a core competence is both an institutional and personal decision. Unless you are a sole practitioner, the company you work for needs to decide that useful, usable and desirable products are a goal worth striving for and it must reward the people who help achieve it so that the organizational culture begins to integrate UX design.

But there is also a personal journey you can take, as you become increasingly aware of UX. You may want to do UX design or you may ultimately prefer that others take on the task. What is important is that you understand how to recognize good design and are clear about the practices that produce it.

Here are a few ways you can increase your awareness and understanding of user experience engineering:

• Look for examples of poor usability in everyday life. Road signs and airports are rife with them. Instructions that make no sense, a latch you can't figure out how to undo, confusing menus on your cell phone are all everyday examples of poor usability. Once you start looking you will be amazed at how much you are inconvenienced by poor design and how much time and energy it wastes. As you identify usability problems think of solutions—how could the design be improved.
• Also look for examples of usability issues and improvements on the software tools you use every day.
• Watch non-technical people using computers or cell phones. Your relatives may offer a fertile population to observe. Don't just correct them or show them how to do something but try to understand their misconceptions. Again, think about how you could support them through better design.
• Observe interactive products like cell phones and websites, from a user perspective. Note the design problems and think about how to solve them.

Sadly, you will not have much problem finding design problems. They abound. But making the decision to understand usability and UX design in a deep way will make you a better developer and help you bring the products you create to the next level.

THE SOFTWARE VIEW

Ambrose Little

The truth is that we're nowhere near a place where we can have a UX designer on every software project. I mean, even if every team working on software were convinced of the importance of a focus on UX, there just aren't enough folks with that expertise and probably won't ever be. So we're left with the reality we have today—developers, developers, developers! And as a once-upon-a-time developer, I don't think that's a bad thing.

Developers are smart. We like to build good stuff, and by and large we're always learning and trying to improve ourselves and our trade. As I see it, a focus on UX, a focus on useful, usable, and desirable is part and parcel of our continued self-improvement. Charlie focused in on usability, so I won't belabor that too much myself. I'll just quote my boss, Dr. Komischke, who likes to quote the International Standards Organization (ISO) definition:

Usability is the "effectiveness, efficiency and satisfaction with which a specified set of users can achieve a specified set of tasks in a particular environment."

Actually, that's a pretty broad definition that seems to encompass what I think most people call "user experience" these days. I think there's a maturing in the UX community as well and plenty of discussions about what UX professionals do and what it should be called. So as the field matures, definitions get refined, and so today usability is more refined. I like the way Dr. Larry Constantine talks about it—designing for user performance.

The thing about usability is that it is focused on minimizing and eliminating barriers and errors that keep people from achieving what they need to achieve with software. The boon for us is that there is a lot of science in the discipline of usability, which is probably the most studied area of UX, thanks to the military, aviation, health care, and so forth where errors can mean life or death. There is a wealth of knowledge derived from these studies that can inform how we build software and the assessment techniques we use (such as usability testing, which we'll cover in July) to help us better ensure the usability of products we build.

Userful

Useful is an easy one because we already get it. It's about the functionality, but even so, there's more to making software useful than making it functional. Software could be completely functional, bug free, and designed to spec and yet totally not be useful to the people that it was made for. It's a change in thinking from requirements gathering and specification (and building to specifications) to understanding what the people who will be using the software want to achieve—what their goals are and how they go about achieving them.

I think this area is where there is most overlap between user-centered/UX approach to software and Agile. Agile recommends regular, iterative input from stakeholders. A UX approach may be more direct—you (ideally) have regular, iterative feedback from users. It helps keep you on the straight and narrow, but it goes farther than that. It urges you to do some more work up front to get a better understanding of the people and what they want to achieve. You can't just ask people what they need the software to do. You ask them what they do. You watch what they do (if you can). You try to understand their motivations--what makes them tick, what they like and don't like about what they do, and more. We call it user research, and there are techniques like user interviews, surveys, and ethnography, which is the science of observing people in their natural habitats, and taking the data collecting and condensing and refining into usable tools such as personas.

I think that this aspect and the body of knowledge and techniques that the UX profession brings to the table has more to add to improving software than it is given credit for. When most people think of UX, they tend to think of either usability or desirability. But if you get the usefulness wrong, the rest doesn't matter. It can be the most functional, the most usable, and the most aesthetically pleasing software ever built, but if it doesn't help people do what they want to do, it'll be nothing more than a splash in the pond. Putting the focus on what people want and need to accomplish and endeavoring to see how software fits in that puzzle will yield unexpected insights; it'll help ensure the software is useful, and it could even keep you from building software that isn't really needed.

Desirable

Ah, eye candy. As humans, we innately understand aesthetic appeal, and it certainly does sell well. It's kind of a no-brainer that you want to invest in this aspect of UX if you need to convince people to use your software. But what if you don't need to sell something? What if you have a captive audience or your software is mandated internally?

Well, in recent years the academics in the field of human-computer interaction have become more and more interested in aesthetics as a way to enhance both the usability and usefulness of software. I was at the 2008 annual meeting of the Human Factors and Ergonomics Society last September, and there were several papers presented around this topic. It's an early area of inquiry, but it makes sense.

There's another aspect of aesthetics that shouldn't be overlooked, even for internal software. Think about your own experiences. If something is aesthetically pleasing, it can make up for other deficiencies in that thing or even the overall experience of a company.

Further, if you actually enjoy using a piece of software, you're less reluctant to use it—you won't try to work around it like so many people do with poorly designed software that they are required to use. It contributes to job satisfaction and, ergo, employee retention. So even for internal software, there are good reasons to focus on aesthetics.

And it's worth noting that there's more to desirability than just aesthetics. The desirability of software is intertwined in usability and usefulness, and aesthetics applied to software at its best will only enhance those aspects of software to increase the overall desirability.

Stay tuned, because we're looking to dive into more on aesthetics late this year.

What About Developers?

So what does all this mean for developers? Essentially, I think it means that developers can and should embrace and learn about UX, about usability, usefulness, and desirability, just as much as they embrace Agile, Domain-driven design, test-driven development, and other approaches and techniques that enhance their overall effectiveness. Incorporating best practices from UX development will only help to make you more effective in building software, regardless of your environment. Usability matters to software developers. That's why we're here each month.

Send your questions and comments for Charlie and Ambrose to magux@microsoft.com.

Dr. Charles Kreitzberg is CEO of Cognetics Corporation (www.cognetics.com), which offers usability consulting and user experience design services. His passion is creating intuitive interfaces that engage and delight users while supporting the product's business goals. Charles lives in Central New Jersey where he moonlights as a performing musician.

Ambrose Little lives with his wife and four children in central New Jersey. He's been designing and developing software for more than 10 years and is honored to be an INETA speaker and Microsoft MVP. Lately, he's shifted from technical design to designing for people and is now a user experience designer for Infragistics.