Thursday, July 26, 2012

Identifying Product Value, Then Designing the Right Product


Identifying Product Value, Then Designing the Right Product

Published: July 24, 2012
Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.
In this edition of Ask UXmatters, our experts discuss how to identify product value and design the product your audience needs.
Every month in Ask UXmatters, our UX experts answer readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to:ask.uxmatters@uxmatters.com.
  • Steve Baty—Principal of Meld Studios; Vice President of IxDA;UXmatters columnist
  • Leo Frishberg—Product Design Manager at Intel Corporation
  • Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at BMC Software; Founding Director of IxDA; UXmatters columnist
  • Steven Hoober—Mobile Interaction Designer at Cummins; author ofDesigning Mobile Interfaces
  • Adrian Howard—Generalizing Specialist in Agile/UX
  • Mike Hughes—User Assistance Architect at IBM Internet Security Systems; UXmatters columnist
  • Caroline Jarrett—Owner and Director at Effortmark Limited;UXmatters columnist
  • Janet Six—Principal at Lone Star Interaction Design; UXmattersManaging Editor and columnist
  • Daniel Szuc—Principal and Cofounder of Apogee Usability Asia Ltd.
  • Josephine Wong—Principal and Cofounder of Apogee Usability Asia Ltd.
Q: How can you better identify product value to help you avoid mistakes in implementation—for example, building the wrong thing?—from aUXmatters reader
“You are starting to get to the heart of user experience—
assessing whether a product is not just pretty, engaging, fun, or even usable, but also whether it is useful.”—Steven Hoober
“Just asking the question puts you well in front of many practitioners,” affirms Steven. “You are starting to get to the heart of user experience—assessing whether a product is not just pretty, engaging, fun, or even usable, but also whether it is useful. Tactically, to figure this out, you should simply ask lots of questions before breaking out your sketchbook. Ideally, you can talk to prospective users and get information about how they use existing or competing products, as well as what they would expect from your notional product.
“Plus, you must always talk to the product owners, and use them to identify every stakeholder or subject-matter expert. These people know a lot more than you might think about the whole domain, the competition, the competitive market space, and even the users.
“They also very often disagree with each other, which is another good reason to ask questions. Whether you do this through questionnaires and analysis or actually put all of them in a room together for a workshop, you can both gather the information you need and make the entire project team aware of everyone’s opinions and information. Then, get all of them to agree on the objectives, goals, and principles that should guide the design of the product and enable you to judge its success once it launches.”

Design the Right Design

“Design has two important goals: delivering a good solution—getting the design right—and solving a significant and meaningful problem—
getting the right design.”—Steve Baty
“Design has two important goals: delivering a good solution—getting the design right—and solving a significant and meaningful problem—getting the right design,” says Steve. “Time and again, you’ll see organizations that are good at getting the design right, but implement products or services that fall flat as far as customer adoption and utilization are concerned. The traditional response to this issue is to look at marketing and advertising, but a much better response is to take on the challenge of solving problems of significance to people—that is, to provide value.
“There are several ways you can tackle this problem, but they all come down to this: find a way to understand your potential customers. Understand them as deeply as you can. What motivates them? What are their needs? What is the physical context within which they live, work, and play; the culture within which they sit? What is their experience and familiarity with technology—and not necessarily just digital technology, but however you define technology within the context of yourproject? Go and talk to them—or ask them to come to you if you must—and watch them? Do the same with people who have chosen not to use your product or service. Understand the criteria people use to make their product choices.
“Having done so, you’ll have a greater understanding of their needs based on empathy, and that empathy will enable you and your organization to better identify the issues of significance to those people—both customers and non-customers alike. In our practice at Meld Studios, we approach this part of the design process using a number of techniques:
  • contextual interviews
  • observation
  • shadowing
  • journal studies
  • focus groups
  • surveys
  • codesign workshops”
“In the edition of my UXmatters column On Good Behavior that is titled “Design Is a Process, Not a Methodology,” says Pabini, “I looked at the challenges of creating product value from a design perspective, writing:
“‘Design is the creative process in which we use our intuition andanalytical ability to understand the opportunities and constraints business goals, competitive markets, customer needs, and technologies present, then envision, communicate, and realize practical solutions that meet customer needs and create business value.’
“We all receive intuitive insights that result from our subconscious synthesis of information from diverse sources—including … business inputs…, but also from everything we’ve experienced in life.”—Pabini Gabriel-Petit
“To create business value, we must design products that people want to possess and use. Intuition, in relation to envisioning products, is a gift that a few extraordinary people possess in a great degree. I’m talking about the type of vision that Steve Jobs exhibited and sustained over so many years. But we all receive intuitive insights that result from our subconscious synthesis of information from diverse sources—including all of those business inputs that I mentioned in my definition of design, but also from everything we’ve experienced in life.
“On the other hand, the analytical aspect of design requires that we follow a defined process—and do the hard work of user-centered design. The Discovery Phase of that process is all about ensuring that we design and build the right product to satisfy a given audience’s needs. In my column, I explored this process of discovery in detail.
“In combination, the intuitive and analytical aspects of design balance one another. Analysis prevents intuition from ending in flights of fancy that fail to deliver value. Intuition provides the inspiration for product or feature ideas that we could never divine by merely analyzing disparate bits of information. You need that Aha! moment to innovate something great; to create something that people never before realized they needed, but once they see it, feel they must have it. But testing your design ensures that you deliver a product that actually meets people’s needs—and, thus, avoid making disastrous errors like the one Apple made in eliminating scroll arrows in OS X Lion.”

Do User Research First

“Answering the value-proposition question requires both qualitative and quantitative research; and it requires performing a technical evaluation to get a handle on the costs of creating the item in question.”—Leo Frishberg
“I always say to my prospective clients: ‘I can tell you with pretty good certainty whether users would treasure and appreciate a particular feature, approach, engagement, service, or product—fill in the blank—but I can’t tell the business whether it’s worth pursuing that result,’” replies Leo. “Providing that answer requires significantly more information than the small sample, qualitative design research I usually perform.
“Answering the value-proposition question requires both qualitative and quantitative research; and it requires performing a technical evaluation to get a handle on the costs of creating the item in question. Working closely with my market research associates, I can help craft the quantitative instrument to identify the business value. Working with my technical associates, I can help clarify the broad brush-stroke design requirements to establish a cost envelope.
“Value comes from solving users’ problems. The more you understand about users and their problems, the easier it is to discover a great product / market fit.”—Adrian Howard
“Making the wrong thing goes well beyond—and starts well before—the implementation phase. A lack of strategy or a poor alignment of a perceived need with business strategy is a far more costly error—and easily just as common an error—as implementing a thing poorly. You might want to pick up Michael Lanning’s Delivering Profitable Value—the original source of the term value proposition. Much of what he wrote in his book will be familiar to UX folks, even though he casts much of the discussion in business terms.”
Adrian sums this up nicely: “Get back to basics. Observe and talk to your users. There really isn’t any substitute for doing this. Value comes from solving users’ problems. The more you understand about users and their problems, the easier it is to discover a great product / market fit.”
For information about how to modify your approach to qualitative usability testing to get early-stage feedback on product value and discover what users really need, read Michael Hawley’s latest column, “Modifying Your Usability Testing Methods to Get Early-Stage Design Feedback.”

Ask Questions and Get Answers

“The problem is we don’t spend enough time up front on projects discussing, assessing, defining, and refining the value of what we make. We jump too quickly into design and implementation before applying sufficient rigor in deciding what to make.”—Daniel Szuc & Jo Wong
“The problem is we don’t spend enough time up front on projects discussing, assessing, defining, and refining the value of what we make,” respond Dan and Jo. “We jump too quickly into design and implementation before applying sufficient rigor in deciding what to make. We should ask:
  • What does this product do? What makes it tick?
  • What do you love about the product? Why would you buy it?
  • What does the product team love about the product? Are they passionate about what they are working on?
  • What does sales love about the product? Are we helping them to sell more?
  • Could you sell the product? Would you want to face customers with the product you have today?
  • What features would you sell? Are there any stand-out features? Any useless features? Any features you would lead with when selling?
  • What are customers saying about the product? Does it really help them?
  • At what point would you want to throw the product away? When does the product lose its value?
“And as Einstein said: ‘Strive not to be a success, but rather to be of value.’ For other lessons from Einstein, read Paulo Coelho’s ‘10 Lessons from Einstein.’”

Focus on What Users Want to Accomplish

“Further complicating the issue of understanding what to build to meet users’ needs is the fact that you are trying to please two different customers. The … person who makes the decision to buy your product [and] the person who would actually use your product.”—Janet Six
Remember, users often do not know what features they want, but they sometimes do know what they want to accomplish using a product. So, be sure to take their answers to your questions with a grain of salt.
Further complicating the issue of understanding what to build to meet users’ needs is the fact that you are trying to please two different customers. The first customer you must please is the person who makes the decision to buy your product; the second customer, the person who would actually use your product. This part of user experience is a very careful balancing act: you must please all of the involved parties while creating a first-rate design. And sometimes the most beautiful, useful design is not the one that your client will adopt. Sad, but true.

Define a Problem in Need of a Solution

“Our orientation toward problems that users are experiencing keeps us focused on market value. ”—Mike Hughes
“We state our requirements in the form of two-part scenarios,” answers Mike. “The first part describes the problem that we intend the new feature, service, or product to solve—as experienced in the user’s context. The second part continues the narrative by showing how our suggested solution would solve that problem. Our orientation toward problems that users are experiencing keeps us focused on market value. Sometimes it is hard to define a problem scenario for a feature. In those cases, we seriously question whether the feature would add value, and we drop it if it doesn’t.”

Bring Stakeholders Along on the Journey of Discovery

“From a perspective of organizational culture and politics, we don’t own the relationship with the customer—but we facilitate that relationship for the organization.”—Steve Baty
“From a perspective of organizational culture and politics, we don’town the relationship with the customer—but we facilitate that relationship for the organization,” asserts Steve. “Share your interactions with users with the rest of the business. Invite product managers and operations people to attend interviews; to come along on observation sessions; to participate in codesign workshops. If you are the one with the empathy and insight, you then set yourself up in the role of convincing the business. It is far, far easier to have them take that journey of understanding with you. They’ll then be much more likely to advocate for users when the time comes to define product or service features—that is, to define what problems you are going to solve.”

Make Sure Your Product Is Useful, Usable, and Used

“Alongside your usability tests, think in terms of analytics—
finding out whether a product is getting used; contextual inquiry—finding out how a product might work in users’ every-day work or personal lives; and focus groups.”
—Caroline Jarrett
“I agree with the question,” answers Caroline. “Although I don’t have any easy answers to it other than triangulation—that is, looking for different sources of data and comparing them. In the UK, we see the mantra ‘Useful, usable, and used’ all the time—especially in local government. You really need all three for a product to be successful. So, alongside your usability tests, think in terms of analytics—finding out whether a product is getting used; contextual inquiry—finding out how a product might work in users’ every-day work or personal lives; and focus groups. Though running focus groups is not an easy technique and they’re all too easy to do badly, they can be very valuable in uncovering people’s emotional reactions and needs.”

Build Feedback Loops into the Process

“Sometimes building and testing something minimal is the fastest way of finding out whether a feature has value.”—Adrian Howard
“I’d argue with the premise of the question,” asserts Adrian. “Avoiding mistakes in implementation shouldn’t be the goal. Instead, you should be trying to discover value as quickly as possible. Sometimes building and testing something minimal is the fastest way of finding out whether a feature has value. Organizations with sharp UX / development divides often overlook this route to discovering business value.
“If you don’t allow anything to escape the UX Design department before it is perfect, you lose the opportunity to exploit some fast and cheap techniques for early validation of product ideas that the development team can help you with.”
“Build feedback loops into the process. Design should be an iterative process, in which we take our concepts … and ask people whether we’ve gotten it right.”—Steve Baty
“Something you should also recognize is the fact that, as designers, we sometimes get it wrong,” agrees Steve. “So build feedback loops into the process. Design should be an iterative process, in which we take our concepts—for either problems we’ve identified or our solutions for them—and ask people whether we’ve gotten it right. Have we hit upon meaningful problems? Have we significantly addressed those problems? And it’s only when we’ve got this part right that we can start to work on the second part—which is the part where we get the details of the design right.”

References

Coelho, Paulo. “10 Lessons from Einstein.” Paulo Coelho’s Blog, March 16, 2012. Retrieved July 12, 2012.
Lanning, Michael. Delivering Profitable Value: A Revolutionary Framework to Accelerate Growth, Generate Wealth, and Rediscover the Heart of Business. Cambridge: Perseus Books Group, 1998.
Szuc, Daniel. “Getting to Value.” UXmatters, October 18, 2010. Retrieved July 12, 2012.
Szuc, Daniel. “The Value of Asking ‘Why?’ Johnny Holland, August 6, 2009. Retrieved July 12, 2012.
Szuc, Daniel. “UX Australia: The ‘Value’ of Asking Why.” UX Australia 2010. Retrieved July 12, 2012.

The Importance of Contextual Navigation, or Cross References in Topics


Go to article

July 23rd, 2012 | Posted in blog 6 Comments »
This entry is part 58 of 58 in the series Findability
Contextual Navigation
One of the most hotly debated topics in tech comm deals with how writers should cross reference other topics within a help topic. Some writers feel that including contextual or inline links in your help topics distracts low-literacy readers by encouraging them to navigate elsewhere. The low-literacy readers, they argue, end up bouncing from page to page, following one internal link to the next, without ever completing any page’s full message. (For more information on how internal links hurt readability, see Embedding Links and Online Accessibility, an interview I did at a previous STC Summit.)
Another group of writers believes that omitting internal links due to readability is non-sense, that readers skip from one page to another because they are looking for the right information and aren’t finding it. They leave a page not because they’re distracted by an exit link, but because they’re still looking for the right information. As such, embedding more links within your content provides a wayfinding technique to help users locate information. (See Re-thinking Inline Links: DITA Devotees Take Note, an excellent article by Mark Baker.)

Contextual Links Provide … Context

Overall, contextual links provide one of the strongest navigation methods for users due to the context they provide. In a table of contents, the user usually has little context about the meaning of the link. But when you include the cross reference directly in a paragraph on a page, readers have all the page content as context for the link. As a result, readers have a much better idea about the link. The abundant context for inline or contextual links makes these links such a good technique for wayfinding.
Additionally, readers often do not use your site’s navigation to land on your content. Think about the last time you searched for something on Google. You probably started reading the page where the term appeared, gathering more context about relevance of the result. If links for more information appear directly in the page content you’re reading, you’ll likely to follow those links rather than look to navigate the site’s content through a top menu bar or sidebar navigation. Again, the context surrounding the link guides the reader in powerful ways.

Publishing Complexities of Contextual Links

Perhaps technical writers feel so strongly about contextual links because of the publishing complexity these links introduce with single sourcing. If you single source your content into multiple deliverables, you have to ensure the cross-reference in one topic doesn’t point to a topic that isn’t included in your output.
For example, let’s say you have a Beginner’s Guide, a Publisher’s Guide, and anAdministrator’s Guide. In the all three guides, you have a topic called “Managing Categories.” In the topic, you reference a related topic called “Converting Categories to Tags.” The topic “Converting Categories to Tags” is a task only administrators can do, so only the Administrator’s Guide includes this topic. Therefore your cross-reference needs to be conditionally included in just the Administrator’s Guide while being excluded from the other two guides.
Multiply this same kind of scenario for every cross-reference, and your conditional text can become a headache. About the only solution is to create a grid of all your topics and your deliverables (putting topics in the left column, deliverables on the top row), and then add a X in row for deliverables that contain the topic.

Relationship Tables

One way around the complicated grid technique is to use relationship tables. A relationship table includes a set of links at the end of your topic. The links will point to other topics only if those topics exist in the output. If the topic doesn’t exist, the link is not shown. Relationship tables are a smart way around the problem of deciding what topics are included in what outputs. (See my post on Discovering Relationships Tables for more information.)
Relationship tables seem like a neat solution, but they don’t include the cross reference in the appropriate place in your content. Many times you may want to briefly allude to a concept or idea and then refer readers to another topic for more information. If you omit this referring sentence in the context when it would be most helpful to readers, you lose a lot of the immediacy and relevance of the cross reference. Ultimately a relationship table is no better than a “See also” list of links at the end of a topic.
In Designing Web Navigation, James Kalbach says that contextual links help readers discover information they wouldn’t otherwise know to look for. Kalbach writes,
Contextual navigation doesn’t support known-item seeking well. Instead, it supports exploration and may point people to new information. For a business standpoint, contextual navigation provides opportunities for upsell. Product pages in e-commerce sites, for instance, often have links to related products and services. (p.93)
In other words, the contextual navigation gives readers opportunities to learn about new information they wouldn’t have otherwise thought to seek out. In that case, merely listing a link at the bottom of a topic loses the power of the upsell. The reader may not understand how the new link connects with the current concept or technique, because the reader isn’t particularly looking for that information in the first place. Without more forcefully bringing in to the reader’s attention, the link gets lost in the background.

Inline Link Styles

If you’re going to include internal links, you have some choices about how to style those links. If you’re accustomed to using a web style, you might think that hyperlinking a word or phrase is a good way to include a link. For example, when you read the following online, there’s nothing confusing about the sentence:
In WordPress, the loop is the main code that shows your latest posts.
However, consider what this same text looks like when you single source it to print:
In WordPress, the loop is the main code that shows your latest posts.
You can style the print output so that hyperlinks look like regular text (as I assume one would do with a print deliverable). The problem is that the reader now has no idea where to get more information about the loop. Perhaps you could leave the link styled as a link, with blue font and underlining. However, assuming the user will print the guide, often in black and white, the user cannot tap or click the paper to go to the link. The user is not told about where to get more information.
If you plan to push content to print, it’s better to include the cross reference spelled out, like this:
In WordPress, the loop is the main code that shows your latest posts. For more information, see “The Loop” on page 23. [This assumes "The Loop" is a topic in your help.]
OR
In WordPress, the loop is the main code that shows your latest posts. For more information, see http://codex.wordpress.org/The_Loop. [This assumes the link falls outside your help system.]
Now the reader can know where to go for more information.
If you plan to leave the print version bereft of cross references altogether, hoping that the sentence would make sense without the link at all, you put a lot of cognitive strain on your style.
In WordPress, the loop is the main code that shows your latest posts.
Now every time you include a link, you’ll need to make sure your sentence reads well even if the link doesn’t appear in print. That might be okay for the above sentence, but what about this one:
In WordPress, one key feature you must understand is the loop. The loop is integral to the way all content is displayed. Beyond the loop, publishing also requires knowledge of other PHP tags…..
The reader may be thinking, uh, if the loop is so important, can you give me any tips on where I can read more about it?
If some links render well in print when removed, and other links introduce confusion without more information, writing becomes more of a dance of decisions that will slow you down. It’s better to adopt a style that will work almost every time.
As long as the outputs aren’t too confusing, I prefer to include links directly in the paragraph where they make the most sense to appear, rather than later at the end. I typically don’t have so many outputs that the inclusions and exclusions become overwhelming.

Overall Strategy

When you include inline links, your strategy should depend on your medium. If you’re writing blog posts, link freely and abundantly, without worrying about how your printed versions will look because blogs are primarily online and not printed. For example, when I read Penelope Trunk’s posts, she includes a ton of inline or contextual links. These links actually have a tremendous SEO boost even when they just point to your own site. Case in point, have  you ever wondered why Wikipedia ranks so well in search results? In part, it’s because they have a jillion internal links pointing from one Wikipedia entry to another.
But technical writers, unlike web writers, often have single sourcing matters to consider. As such, they have to follow a different strategy. My recommendation is to link where appropriate in the right paragraph, rather than at the end of a topic. If you have seventeen outputs with a complicated array of topics that are included and excluded, you may want to consider reducing these links or even using relationship tables. But if you only have several outputs, it shouldn’t be so complicated that you have to hire a neuroscientist to keep the conditional formatting straight.
I also prefer putting links for more information into their own sentences (such as, “For more information, see …”) rather than converting phrases into links. The former style accommodates a printed output that readers can understand.
I’m curious to hear about your strategy for contextual links. Do you welcome them in your help as a wayfinding technique, or do you omit them due to publishing complexity and readability considerations?

Travel plans now include the layaway route


Go to article

thumbnailby Stefania Revelli
WHAT’S HAPPENING
  • Layaway isn’t a new way to pay, but travel hasn’t traditionally been a category associated with the piecemeal-style payment plan.
  • Sears has launched Sears Vacations, an online destination where customers can put hotel and travel packages, hotels, cruises and rental cars on hold and pay for them progressively.
  • Layaway payment plans differ based on type of trip and package. A $1,499 cruise package, for instance, requires a $149 deposit and $75 monthly rate for 18 months (Sears Vacations, July 2012).
  • The site also features 100 prepaid vacation packages under $400 that can be financed over time (MoneyLand.Time.com, 20 June 2012).
WHAT THIS MEANS TO BUSINESS
  • Post-recessionary consumers are discovering savvy and creative ways to finance wish lists, without risking the bank. Long-term payment plans offer every consumer the flexibility and opportunity to make their ideal vacation a reality.
  • Sears-style layaway plans are not for the whimsical traveler, but for the calculated consumer who can plan far in advance.
  • Introducing vacations into a payment system typically associated with big-ticket household items (like furniture or electronics) shifts vacationing into a lifestyle improvement category.
RESOURCES

Failing Gracefully : Handling User Errors


ARTICLE NO. 846    JULY 24, 2012

Go Go to article

You When you stumble, you fall, you keep getting up until you can walk.
Failure is an integral part of the learning process. Every interaction we have with the world gives us feedback that allows us to fine-tune our responses and behaviors and optimize our processes. This article examines how the design of software applications can be optimized to prevent excessive user errors and how to handle the implementation of error messages.
Learning to play a musical instrument is a great example of how our errors help us refine our processes until eventually we succeed (or choose to fail). Every time a pianist plays off-key, he is immediately notified of his discordant error and tries again, refining his method until he succeeds or gives up. This reaction is the foundation of many human–computer information models:
The user makes an error. The user recognizes the error. The user adjusts so he doesn't make the error again.
Musical instruments and human–computer information models train their users using similar methods, but there's an important difference: the piano doesn't care if I actually learn to use it or not, whereas the designers of computer systems need to be concerned with this. If the fledgling pianist isn’t entirely committed to learning how to play, he’ll be easily dismayed by his frequent errors and possibly give up trying. Similarly, people who encounter frequent errors in computer systems will simply choose not to use the system or replace it with a better one. Applying principles of good design in a system from the beginning allows you to retain users. When users do encounter errors (which they inevitably will), make sure the error handling isn't as painfully delivered as an ill-placed sharp note from a novice piano player.

The 3-Part System

According to Donald Norman, there are three parts to a system:
  1. The designer's mental model of the system
  2. The user's mental model of the system
  3. The system image (the system itself)
Often, user errors occur when the designer has failed to render his idea of the system correctly to the user. There are three ways you can help users navigate within a system:
  1. Understand users and show them the path of least resistance
  2. Provide nets for users who fall outside of the main use case
  3. Gracefully degrade for user errors
Let’s dive more deeply into each of these to learn helpful ways to lead users through a system, provide safety nets, and recover from errors.
1. Understanding Users and Showing Them the Path of Least Resistance
Designers can never fully grasp all the ways in which their application might be used. Launch days for products are almost always met with a flurry of feature requests and bug reports resulting from unexpected use cases that weren’t exposed until users began to actually use the application.
Gerhard Fischer, professor of computer science at the University of Colorado and fellow at the Institute of Cognitive Science, explained this in his research paper, User Modeling in Human-Computer Interaction:
A consequence of any smart behavior of systems is that agents (humans or computers) can guess wrong and perform hidden changes that users do not like. Current systems often lack the possibility, or at least the transparency, for users to turn off these “smart” features, which can get more in the way than help… [S]ystems, even smart ones, are aware of only a fraction of the total problem-solving process their human partners undergo, and they cannot share an understanding of the situation or state of problem-solving of a human.
You can't plan for every possible use case. Instead, determine what the main use case will be for the majority of users and optimize your design for it. This is part of what Fischer, in a later paper calls "context-aware systems." Understanding users, their backgrounds, and their objectives allows you to create a system better optimized system for their needs.
Defining a main use case helps send a clear message about how you want users to interact with the application. Be sure to limit the secondary features that may distract from that main use case. Your main use case should something you can convey in a simple sentence. For example, a main use case might be: "The user orders specialty donuts.”
Now the goal is to get users flowing through the application in a way that is optimal for the main use case. Start by designing the minimum functionality needed for users to order donuts that will be delivered to their house. You might start with:
  1. A display page of the available donuts
  2. Functionality to click on a donut and add it to cart
  3. A cart view page with a checkout button
  4. A payment processing page
  5. A payment confirmation and thank you page
2. Provide Safety Nets For Edge Cases
We have established the main use case: the user orders specialty donuts. But what happens if the user just wants to order icing or sprinkles? Or what if 22% of users want to dip the donuts in gold and wear them as necklaces? You don't want your field of view to be so narrow that you miss out on golden business opportunities.
Users might want to interact with your service in unexpected ways—ways you couldn't even dream of designing for. Therefore, your application needs to be able to accommodate for the unexpected user's demands; but how do you this while still designing only for the primary use case? By building in safety nets.
Many of your users who don't associate themselves with the main use case will still be able to see themselves benefiting from your system in other ways. Provide a net to catch them, and if appropriate, send them into a use case that is right for them. Employ intelligent metrics to gain data on your users' behavior and to identify places where you're losing users. Google Analytics provides fantastic tools for tracking user errors; a Smashing Magazine article from 2011 offers a tutorial on how to take advantage of those tools.
3. Gracefully Degrade User Errors
Designing an application from the start to be context-aware and putting safety nets in place to help adjust the system to meet your users' expectations in the future are very important steps. But even if your system is optimized for a main use case and the nets are place, users will still encounter errors. It is inevitable.
In the process of Error -> Recognition -> Adjustment, we must do two things:
  1. Provide helpful error responses throughout the application
  2. Make errors seem less like failures on the user's end and more like cues for adjustment.
Error messages are often overlooked by designers or are added at the last minute without any thoughtful styling, presentation, or wording. Error messages are your last tool to get users to stay in your application.Vague 404 page or failed form submissions that don’t clearly explain what caused the failure are both types of oversights that will confuse and frustrate users.
Use error messages to your advantage. Make them noticeable and make sure any part of your system where user action is required is equipped with proper error handling notices. Twitter Bootstrap is a helpful UI Kit that will make this process easier; it offers beautifully designed alerts that you can easily drop into an application. It provides simple, elegant error message styling:
Twitter Bootstrap Alert Example
It’s also important to remember to reward users for actions they complete successfully. After all, the human brain responds better to success than to failure!
You can use Twitter Bootstrap for stylized success messages too:
Twitter Bootstrap Alert Example
Well-designed and carefully explained error messages not only help teach users how to use the system as you intended, but they also prevent users from feeling ignorant.

Designer Responsibility

The usability of a system depends on how well the designer does his job. The extent to which you understand the user base, the methods you use to measure their actions, and the way you help them recover from errors directly affect the usability of the system.
Remember to start with a clear use case and design the system to support that single use case, and to implement error handling. Then imagine other common ways users might want to use the application and determine if you want to provide functionality for those use cases, being careful not to add too much at once. Implement error handling for any additional functionality you added. Put systems in place to monitor the paths users take through the system and continually improve it to more closely match user expectations.
We all want to use beautiful, intuitive software; now you can do your part to make that possible.

Skier image provided by Shutterstoc