A visitor doesn’t drop in on a web site simply because it’s cool, or looks attractive, or has terrific navigation. Instead, a visitor hopes the site will help him or her to accomplish a goal. If the tasks necessary to achieve that goal become at all difficult to complete, the visitor is likely to abandon the site and search for a competing site that is easier to use. Thus, we must determine the needs of our visitors and do whatever we can to make those tasks seem effortless. If we can meet the visitor’s needs, we will have established a long-term relationship with that visitor, and our site has the potential to be a success on the web.
Consequently, the best way to support an organization’s goals is to consider how best to support our visitors’ goals. How do we go about sustaining a business goal, such as to sell lots of products, while at the same time supporting visitor’s goals to buy something? What works for both of us? Well, of course we need to demonstrate to visitors that our site is reliable and provides the best value, or the best quality, or the best service. Then we allow the visitors to make purchases easily and quickly. Anything that interferes with visitors’ goals is ultimately counterproductive to a site’s goals as well, because visitors will be disinclined to use the site.
We define or identify our visitors’ goals by getting feedback from current customers, interviewing potential visitors, and analyzing competing web sites. Visitor goals might include:
-
Purchasing products or services online, as economically and efficiently as possible.
-
Researching products or services for future purchase, either online or at a retail store.
-
Obtaining service for a product that he or she already owns.
-
Obtaining information about a topic of interest.
A use case is a step-by-step documentation of a sequence of interactions that must be completed for a visitor to accomplish a task, presented from that visitor’s point of view. Normally, there is one main scenario for successful completion of the basic task, plus additional scenarios for alternate paths when things go wrong or for when the task has an unusual component.
Put all the scenarios together, and you have a complete use case for a typical user interaction. See the below for simple an example of a use case that includes two alternate scenarios.
Use Case For Purchasing A Product
-
The customer browses the on-line catalog and adds desired items to the shopping cart.
-
When done shopping, the customer clicks the “checkout” button.
-
The customer enters the shipping information.
-
The system presents full order details, including shipping costs.
-
The customer enters credit card data and clicks “place order.”
-
The system verifies the credit card.
-
The system fails to authorize the credit card.
-
The system allows the customer to re-enter credit card information up to two more times.
-
Upon third failure, the transaction is terminated with an error message.
Alternative: Authorization Failure
-
-
The system confirms the sale immediately.
-
The system sends a follow-up email to the customer.
-
The system displays the full order details, including the customer’s standard shipping option and the last four digits of the credit card.
-
The customer may accept or reject the standard shipping and credit card information.
-
The customer clicks “place order.”
-
See Steps VI and VIII in the primary scenario.
Alternative: Repeat Customer
We also need to analyze how often a visitor might perform each task. Those that are performed often should take priority and have the most visibility on the site.
Design Patterns
One way of analyzing any task is to see how it might fit into a design pattern, a common, recurring problem that can make use of a standard solution. This technique relies on the belief that almost anything that anyone might want to do has been done already.
Only rarely does a site do something radically different from that recognizable metaphor. When it does happen, it’s usually an unpleasant surprise. The point is that we can re-use the patterns of the web pages that we have been visiting ourselves—patterns that have already been proven to work. We need not reinvent the wheel with every site. In fact, it’s not just a waste of time, it’s likely to be a failure!
Design patterns can include not only a sequence of visitor interactions but also a recommended layout for the necessary pages and specific guidelines for designing those pages. Such design patterns proliferate on the web.
Last Words
By identifying target audience goals, we can support visitors’ decisions and actions, not only the best-case scenarios (the user completes his or her intended task) but also the worst-case scenarios (the user doesn’t complete a task or encounters an error). We are always searching for ways to expedite the entire process.
There have been 2 comments | Subscribe to Comments | Jump to Form »
Sergiu Naslau
Interesting approach explaining the process. I would have to agree and disagree with you on the design patterns. I agree that sometimes is a waste of time, and sometimes, time is money (even if it is a insult to time ), and in the same time I have to disagree. I disagree because, from my own opinion, it limits my creativity process, I always want to create a different approach in a design/development/marketability of a project. I don’t need to reinvent the wheel, I need to reinvent myself.
Martin
Design patterns are something I have used when writing software and are generally accepted in the software development industry but don’t think they have been embraced as readily in our industry.
This is a real shame because not only do they save time through re-use, but they also create a familiarity for end users. Just imagine if every online shopping site followed the same metaphor…