Use Scenarios and Use Cases
Some of the most common questions I have received in relation to the KDE User Research Profiles have been what are use scenarios, how are they different from use cases, and why do I need them. Hopefully some of this information will clarify the difference between use cases and scenarios and why use scenarios are so important.
What is a Use Case?
A use case is a description of how a user might use an application to complete a specific task. Use cases are commonly used in software engineering to help document functionality and how it is used. They can range in the amount of system-specific information from only describing the task to detailed implementation and avenues for completion. This examples describe similar use cases for the print function in Okular, including implementation details and two avenues for completion.
Okular example: Print a PDF document
- John prints a PDF document from the hard drive by opening the file in Okular, and then selecting File -> Print.
- Sara prints a PDF document from the web by opening the file in Okular, and presses Ctrl+P.
What is a Use Scenario?
A use scenario describes the context of a use case — the conditions, motivation, and environment of the task for a particular user. It is important to understand why a user might complete a specific task and how they will complete it in order to create an interface design. Use scenarios are commonly used by designers as a way to understand users’ motivation and tasks in an interface, but good engineering use cases include these extra elements of use scenarios. This example describes different use scenarios for a similar use case (printing) in Okular.
Okular example: Print a PDF document
- John is using a friend’s computer to print a paper he needs for class. He finds the paper on the hard drive and clicks on the icon to open it in Okular, the default PDF document viewer. He has never used Okular before and doesn’t find the Print button on the toolbar. John is not sure if Okular shares the same keyboard shortcuts as other applications, so to be safe, he goes to the File menu and finds the Print option and clicks it to print the document.
- Sara wants a PDF document which is stored on the web. When she clicks on the link, instead of opening in her browser, she is prompted with a dialog to save or open the document. She selects the open document option and specifies Okular as the application to open the PDF document. Sara usually only reads PDF files on the web, and this is the first time a PDF did not open in her web browser, and this is the first time she has ever used Okular. She does not see a Print button on the Okular toolbar and so decides to try Ctrl+P, which is a shortcut she is familiar with using in her web browser’s PDF plugin.
Why do we need both Use Cases and Use Scenarios?
Use cases and scenarios complement each other. They get interesting when you have similar use cases driven from different use scenarios or different use scenarios leading to similar use cases. You want to try and develop use cases and scenarios for as many functions or features and user types as possible. The goal is to make sure the different ways different users try to complete the same tasks do not conflict with each other.
These example use cases and scenarios describe how different users under different conditions might try to print a document in Okular. In particular, notice how the decision to remove the Print button from the toolbar to make the interface more simple and pleasing effects how these sample users might complete their tasks. What might happened if Okular has a number of users who rely on toolbar buttons to assist in completing tasks? Are these types of users familiar with looking through menu items or keyboard shortcuts? At the same time, consider how inexperienced a user must be to not consider looking through an application menu when all else fails. These users are not really a target user type for KDE or Okular, and so changing the design to accommodate them might not be reasonable.
Use cases and scenarios help provide developers with information to make these types of informed decisions. The next time Okular gets a bug report complaining about the Print button not available on the toolbar by default, the project has a reasoning they can cite. (BTW, users who are knowledgeable enough about using bugtracker can probably also figure out how to add the print button to their toolbar.) Also, I am in no way agreeing or disagreeing with Okular’s decision to remove the Print button from the toolbar by default. It was just a really good example.
Thanks for the explanation about this. It is just in time. I started working on user research profile yesterday and got stuck here. Was planing to google for this today and it looks like I will not have to now.
“you have similar use cases driven from different use scenarios or different use scenarios leading to similar use cases”
Isn’t that the same thing said two different ways?
skierpage: yeah, it’s basically the same thing, but inverse.
Whilst I do agree on you classification of use cases and use scenarios, I am afraid their use does not always lead to appropriate conclusions: both use scenarios and use cases are indeed often written by people of mixed skills (very advanced users, who have knowledge about development).
It is particularly the case with OS development and even more with KDE.
A very good example is the removal of the print button from Okular: it may well make the tool bar more pleasing to the more experienced user / developer but does negatively effect the usability for unskilled office workers. It is these workers we are targeting with desktop linux(es), and particularly with new generation KDE.
To be effective, use scenarios and use cases must be …. use scenarios and use cases, that is cases and scenarios drawn from real daily life use, by the average real users. These users may be very experienced in their jobs, for example reading and commenting pdf research papers with Okular, but very unskilled at using graphical interfaces, particularly new interfaces. I am not referring to a theoretical situation, but to very practical cases I met and meet with: I manage a small company which develops OS based solutions, and if we have a complaint from our customers and users is about the friendliness of interfaces.
@5c: That is the point. The cases are developed for targeted user groups which are more than just “advanced users and everyone else”. This is why user cases and scenarios are included in the same document with user profiles and personas: it all goes together. Creating user types that reflect the developer or advanced user is pointless, and so are developing use cases and scenarios in that way. It certainly isn’t easy, which is why I hope when developers have a hard time answering some of the questions in the user research profiles, they will come to me or one of the other usability project members for help. The goal of all this effort is to help developers think about *all* the users of their software. Even if they don’t get their user groups right the first time, fail to consider all the user types, or write less than effective use cases and scenarios — it will all help more than doing nothing at all.
IMHO：
1) The user groups / personae / profiles and the scenarios should be based on real users and developed in cooperation with real users in real world situations.
They should not be developed by the developers (or HCI experts or BA) on their own.
The developers (or even better a BA or HCI expert) should extract information from the environment and users base.
They should not imagine their user base themselves, because they are intrinsically biased by their expertise.
2） “Advanced users” may be a user group, and “developers” another.