Skip main navigation

Framing the problem

Aside from the earlier discussion on scenarios and experience outcomes, what are other ways you can frame a 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.

This article is from the free online

Microsoft Future Ready: Introduction to Design Thinking

Created by
FutureLearn - Learning For Life

Our purpose is to transform access to education.

We offer a diverse selection of courses from leading universities and cultural institutions from around the world. These are delivered one step at a time, and are accessible on mobile, tablet and desktop, so you can fit learning around your life.

We believe learning should be an enjoyable, social experience, so our courses offer the opportunity to discuss what you’re learning with others as you go, helping you make fresh discoveries and form new ideas.
You can unlock new opportunities with unlimited access to hundreds of online short courses for a year by subscribing to our Unlimited package. Build your knowledge with top universities and organisations.

Learn more about how FutureLearn is transforming access to education