Triggers. Actors. Flow. Complexity. These are words that come to mind when we hear someone say “use case“. Use cases are, of course, an irreplaceable and necessary facet of the software development lifecycle (SDLC).
In the context of software development, a use case is not only a description of the actual task at hand, but also a description of how the website ought to behave in the event that a user triggers the task, among other things.
The key, here, is to define the correct sequence of events that will allow a user to complete the predefined task. This becomes highly relevant during two very distinct phases of the SDLC: the UX phase, and the QA phase – but more on that later.
Use Case Etiquette
Having briefly touched upon what a use case is intended to accomplish, let’s address some surface-level etiquette before delving deeper down the rabbit hole. We’ll begin as close to the surface as possible: what exactly does a use case look like?
Each use case is represented as a sequence of simple steps, beginning with a user’s goal and ending when that goal is fulfilled – Usability.gov
A sequence of steps means nothing, however, without an industrywide accepted operational definition of the elements used to describe the use case. There are a few elements that are critical in most useful case studies. They are as follows:
- Preconditions: predetermined conditions which must be met for the use case to be valid.
- Actor: any user which performs an action on/within the system.
- Trigger: this is the event that causes the use case to be initiated.
- Standard Flow: refers to the succession of events and triggers which detail a typical (and successful) use case.
- Alternate Flow: variations of the standard flow which become relevant when something goes wrong or prevents the use of the standard flow.
- Stakeholder: an individual (typically the client) with vested interests in the behavior of the system.
So, what does a simple use case look like?
Down the Rabbit Hole: Use Cases During the UX Phase
Even though UX designers learn early on that use cases are critical during the UX design phase of the SDLC, you’d be surprised to find out that many of our competitors don’t make use of these fundamental tools.
This section is for those of you (and I know you’re out there) that don’t regularly use use cases in your workflow, for one reason or another. Why should UX designers care about use cases? Because they make your job easier to do, and easier to check.
Designing around a predetermined set of use cases – which come directly from the client, makes it significantly easier to define and test the actual “usability” of the software. Like blinders, use cases allow the UX designer to focus on the specific flows which they are accountable for.
Further Down the Rabbit Hole: Use Cases During QA
Use cases aren’t reserved for the UX phase of the SDLC, either – they are critical to some parts of the QA phase as well. When reviewing the usability of a given piece of software, it is critical that the QA specialist have the use cases on hand.
How else can one judge whether or not the UX designer was successful in his/her endeavor to faithfully reproduce the vision of the client? Use cases give QA specialists a set of criteria which had to have been addressed by the design.
In fact, one could argue that QA tests conducted on a piece of software without adequate use case documentation are only completing half of the job.
Conclusion: Use Cases Are Unavoidable
UX designers (and QA specialists): whether you like it or not, use cases are a part of your job description. They give you the blueprints for crafting a successful implementation of the client’s vision of the product, and the foundation for a successful quality assurance test of the software’s usability.
More from the Smart UX series
- Smart UX: High-Fidelity Wireframes
- Smart UX: Use Cases ← You are currently reading this
- Smart UX: Designing for the Future