What is Usability

1 Usability definition:
As defined in ISO 9241-11 1 The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use

2 Parameters of usability
1. Effectiveness : Task Completion
2. Efficiency : Lesser time / clicks
3. Satisfaction : Pleasurable activity

3 Benefits of Usability
Benefits to Users User satisfaction à User Delight More ease of use Efficiency increases Shorter learning cycle User perceived quality improved Benefits to Developers User oriented thinking = Reduction in rework Designing for the users and not (only) Clients Benefits to business Product quality improvement More value delivered à Priced higher Increased Profitability 4 Why Usability is important Other sources report : “There are about 43 million Web sites, and no one knows which ones are usable. The best sites we’ve found are usable only 42 percent of the time, and none that we have studied are usable a majority of the time ….” Forrester Research : Losing approximately 50% of the potential sales from a site as people can’t find what they need Losing repeat visits from 40% of the users who do not return to a site when their first visit resulted in a negative experience Jacob Nielsen : “Studies of user behavior on the Web find a low tolerance for difficult designs or slow sites. People don’t want to wait. And they don’t want to learn how to use a home page. There’s no such thing as a training class or a manual for a Web site. People have to be able to grasp the functioning of the site immediately after scanning the home page — for a few seconds at most.”

5 Usability Engineering Goals
1. Compatibility (with the user) – Computer speaking my language
2. Learn ability – I can do that.
3. User friendliness – Easily
4. Effectiveness A – Accomplish user goals.
5. Effectiveness B – Business goals fulfilled.
6. Efficiency – faster.
7. User Satisfaction – Alright ! it was smooth !
8. User Delight – Wow I did not expect this.
9. Flexibility – good ! You could do it this way also, (Ctrl C Ctrl V)
10. Excellent User Experience.

6 Usability Engineering Definition An Evidence based methodology that involves end users throughout the development process to product information systems that are measurably easier to use, learn and remember. — By Jean Fox, Janice R. Nall.

7 Understand the users
1. Who are the users of this specific product?
2. What are their User specific & Use specific needs?
3. What are the users goals for using this product?
4. Which areas are critical for meeting the user goals efficiently?
5. What other products they have used?
6. What is the terminology they use?

8 Model of stages of use Model for Stages of Use (for a particular application)
1. Novice
2. Advanced Beginner
3. Competent Performer
4. Expert “User and Task Analysis for Interface Design” by Joann T. Hackos, Janice C. Redish

9 GUI Design Process
1. Understand the Users
2. User goals, Business goals
3. User specific and use specific tasks
4. Define features
5. Design the work flow
6. Design the information structure
7. Design the front end

10 Usability Methods
1. Card Sorting Technique that allows users to group the information on your Web site and helps to ensure that the site structure matches the way users think.
2. Contextual Interviews Method that enables you to observe users in their natural environment to better understand the way users work.
3. Focus Groups Moderated discussion with a group of users that allows you to learn about users’ attitudes, ideas, and desires.
4. Heuristic Evaluation Usability inspection method where a group of usability experts evaluate the Web site against a list of established heuristics (or guidelines).
5. Individual Interviews One-on-one discussions with users that allow you to learn how a particular user works and enables you to probe on a user’s attitudes, desires and experiences.
6. Parallel Design Technique where multiple designers create mock-ups of the user interface and the best aspects of each design are used in the final design.
7. Personas A fictional person that represents one of the major user groups for the site. The design team considers the needs of this fictional person when developing the site.
8. Prototyping Draft model (or mock-up) of the Web site that allows the design team to explore ideas before fully implementing them. A prototype can range from a paper mock-up to interactive html pages.
9. Surveys (Online) Series of questions asked to multiple users of the Web site that helps you learn about the people who visit your site.
10. Task Analysis Method that involves learning about users’ goals – what they want to do on your Web site – and understanding the tasks that users will perform on your site.
11. Usability Testing One-on-one sessions where a “real-life” user performs tasks on the Web site in order to identify user frustrations and problems with the site.
12 Use Cases Description of how users will use a particular feature of the Web site. Use cases provide a very detailed look at how users interact with the site including the steps a user will take to accomplish each task. 13 Writing for the Web Guidelines for optimizing content on the Web based on the way users read online. Involves chunking content, using bulleted lists, and putting the most important information at the top of the page.

11 Heuristic guidelines for usability testing
1) System Status shown (Keep the user informed about what the computer is doing) Providing feedback to the users Appropriate method of feedback to be used
2) Match with the real World Use simple and natural dialog. Tell only what is necessary, and tell it in a natural and logical order. Ask only what the user can answer. Speak Users language Use metaphors familiar to users Use words and concepts familiar in their work. No computer jargon.
3) User has to feel he is in command Provide clearly marked exits so users can escape from unintended situations User should be able to leave an unwanted state Users should not get locked in the system
4) Consistency in terminology and required actions. Consistency in communication Names, Images Use sequence, Use of Controls Behavior of controls
5) Error prevention Prevent errors from occurring by keeping choices and actions simple UI should prevent an error from occurring Minimize error situations
6) Error Recovery Give good, clear, specific and constructive error messages in plain text, no beeps and codes Error messages should Clearly indicate the problem Constructively help users solve the problem Be polite and express in plain simple language
7) Recognition not recall Minimize the user’s memory load Objects and screens should be Easily visible Easy to interpret User should not be forced to remember any information
Flexibility Provide shortcuts for frequent actions and advanced users Provide multiple ways to accomplish the same task If possible provide freedom to customize the system
9) Minimalist Design “Less is More” Offer only relevant information and functions Make invisible all the irrelevant information & functions Seek minimum inputs from the users
10) Help and Documentation (Provide clear and concise, online help, instructions and documentation. Orient them to the users task) Anticipate where users will require help Provide appropriate help

original posted on http://www.strangesystems.net

Wireframes serve a central function in the development of a web site. It is a key tool in communicating the content and layout of each web page for internal and client reviews as well serving as a blueprint for graphic designers to produce designs and for programmers develop functionality.

What are wireframes?

A wireframe is a stripped-down visual representation of a single web page, devoid of any graphic treatment. As the name suggests, it is a framework made with wires, which define basic layout and placement of content and page elements such as navigation; header & footer; branding etc.

They are sometimes referred to as “page schematics”, “page architecture” or even “blueprints” (though the term “blueprint” sometimes refers to a more overall site design).

It is sometime helpful to use the architectural blueprint metaphor in understanding wireframes. Architectural blueprints show you the form of the building, define the functionality of the spaces and paths for circulation, while provide the contractor and interior designer specifications from which to build from. Likewise wireframes define areas of content and functionality, navigation strategy while providing a framework from which the programmer and graphic designer can build from.

A full wireframe needs to deliver the following information:

• Layout: General placement of page elements such as headers, footers, navigation, content area, and often branding; It communicates decisions that as been made as to the navigation strategy of the site; it also shows the prioritization of the content on the page.

• Content inventory: What content needs to be present on the page

• Web elements: Headers, links, forms, lists, images etc.

• Behavior: Notes/annotations may be added as to how elements should be displayed (such as number of elements, default display etc.), or what functional behavior occur when an element is activated (popups, page refresh, link to another page, or external site etc.)

When are wireframes created?

Wireframes as deliverables are developed as a part of Information Architecture phase. It usually follows the “Business Requirements” phase of the project and precedes any graphic design and technical development.

Usually this is the role of the information architect. On smaller projects, this often become the role of the project manager.

Who is it for?

The following table shows the consumers of wireframes and how they are used.

A blueprint with which they can review whether the design meets their needs; a preview to the actual site design; Key deliverable, the signoff of which kicks of design and development phases of the project

Types of wireframes

• Content-only wireframes (aka Powerpoint wireframes): Powerpoint is used to define the key pages of the site. Name of the page, and a list of content items are captured on each page without information about layout or placement. This technique can be used to quickly capture client requirements and sketch out a site without having to go through the labor intensive work or creating detailed wireframes. Tools: Powerpoint

• Block diagram wireframes: This type of wirefames is one step higher than the Content-only wireframes in that it offers basic layout information through blocks of functionality, and content grouping. These wireframes can be used in conjunction with detailed wireframes to provide a high level strategic overview to the wireframes before diving into the details. Tools: Powerpoint, Visio

• Detailed wireframes: Fully-loaded wireframes with layout, content, web elements information along with notes and annotations on page behavior. Tools: Visio, OmniGraffle

Developing wireframes

Here are some basic steps an information architect would take when developing wireframes.

Gathering information

• Business requirements: Ideally you would already have documentation from the the Business Requirements phase. This document will spell out major site functionality, key site pages and what content/functionality would need to be presented on them.

• Content requirements: If there is no documentation from a previous phase it is important to meet with client and sketch out what needs to be presented on key pages of the site. A content-only wireframe is a good tool to do this.

• Existing design requirements: Additional information such as need to integrate with existing site guidelines or need for consistency with previous site design, etc. should also be noted.

• Bandwidth requirements Some clients may have to serve a low-bandwidth user base in which case, the design will have to be more text-reliant and less image heavy.

• Software requirements Some sites are CMS-driven or software driven (such as blogs). Many software packages have layout and navigation rules the design will have to conform to.

Prioritizing/grouping information

• Once the information has been gathered, it is important to first group and then prioritize how they need to be displayed on the page.

Navigation strategy

• Clients may have strong preferences as to how navigation should work and be placed on the page. If there is no strong preference, software requirements and usability should dictate how navigation should be configured.

Drawing wireframes

Wireframes should include:

• Key page elements & location: header, footer, navigation, content objects, branding elements

• Grouping: side bar, navigation bar, content area, etc.

• Labeling: page title, navigation links, headings to content objects

• Place holders: dummy text (lorem ipsum dolor…), and image place holders

The question often arises: how many wireframes should I create? The answer is how ever many you need to get the job done. (or in our case how ever many we said we will create). Having said this the follow should be included in any good set of wireframes:

Required:

• Homepage

• Major sub-pages and “portal” pages

• Key template pages

• Pages with forms

Optional:

• Search results page

• 404 Error pages

• Any other pages that provide clarification to the overall development process

A User Interface Management System (UIMS) is a mechanism for cleanly separating process or business logic from Graphical user interface (GUI) code in a computer program. UIMS are designed to support N-tier architectures by strictly defining and enforcing the boundary between the business logic and the GUI. A fairly rigid Software architecture is nearly always implied by the UIMS, and most often only one paradigm of separation is supported in a single UIMS. A UIMS may also have libraries and systems such as graphical tools for the creation of user interface resources or data stores.

Generally, you cannot easily use multiple UIMS systems at the same time, so choosing the correct model for your UIMS is a critical design decision in any project. The choice of system is dependent upon the system(s) you wish to create user interfaces for, and the general style of your application. For example, if you want to create a web based front end, or just a standalone application or both that would be an important factor in choosing. If you want to deploy to the Macintosh, Windows and Linux, that would further influence your choice of a UIMS system.

The event, “Google Presents User Experience & Mobile Apps, Google user experience designer Leland Rechis started his talk by re-iterating Google’s mission: Organize the world’s information and make it universally accessible and useful. Rechis added that mobility is fast-becoming the key to making information “universally accessible,” but he warned that without a solid user experience, there is no way mobile applications can be useful.

Rechis said that when Google plans to launch a mobile application, it looks at the potential app through six layers:

1. Understanding users, anywhere, anytime

2. Fits in your pocket

3. More personal than the PC

4. Consistency across modes

5. Localization is intensified

6. Integrated devices, modes, products

Rechis then broke out the company’s mobile development and optimization strategy by each level.

Understanding users, anywhere, anytime

Rechis said that Google breaks down mobile users into three behavior groups:

A. “Repetitive now”
B. “Bored now”
C. “Urgent now”

The “repetitive now” user is someone checking for the same piece of information over and over again, like checking the same stock quotes or weather. Google uses cookies to help cater to mobile users who check and recheck the same data points.

The “bored now” are users who have time on their hands. People on trains or waiting in airports or sitting in cafes. Mobile users in this behavior group look a lot more like casual Web surfers, but mobile phones don’t offer the robust user input of a desktop, so the applications have to be tailored.

The “urgent now” is a request to find something specific fast, like the location of a bakery or directions to the airport. Since a lot of these questions are location-aware, Google tries to build location into the mobile versions of these queries.

Fits in your pocket

Rechis stressed the limitations of mobile phones. He pointed out that any mobile application has to be able to fit on a small screen and cannot require complicated text input. Also, since the third screen has no X-axis, layout has to clean, simple, but maintain the basic usability of the parent desktop application. Rechis also stressed that the “density of information” changes on a mobile phone, requiring designers to identify only the most essential parts of any given application. Obviously, juggling all this isn’t easy.

In order to achieve usable mobile applications, Fechis reminded the audience that they have to be willing to test and re-test applications with users. Otherwise you can’t get it right.

Also, building successful mobile apps requires developers and user experience people who are passionate about their subjects. He pointed out one Google employee who went to great pains to make sure that Google Maps gave directions correctly for Japan. Since street signs and markers in Japan are different than in the West, this employee had to go to great lengths to make sure that the app rendered maps and gave directions in ways that are useful for that country.

Consistency

Google always strives to keep the look and feel of any Google application consistent, both within the type of function (i.e. all blog search results look different than map search results) and on devices (a map search on a desktop looks and feels like a map search on a mobile phone and vice versa). If mobile applications are to be universal, then developers have to maintain patterns and designs across all screens.

What is Strategy

Before we define User Experience Strategy, lets define Strategy. Answers.com says
“Management plan or method for completing objectives; plan of procedures to be implemented, to do something.”

That’s a bit vague, so lets try to get some handle here. Strategy is the path between Vision and executing vision or in other words a vehicle to realize vision. hmm so it’s not just a tool but has great importance. It’s a 3 step dance:

Vision > Execution Strategy > Execution

Many organizations tend to go directly from vision to execution, missing this important step in between, perhaps most important one as it is allows for energies and resources to be canalized in the right direction.

Vision

For this article I’ll equate Vision to goals even though that’s not entirely correct. But you’ll see why I am doing this.
Goals that an organization has are more or less a variation of:

• Increase Revenues
• Reduce Costs
• Increase Profits
• Increase customer base
• Improve brand image

You need to figure out what variation of which goal do you want focus on in the solution you are building.

Strategy

So now that some context is set for what strategy is and role it plays, Lets dig deeper into it. Strategy can apply to anything with a vision from building a house to marketing a product to anything. So there can be :

• Marketing Strategy
• Brand Strategy
• Pricing Strategy
• Product Strategy
• Experience Strategy
• Innovation Strategy
• Coding Strategy
• Combat Strategy

… this list can go on and on..

Important thing here is to understand that more than one kind of strategy can be applied to reach the goals.

Lets take an example – Microsoft v/s Apple – both would have had similar goals, but applied different kind of strategies, Needless to say but Microsoft focused a greater effort on marketing strategy and less on experience strategy, Apple was opposite.

Lets take another example – Google v/s Microsoft (can’t resist this one). If you look at it Google is NOT a search company, it’s brand stands for innovation , that’s the reason we just absorb “any” product they launch.. everyone has to have an account with new products from Google.

A non-tech example would be airlines – Jet blue had experience strategy, they had well developed systems (in non-technical sense) to ‘institutionalize’ ability to provide superior experience

So User Experience Strategy is one of the many that an organization can choose from. Each strategy has a cost and value that it delivers. Also strategy does is relative not absolute. It depends on time, market, and competition.

How to decide on the strategy? Here are some tips, (but this is a subject that deserves a separate article):

1. Vision: This of course is the starting point, strategy must align with vision.
2. Industry Direction: Take an example of Hotel industry, the base direction it is taking is experience strategy, which is good, but question to be asked is if you can differentiate yourself on same strategy or something else is needed. Consider Yahoo – it has opened yahoo products like a development platform, because even though industry is moving towards Innovation Strategy, they cannot generate enough innovation in house.
3. Socio-Economic Situation: Back in 1940-50s airline prices were regulated by government, given this airlines could only differentiate based on service and experience they provide. Once that regulation was removed, price wars started and strategy changed.
4. Competitive Landscape: This is very much of like Industry, however in case you have specific competitors you are going after, looking at Industry direction alone would not be enough, you competitor might be doing something that changes Industry direction
5. Your offerings: Last but not the least your capabilities. Sony is putting a great deal of resources on Blue Ray disc (one of the two HD DVD Formats being released). This has resulted in them selling new Playstation boxes at a loss because Blue Ray drives are being shipped in new PS and have added significantly to costs. But with competition from X-Box they cannot increase prices. So look at where is the strength in our offering and adopt the right kind of strategy.

User Experience

Okay, let me take a parallel road and look at User Experience at very high level, and then we’ll converge it with Strategy discussion.

So what is User Experience? Answers.com does not even tries to answer this, so lets take it from Wikipedia:

“User experience is a term used to describe the overall experience and satisfaction a user has when using a product or system.” We should change ‘system’ to service.

In more materialistic terms I would say User Experience is essentially something that resides in User’s long-term memory and has a bearing on decision to transact with the company in future. This could be positive or negative.

You need to ask following questions, and these will map you to User’s experience life-cycle:

a. How do users come to know of their need?
b. How do they find the right product/service?
c. How do they make a decision on that product/service?
d. How do they order it?
e. How does it get delivered?
f. How does it get installed?
g. How are problems with product and service resolved?
h. How is it disposed?

Am sure some questions here are new and do not form a part of current experience design discussions, but all are important opportunities.

Now map your user’s path across these stages and rate your and competition’s performance at each stage. I like to follow a 5-point scale as it brings enough granularity, and at the same time has limited subjectivity. I do not recommend using 1 to 5 scale, instead use (-) 2 to (+) 2, i.e. –2, -1, 0, +1, +2

-2 Significant problems with experience
-1 Mild problems with experience
0 As expected
+1 Mild improvements to expected experience
+2 Significant improvements to expected experience

So now you have some assessment of User Experience at high level

Bringing the two together

So now you know which places the experience fails. Next Step is to “Identify Critical moments”. These are moments where users decide to move to next step or not. For e.g. lets say you are doing this for Parking Garage and experience of finding the garage was significantly negative, but once they find the garage they might go ahead if other parameters are fine. But if at this stage attendant’s approach is not right and if customer place high value on attendant’s attitude making it “critical” for customer, she might decide to look further.

So identify such critical moments and those are where you start to focus on. With this you have now narrowed on 2-3 such critical points and start to go deeper.

How do you find what’s critical and what’s not – User Observations are the most reliable method. Go in the field see what goes on and you’ll know what’s important what’s not. In addition talk to people. Do this for your product/service as well as competition product/service

A general principle for all user interface design is to go through all of your design elements and remove them one at a time. If the design works as well without a certain design element, kill it.   — Jakob Nielsen, author and consultant on user interfaces

A good website should have at least the usability and usefulness of a good book. But, although rarely fully exploited, it has the potential to be far more usable, largely because of the availability of hyperlinking.   — a Bellevue Linux Users Group member, August 2005

A well-designed and humane interface does not need to be split into beginner and expert subsystems.   — Jef Raskin, human-computer interface expert and a designer of the first Macintosh

Computer science departments have always considered ‘user interface’ research to be sissy work.   — Nicholas Negroponte, founder and director of the Massachusetts Institute of Technology’s Media Laboratory

Computing has gone from something tiny and specialized to something that affects every walk of life. It doesn’t make sense anymore to think of it as just one discipline. I expect to see separate departments of user interface, for example, to start emerging at universities.   — Nathan Myhrvold, former Microsoft executive

Don’t make me think.   — Steve Krug, usability expert

If the user can’t use it, it doesn’t work.   — Susan Dray, usability consultant

Most websites today fail basic tests of usability.   — Forrester Research

No matter how good your backend systems are, the users will only remember your front end. Fail there and you will fail, period.   — Tristan Louis, writer about the Internet

The Interface is the system.   — unknown

The only ‘intuitive’ interface is the nipple. After that, it’s all learned.   — unknown (but often attributed to a Bruce Ediger)

Usability cost-benefit data shows that including usability in product development actually cuts the time to market and increases sales because usability and ease of use build quality into products and catch many expensive problems early on in the cycle when they can be addressed at lower cost. Finally, working with users from the beginning of a product cycle ensures that the product is being designed so that users will be satisfied.   — Claire Marie Karat, human-computer interface researcher at IBM

Usability is critical for any application, but for mass-market software, usability spells success or failure more clearly than any other feature.   — Jerrold Grochow, Chief Technology Officer, American Management Systems

Usability really just means making sure that something works well: that a person of average (or even below average) ability and experience can use the thing – whether it’s a web site, remote control, or revolving door – for its intended purpose without getting hopelessly frustrated.   — Steve Krug

Usability rules the Web. Simply stated, if the customer can’t find a product, then he or she will not buy it.   — Jakob Nielsen

User interfaces have to do with people, and computer scientists don’t like to work on problems involving people. The classic work on user interfaces that sets the current paradigm was invented outside of universities in industrial research laboratories and government-funded institutes.   — Stuart Card, interface researcher at Xerox PARC

… when folks read news online, their eyes go for text first, particularly captions and summaries, and graphics only later.   — Bryan & Jeff Eisenberg, usability consultants and authors

 A prototype is a model of something to be further developed. The higher the fidelity the more representative is the prototype. Rapid prototyping implies that there is a short time between conceiving an initial notion and modeling it in physical form and between successive iterations. A popular method is to use paper to create the prototype (Snyder 2003) which can be done without programming skills and which has the look of work in progress thus encouraging users to comment on it. Software prototypes can then be developed when the ideas have been thought through and tested on paper. These can then be used for usability testing.

The reasons of Rapid Prototyping are

• To increase effective communication.

• To decrease development time.

• To decrease costly mistakes.

• To minimize sustaining engineering changes

• To extend product lifetime by adding necessary features and eliminating redundant features early in the design.

Appropriate Uses

Costs and Scalability

Paper prototyping can be carried out by human factors or usability specialists with the support of domain experts and users. No special equipment is required.

Software prototyping also requires someone with knowledge of the prototyping tool being used.

Interaction design is the branch of user experience design that illuminates the relationship between people and the interactive products they use. While interaction design has a firm foundation in the theory, practice, and methodology of traditional user interface design, its focus is on defining the complex dialogues that occur between people and interactive devices of many types—from computers to mobile communications devices to appliances.

Summary:

Application usability is enhanced when users know how to operate the UI
and it guides them through the workflow. Violating common guidelines
prevents both.

It’s hard to write a general article about application design mistakes because the very worst mistakes are domain-specific and idiosyncratic. Usually, applications fail because they (a) solve the wrong problem, (b) have the wrong features for the right problem, or (c) make the right features too complicated for users to understand.

Any of these three mistakes will doom your app, and yet I still can’t
tell you what to do. What’s the right problem? What are the right
features? What complicating curlicues can safely be cut from those
features? For each domain and user category, these questions have
specific and very different answers.

The only generalizable advice is this: rather than rely on your own best guesses, base your decisions on user research:

• Conduct field studies and task analysis before deciding what your app should do.
• Paper prototype
  your initial ideas before doing any detailed design — and definitely
  before wasting resources implementing something you’d have to change as
  soon as you get user feedback.
• Design iteratively, conducting many rounds of quick user testing as you refine your features.

Of course, 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.

(Whatever you do, at least promise me this: Don’t just
implement feature requests from “user representatives” or “business
analysts.” The most common way to get usability wrong is to listen to what users say rather than actually watching what they do. Requirement specifications are always wrong. You must prototype the requirements quickly and show users something concrete to find out what they really need.)

All that said, there are still plenty of general guidelines for
application UIs — so many, in fact, that we have a hard time cramming
the most important into our two-day course.
Here’s my list of 10 usability violations that are both particularly
egregious and often seen in a wide variety of applications.

1. Non-Standard GUI Controls

Basic GUI widgets — command links and buttons, radio buttons and checkboxes, scrollbars, close boxes, and so on — are the lexical units that form dialog design’s vocabulary.
If you change the appearance or behavior of these units, it’s like
suddenly injecting foreign words into a natural-language communication.
Det vil gøre læserne forvirrede (or, to revert to English: Doing so will confuse readers).

For some reason, homemade design’s most common victims are scrollbars. For years, we’ve encountered non-standard scrollbars in our studies, and they almost always cause users to overlook some of their options. We’re seeing this again this year, in the studies we’re conducting to update our course on Fundamental Guidelines for Web Usability. (The linked article includes screenshots of offending scroll controls.)

Some of the world’s best interaction designers have refined the
standard look-and-feel of GUI controls over 30 years, supported by
thousands of user-testing hours. It’s unlikely that you’ll invent a
better button over the weekend.

But even if your homemade design, seen in isolation, were hypothetically better than the standard, it’s never seen in isolation in the real world. Your dialog controls will be used by people with years of experience operating standard GUIs.

If Jakob’s Law is “users spend most of their time on other websites,” then Jakob’s Second Law
is even more critical: “Users have several thousand times more
experience with standard GUI controls than with any individual new
design.”

Users will most likely fail if you deviate from expectations on
something as basic as the controls to operate a UI. And, even if they
don’t fail, they’ll expend substantial brainpower trying to operate
something that shouldn’t require a second thought. Users’ cognitive
resources are better spent understanding how your application’s
features can help them achieve their goals.

1.a. Looking Like a GUI Control Without Being One

The
opposite problem — having something that looks like a GUI control when
it isn’t one — can reduce usability even more. We often see text and
headlines that look like links (by being colored or underlined,
for example) but aren’t clickable. When users click these look-alikes
and nothing happens, they think the site is broken. (So please comply
with guidelines for visualizing links.)

A similar problem occurs when something looks like a button but doesn’t initiate an action, or looks like a radio button but isn’t a choice. We found an example of this in our current round of studies.

To design a custom-tailored shirt on Liste Rouge Paris, you must
provide your measurements. As the following screenshot shows, there are
two different paths through the application here, depending on whether
your measurements are already on file with the tailor.

Our test user clicked incessantly on the New Customer
button to indicate that he was indeed a new customer. Unfortunately,
this screen element was not a button at all, but rather a non-clickable
heading.

He was the only user to test this site because he encountered
it during a task in which users could choose a site to visit (usually
from a search listing). In this case, the user eventually overcame the
confusion and proceeded to enter his measurements. If we had tested
more users, a small percentage would have likely failed at this point.
Each small error in dialog design reduces usage only by a small amount,
but most UIs contain bundles of errors, and the number of lost customers adds up.

As an aside, this screen also uses radio buttons incorrectly. In
theory, all five choices are mutually exclusive, which does call for
radio buttons. But in the user’s mental model of the workflow, there
are actually two issues
here: (a) new vs. old customers, and (b) how to provide the
measurements for your situation. You should use a single set of radio
buttons only when users will choose between options for a single issue.

So, in the case above, a better design would first ask users to
decide the new/existing customer question, and then reveal the relevant
radio buttons for the option they choose.

2. Inconsistency

Non-standard GUI controls are a special case of the general problem of inconsistent design.

Confusion results when applications use different words or commands
for the same thing, or when they use the same word for multiple
concepts in different parts of the application. Similarly, users are
confused when things move around, violating display inertia.

Using the same name for the same thing in the same place makes things easy.

Remember the double-D rule: differences are difficult.

Another example from our current study: Expedia pops up a two-month
calendar view when users specify the departure or return date for a
trip. The composite screenshot below was taken in February and shows
what happens when you want to book a trip that starts on March 10 and
ends on March 15.

In the second pop-up, the month of March has moved to the left,
leaving room for April to appear on the right. This may seem like a
convenient shortcut, since there’s no way the user would want a
February return date when traveling out in March.

In reality, however, the user is looking for March 15 in the
same spot where it appeared in the first pop-up calendar: in the
right-most column.

In our testing, the inconsistent placement of the months in the
second pop-up caused confusion and delays, but users ultimately figured
it out. We tested only a few users with this site, but if you observe
this kind of almost-miss error in user testing, it’s usually a sign that a few users will make the mistake for real during actual use.

Booking the wrong return date can have disastrous consequences —
customers could arrive at the airport without a ticket for their
expected flight. If a site has good confirmation emails,
users might discover the problem before departure, but even that will
cause aggravation and expensive customer support calls to resolve the
situation.

Even if people eventually use the calendar correctly, it takes more time to ponder the inconsistent design than the time users save by not having to click the next-month button for April departures.

The shortcut that moves the months around saves time only for
very frequent users who learn how to efficiently operate this part of
the UI. So, an application for professional travel agents should
probably use Expedia’s calendar design. A site targeting average
consumers should not.

3. No Perceived Affordance

“Affordance” means what you can do to an object. For example, a
checkbox affords turning on and off, and a slider affords moving up or
down. “Perceived affordances” are actions you understand just by looking
at the object, before you start using it (or feeling it, if it’s a
physical device rather than an on-screen UI element). All of this is
discussed in Don Norman’s book The Design of Everyday Things

.

Perceived affordances are especially important in UI design,
because all screen pixels afford clicking — even though nothing usually
happens if you click. There are so many visible things on a computer
screen that users don’t have time for a mine sweeping game, clicking around hoping to find something actionable. (Exception: small children sometimes like to explore screens by clicking around.)

Drag-and-drop designs are often the worst offenders
when it’s not apparent that something can be dragged or where something
can be dropped. (Or what will happen if you do drag or drop.) In
contrast, simple checkboxes and command buttons usually make it
painfully obvious what you can click.

Common symptoms of the lack of perceived affordances are:

• Users say, “What do I do here?”
• Users don’t go near a feature that would help them.
• A profusion of screen text tries to overcome these two
  problems. (Even worse are verbose, multi-stage instructions that
  disappear after you perform the first of several actions.)

When I tested some of the first Macintosh applications in
the mid-1980s, users were often stumped by the empty screen that
appeared when they launched, say, MacWrite. What do I do here,
indeed. The first step was supposed to be to create a new document, but
that command was not shown anywhere in the otherwise highly visible
Macintosh UI unless you happened to pull down the File menu.
Later application releases opened up with a blank document on the
screen, complete with an inviting, blinking insertion point that
provided the perceived affordance for “start typing.”

3.a. Tiny Click Targets

An associated problem here is click
targets that are so small that users miss and click outside the active
area. Even if they originally perceived the associated affordance
correctly, users often change their mind and start believing that
something isn’t actionable because they think they clicked it and
nothing happened.

(Small click zones are a particular problem for old users and users with motor skill disabilities.)

4. No Feedback

One of the most basic guidelines for improving a dialog’s usability is to provide feedback:

• Show users the system’s current state.
• Tell users how their commands have been interpreted.
• Tell users what’s happening.

Sites that keep quiet leave users guessing. Often, they guess wrong.

(For an example of the problems with poor feedback, see the screenshot of VW’s car configurator toward the bottom of my recent article reporting on our current round of testing: Because users couldn’t tell which tire was selected, they had trouble designing their preferred car.)

4.a. Out to Lunch Without a Progress Indicator

A variant on
lack of feedback is when a system fails to notify users that it’s
taking a long time to complete an action. Users often think that the
application is broken, or they start clicking on new actions.

If you can’t meet the recommended response time limits, say so, and keep users informed about what’s going on:

• If a command takes more than 1 second, show the “busy” cursor. This tells users to hold their horses and not click on anything else until the normal cursor returns.
• If a command takes more than 10 seconds, put up an explicit progress bar, preferably as a percent-done indicator (unless you truly can’t predict how much work is left until the operation is done).

5. Bad Error Messages

Error messages are a special form of feedback: they tell users that something has gone wrong. We’ve known the guidelines for error messages for almost 30 years, and yet many applications still violate them.

The most common guideline violation is when an error message simply says something is wrong, without explaining why and how the user can fix the problem. Such messages leave users stranded.

Informative error messages not only help users fix their current problems, they can also serve as a teachable moment.
Typically, users won’t invest time in reading and learning about
features, but they will spend the time to understand an error situation
if you explain it clearly, because they want to overcome the error.

On the Web, there’s a second common problem with error
messages: people overlook them on most Web pages because they’re buried
in masses of junk. Obviously, having simpler pages is one way to
alleviate this problem, but it’s also necessary to make error messages more prominent in Web-based UIs.

6. Asking for the Same Info Twice

Users shouldn’t have to enter the same information more than once.
After all, computers are pretty good at remembering data. The only
reason users have to repeat themselves is because programmers get lazy
and don’t transfer the answers from one part of the app to another.

7. No Default Values

Defaults help users in many ways. Most importantly, defaults can:

• speed up the interaction by freeing users from having to specify a value if the default is acceptable;
• teach, by example, the type of answer that is appropriate for the question; and
• direct novice users toward a safe or common outcome, by letting them accept the default if they don’t know what else to do.

Because I used Liste Rouge Paris as a bad example under
Mistake #1a, I thought I’d play nice and use them as a good example
here. The tailor offers 15 different collar styles (among many other
options) for people ordering custom-designed shirts. Luckily, they also
provide good defaults for each of the many choices. In testing, this
proved helpful to our first-time user, because the defaults steered him
toward the most common or appropriate options when he didn’t have a
particular preference.

Dialog to specify your shirt’s collar on www.listerouge-paris.com (3 of 15 styles shown).

8. Dumping Users into the App

Most Web-based applications are ephemeral applications
that users encounter as a by-product of their surfing. Even if users
deliberately seek out a new app, they often approach it without a conceptual model
of how it works. People don’t know the workflow or the steps, they
don’t know the expected outcome, and they don’t know the basic concepts
that they’ll be manipulating.

For traditional applications, this is less of a problem. Even if
someone has never used PowerPoint, they’ve probably seen a slide
presentation. Thus, a new PowerPoint user will typically have at least
a bare-bones understanding of the application before double-clicking
the icon for the first time.

For mission-critical applications, you can often assume that
most users have tried the app many times before. You can also often
assume that new users will get some training before seeing the UI on
their own. At the minimum, they’ll usually have nearby colleagues who
can give them a few pointers on the basics. And a good boss will give
new hires some background info as to why they’re being asked to use the application and what they’re supposed to accomplish with it.

Sadly, none of these aides to understanding apply for most Web-based applications. They don’t even apply for many ephemeral intranet applications.

Usability suffers when users are dumped directly into an application’s
guts without any set-up to give them an idea of what’s going to happen.
Unfortunately, most users won’t read
a lot of upfront instructions, so you might have to offer them in a
short bulleted list or through a single image that lets them grok the
application’s main point in one view.

As an example, our test user who was trying to order a
custom-tailored shirt was highly confused when the first screen in
Hamilton Shirts’ “Create Your Shirt” process displayed a fully designed
shirt with an “Add to Bag” button. This screen mixed two metaphors: a
configurator and an e-commerce product screen.

This is a case where a default value isn’t helpful: people who want
to design their own shirt are unlikely to want to buy a pre-designed
shirt on the first screen.

(This screen also suffers from Mistake #1: non-standard GUI
controls. In addition to its non-standard drop-down selection menus in
a tabbed dialog that doesn’t look enough like tabs,
the screen has a non-standard way of paging through additional fabric
swatches. Users are less likely to understand how to select fabrics
when the controls are presented in this manner.)

Our test user never understood the process of designing his own shirt on this site and ultimately took his business elsewhere.

9. Not Indicating How Info Will Be Used

The worst instance
of forcing users through a workflow without making the outcome clear is
worth singling out as a separate mistake: Asking users to enter
information without telling them what you’ll use it for.

A classic example is the “nickname” field in the registration
process for a bulletin board application. Many users don’t realize the
nickname will be used to identify them in their postings for the rest
of eternity — so they often enter something inappropriate.

As another example, we once tested an e-commerce site that
smacked users with a demand for their ZIP code before they could view
product pages. This was a big turn-off and many users left the site due
to privacy concerns. People hate snoopy sites. An alternative design
worked much better: It explained that the site needed to know the
user’s location so it could state shipping charges for the very heavy
products in question.

10. System-Centric Features

Too many applications expose
their dirty laundry, offering features that reflect the system’s
internal view of the data rather than users’ understanding of the
problem space.

In our current study, one user wanted to reallocate her retirement
savings among various investments offered by her company’s plan (for
example, to invest more in bonds and less in stocks). She thought she
did this correctly, but in fact she had changed only the allocation of future additions to her retirement account. Her existing investments remained unchanged.

As far as the mutual funds company is concerned, new investments and
current investments are treated differently. Reallocating future
additions means changing the funds they’ll buy when the employer
transfers money into the account. Reallocating current investments
means selling some of the holdings in existing mutual funds and using
the proceeds to buy into other funds.

The key insights here?

• Our test user didn’t have this distinction between new and old
  money; she simply wanted her retirement savings allocated according to
  her revised investment strategy.
• Even users who understand the distinction between new and old
  money might prefer to treat their retirement savings as a single unit
  rather than make separate decisions (and issue separate commands) for
  the new and old money.

It would probably be better to offer a prominent feature for changing the entire account’s allocation, and use progressive disclosure to reveal expert settings for users who want to make the more detailed distinction between the two classes of money.

Bonus Mistake: Reset Button on Web Forms

This mistake relates to Web forms, but because so many applications are rich in forms, I’ll mention it here: It’s almost always wrong to have a Reset button on a Web form

.

The reset button clears the user’s entire input and returns the form
to its pristine state. Users would want that only if they’re repeatedly
completing the same form with completely different data, which almost
never happens on websites. (Call center operators are a different
matter.)

Making it easy for users to destroy their work in a single click
violates one of the most basic usability principles, which is to
respect and protect the user’s work at almost any cost. (That’s why you
need confirmation dialogs for the most destructive actions.)