Effective Design Research: Analyze Goals First
Imagine that you make $100 a month at your current job and that your monthly expenses are $85. In order to take a well-deserved vacation next year, you need to save $240, or $20 a month for the next 12 months. What should you do?
Actually, there's a lot of things you can do - it just depends on how you state your goal...
For example, if your stated goal is to save more money, you can cut down on your expenses or perhaps look for a bank account that will pay you a higher interest rate. However, if your stated goal is to make more money, then you should start looking for either a second job or a higher-paying job.
If you happen to state your goal more abstractly, such as you simply want to have more money, then you've actually got a lot more options available: begging, borrowing, and stealing are all valid means (some more legal than others, of course) for you to ultimately having more money. So is playing the lottery.
If, however, your stated goal is to simply take a vacation, then you can consider delaying your vacation date until you have enough money or perhaps choose a slightly less expensive place to visit...
Your Point (and I Assume You Have One) Is...?
The point of that (lengthy) explanation is to demonstrate how a small difference in the way a goal is phrased can drastically change the tasks that are necessary to accomplish that goal. Talking about the steps you need to take to accomplish a goal is completely dependent on the goals that have been identified - a fact of life that many designers, unfortunately, seem to forget.
Many designers of technology-based products spend a lot of time working on task analyses - detailed step-by-step evaluations of how a person should (or could) best accomplish a particular task. By focusing only on conducting task analyses, however, the resulting design work is usually nothing more than tweaking an existing set of tasks.
Without truly understanding the customers' goals first, it's not surprising that a solution based on this type of design approach often fails to help the customers completely accomplish their goals.
Example: Web-based Hotel Reservations
Many hotels offer some sort of "rewards" program for loyal visitors. The more times you frequent a particular hotel chain, the more points you can earn towards buying things such clothing, magazines, or "free" hotel stays.
Hotel points can be used fairly easily to buy clothing or other consumer goods. However, hotels only allocate a small number of rooms per night as those that can be issued to rewards program visitors. Any frequent traveler will tell you that it's next to impossible to be able to actually use your points towards hotel stays, even though that option is frequently a top selling-point for rewards-program advertising campaigns.
Most hotel-reservation systems first ask a customer to indicate the dates for which they would like to stay at the hotel. Then the system checks to see if there are any reward-based rooms available on those dates. If there are no rooms available, the customer is instructed to select a different set of dates so that the system can check availability once again...
A task analysis-based approach to the problem might result in a variety of highly successful and usable ways to lead customers through the process of entering in their desired stay dates and viewing the results...
But what if we slightly modify the customer's stated goal? What happens to our solution if a customer's goal is to simply find a date on which she can use her reward points? You can probably see where this is going: enter dates, check results, enter dates, check results, enter dates...
Why doesn't the system allow the customer to display a list of the dates for which rewards-points can be used? After all, we know the data exists!
Chances are, the designers spent the bulk of their energies conducting task analyses, trying to improving the existing set of steps traditionally involved in the task of reserving a hotel room. In doing so, they missed evaluating the other types of goals customers might want to accomplish with the system, and therefore the tasks do not effectively support those goals.
How It's Currently Done: Task Analysis
Task analyses traditionally consist of several stages. These stages include: 1) the initial investigation of the existing workflow and the breakdown and definition of user tasks, 2) the buildup of those tasks into one or more configurations, and 3) a description of future use cases.
A task analysis begins with an evaluation of how the potential users currently do their work. Work pattern data such as workflow reports, usability test results of current systems, definitions of all the types of users, and preliminary designs of the new product (if available), are collected. All of the user tasks in this workflow are identified and often described using a visual flow diagram.
Descriptions or illustrative examples of how a "typical" user would proceed through the work flow diagrams are often created to help designers better identify with the users and to help flush out the details of any particular task.
After the high-level list of tasks is completed, the items on the list are systematically deconstructed into the low-level actions that a user needs to perform to complete those tasks, all the while looking for areas in which improvements can be made.
Often, these actions are eliminated, combined, or otherwise reconfigured to establish a more efficient, effective work flows. Use cases which describe the new operation of the system are then written to provide detailed design specifications.
Note that not every designer will conduct their task analyses in the same manner, but for the sake of argument, a "typical" task analysis methodology has been described. And if the tasks are designed to support a customer goal, things tend to work out pretty nicely.
Example: Amazon's "One-Click" Shopping
Wrongly-awarded patent issues aside, the the folks at Amazon should be applauded for their innovative thoughts around "one-click" shopping.
Designers at the massive online retailer knew that no matter how hard they tried to improve the checkout process, it was still a tedious, error-prone barrier to completing a purchase.
The designers focused on evaluating the customer's primary goal - that of simply buying a product, not filling out page after page of form information. In doing so, they were able to look past the traditional, required checkout steps and come up with a unique, efficient, competitively advantageous solution that greatly improves the customer's experience with the company.
A side benefit to their design solution is that it also helps the company meet one of their key goals: separate the customer from his/her money as quickly as possible!
"Final" Words
Understanding a user's goals - before you try to design the tasks needed to meet those goals - seems like one of those no kidding things that you assume is taught in every Design 101 class because it's so important...
The problem is that it's very difficult to do that analysis correctly, because understanding user goals to create an effective solution is only half of the picture - you also need to evaluate the company's goals. Ironically, although the company wants to make their customers happy, more often than not the company's goals are in direct opposition to the customers' goals.
Consider the following:
Customers want to remain as anonymous as possible when buying online, while the company wants to collect as much data about a customer as it can.
Customers want the absolute lowest price, while companies want to create the highest margins.
Customers don't want to be bombarded by advertising, yet companies need to show ads to generate revenue.
Customers want the highest quality in a product, while the company wants to manage production costs wherever possible.
Remember the the hotel reservations system example described earlier? Perhaps the reason that a customer can't simply search for days on which free hotel coupons can be used is because the hotel doesn't make any money when someone stays for free. Given that, why should they bother supporting that type of search when it so obviously goes against meeting a key company goal?
Analyzing user tasks is an essential step in designing effective products and interactive systems. However, if you don't fully understand what your users are trying to accomplish with that product or system, you run the risk of designing tasks that ultimately do not support their goals. And if you don't support their goals, chances are they won't be your customer for very long.
But keep in mind that you need to balance the company's goals with users' goals to truly create a workable solution. Finding that balance requires a significant amount of time and energy be devoted to goals analysis. Get that figured out first, then concentrate on task analysis.