Framing the problem

User Stories

User stories have been central to software development for many decades. The user story is often the fundamental work unit of a given agile software development effort. The general construct of a user story is: As a , I want <goal/task>, so that . Mature practitioners also include a definition of done so that the engineering team knows when the solution meets the acceptance criteria. User stories emerged as a response to bulleted lists of feature requirements. They allow engineering teams to clearly see who benefits, and how they benefit.

In that user stories are generally sprint-sized portions of work, a team cannot create them without the involvement of the developers. Many UX teams don’t use them initially, although many UX teams do use scenarios or experience outcomes and will convert them into user stories which support the scenario or experience outcome just prior to sprint planning. There will usually be multiple user stories for each scenario or experience outcome.

Use Cases

Use cases are the oldest of the constructs covered in this unit, and are still taught in many CS curricula. Use cases emerged from the Unified Modeling Language (UML) effort. They were formally introduced in 1992 with the publication of Object-Oriented Software Engineering – a Use Case Driven Approach. The formalism of UML gained widespread adoption in the early software industry, yet there were scarce voices governing terminology or application, leading to a profusion of interpretations. Some practitioners joke that UML stands for unrelated modeling languages.

Complete use cases include a title, a primary actor, a goal in context, a scope, a level, a list of stakeholders and interests, a precondition, minimal guarantees, success guarantees, a trigger, main success scenario, extensions, technology and data variations. Most of the time use cases are considerably less fleshed out, but they always involve an actor and a goal in context.

Use cases frequently used bulleted lists of business requirements as an input. They generally are not produced by user experience design teams, and they can be formulated and used without any user input.

Any system can be misused or abused. The various forms of user experience prose described in this module often evolved in order to address the disconnected user experience that emerged from a purely use-case-centric engineering model. In that use case actors may or may not be based on real people, and in that real people are rarely recruited to validate them, engineering efforts based on use cases alone can produce disconnected interactions which didn’t consider user goals or context in completing a task.