Originally published February 2007
Use cases, sometimes called user scenarios, are narratives or flow diagrams that describe how users will interact with a Web site. Some people also refer to them as task analysis or user flows. Regardless of what you call them, the idea is the same. Illustrate to people scenarios or specific tasks which users will perform. So the names of the deliverables are pretty self descriptive. A case (study) of a use or a scenario. Sounds right to me.
User scenarios can identify specific tasks or more general concepts and usage patterns. For example, if the information architects (IAs) at Yahoo were creating sample use cases, one might illustrate the following scenario.
A user opens their Firefox browser and sees their home page – Yahoo.com. The user checks the personalized news headlines on the home page. They then scroll down to check their local weather forecast. After that the user clicks on the Finance link to check on their stock holdings. continued…
This is a generic example without much meaning, but these types of scenarios are meaningful to information architects and designers. More detailed use cases can tell us a lot about usage and navigation patterns.
Creating user scenarios is helpful in setting the IA and design direction for new sites. If the scenarios are accurate it will help the Web team understand how the site will be used. Effective requirements analysis, user and client interviews, and observation will help lead to accurate use cases.
You may come across the terms “actor” or “external agent” when reading about use cases. These are usually just another way to refer to a particular user, but can also mean another system.
How Many Web Use Cases do I need?
This depends on the size and scope of the site you are developing. It also depends on your budget. For projects with small budgets – formal use case documentation may beyond the scope. When time and money allows, a document with a dozen or so scenarios can be very valuable to the project team. There are many variations on what the actual documentation can look like.
Real vs. Essential Use Cases
Use cases can be independent of technical specifications (i.e. programming language, server, database, etc.). Or they can include technical specifications. These variations are referred to as essential uses cases and real use cases respectively. Basically the former is a higher level scenario illustrating general concepts. The latter involves more site specific details.
Use Cases vs. Use Case Diagrams
Some make the distinction between a use case and a use case diagram. Traditionally a use case would include much greater details and a diagram would simply illustrate a general flow or process. To me, a use case is either detailed or not, and tend not to worry about the difference in terminology.
Using Use Cases with Other Deliverables
If you’re familiar with creating Web requirements and deliverables you will see the natural connection between use cases and user profiles (personas). Including user scenarios on profiles can be very effective. This approach gives anyone who reads the document – a snapshot of the target user, and overview of their web habits, and some sample usage scenarios.
If you’re experienced in usability testing you will see the connection between use cases and usability test tasks. Some would argue not to make this connection, but if you have spent the time and effort to develop realistic user scenarios, it seems they translate well to specific tasks for usability testing. E.g. a use case may describe how a Yahoo user navigates to the Finance section and performs a stock quote lookup. Why not use the scenario as a task for usability testing. The results may or may not validate your use case.
Use case example 2 (although this one is more of a process flow than typical use case)