# Usability Quality Attribute Scenario

**In short:** A usability scenario describes a user action (the stimulus) and how the system should react (the response). Adding a number, such as a time limit, makes a usability requirement testable.

## Explanation

"The system must be easy to use" is hard to test. A usability scenario fixes this. It describes one aspect of usability as a stimulus and a response. The stimulus is what the user does or what happens. The response is how the system reacts.

A scenario becomes testable when it carries a measure. The arc42 material shows three kinds:

- **Time until the system responds.** After switching on, a navigation system accepts input from its screen within 4 seconds.
- **Time to reach an action.** Users can tap Find within 3 seconds of opening the interface.
- **Error rate.** Some products need users to make very few errors, or none. There, the error rate is the measure.

A scenario can also describe a situation. One example is a new user who logs into an enterprise system for the first time. That user has had no demo, tutorial, or instructor-led training. The scenario then asks whether the user can complete the core tasks. The reason is practical. Training is unaffordable, so the software must be self-explanatory to users who know the domain.

arc42 counts such scenarios as usage scenarios. They ask how the system reacts in certain types of use. For the wider idea, see the articles Quality Attribute Scenario and arc42 Quality Requirements.

A scenario can also connect to design. The SEI report on usability and architecture pairs each usability scenario with an architecture pattern that implements it. So a scenario says what to test. It also points toward a design that supports it.

## Example

A team builds a mobile app for field technicians. Their first draft says "the app must be user-friendly." They rewrite it as a scenario. A technician opens the app on a job site. The Search button must then be tappable within a fixed number of seconds. The team can now time this in a test and decide whether the requirement is met.

## Trade-offs

The facts here describe the benefit, not the costs. A scenario covers one situation and one measure. A set of scenarios must therefore cover the aspects of usability that matter for the product. A measure such as error rate matters most where users must make few or no errors. For other products, a different measure may fit better.



## Checks

- Each usability requirement is written as a scenario with a stimulus (user action) and an expected system response.
- Usability scenarios carry a measurable value, such as a time limit in seconds.
- Where users must make very few or no errors, a scenario uses error rate as its measure.
- Learnability scenarios state the starting condition, such as first use without demo, tutorial, or training, and the reason behind it.
- Usability scenarios are linked to the architecture pattern or design that supports them.

## Related

- [Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-scenario.md)
- [Usability](https://arc.fuet.ch/concepts/quality-attributes/usability.md)
- [Usability Tactic](https://arc.fuet.ch/concepts/tactics/usability-tactics.md)
- [arc42 Quality Requirements](https://arc.fuet.ch/concepts/documentation/arc42-quality-requirements.md)
- [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md)
- [SMART Requirements](https://arc.fuet.ch/concepts/functional-requirements/smart-requirements.md)
- [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md)
- [arc42 Quality Requirements Chapter](https://arc.fuet.ch/concepts/documentation/arc42-quality-chapter.md)

## Sources

- [Achieving Usability Through Software Architecture | CMU Software Engineering Institute](https://www.sei.cmu.edu/library/achieving-usability-through-software-architecture/) — sei.cmu.edu, accessed 2026-11-09
- [Tip 1-12: Explain quality requirements through scenarios! | arc42 Documentation](https://docs.arc42.org/tips/1-12/) — docs.arc42.org, accessed 2026-11-09
- [Ease of Use | arc42 Quality Model](https://quality.arc42.org/qualities/ease-of-use) — quality.arc42.org, accessed 2026-11-09
- [New user completes core tasks without prior training | arc42 Quality Model](https://quality.arc42.org/requirements/new-user-completes-core-tasks-without-training) — quality.arc42.org, accessed 2026-11-09