User Stories: a strategic design tool

Collaboratively developing a User Experience Strategy

Collaborative design methods play a key role in aligning team members towards a shared and strategic project vision. In this article we describe how user stories stimulate and facilitate discussion and decision making with clients in the development of a User Experience Strategy. In our context (the development of online projects) the User Experience Strategy becomes an ‘in principle agreement’ on the shape of the project (what), its purpose (why), and provides potential implementation strategies (how). It takes into account all perspectives (e.g business, technical, marketing, brand) but privileges the intended user experience.

A collaborative approach enables clients to actively participate in the process, increasing the likelihood of achieving a collective vision for the project. This article focuses on the first step in the journey towards collaboratively developing a User Experience Strategy and is concerned specifically with how user stories are generated, themed and prioritized. Interested in more? We will be talking about this subject at UX Australia 2009 at the end of this month.


Working agency side, our involvement as User Experience professionals in a project often starts after the client has already invested in developing initial project assets. These might take the form of requirements, objectives, user profiles, user research or feature lists for example. There might also be pre-existing content or collateral if an existing site or service is being replaced.

While this information goes some way to describing the future project, it does so via the different agendas of marketing, technical, business, or brand; each asset takes a different perspective and is presented in its own ‘language’.  These different perspectives can effectively point in different directions, making a holistic view of the project difficult. It can also mean stakeholders hold different visions of project outcomes. Engaging in design at this point means risking significant tensions and costly delays down the track.

Different perspectives different perspectives in design

Different perspectives on the project.                           Different agendas impacting in the design phase

Reframing the project

By collaboratively developing a User Experience Strategy with clients, we can create a shared and holistic vision for the project that guides us through the design phases of the project. Central to a User Experience Strategy is the perspective of the people who will actually use the Website. Part of developing the strategy is re-framing the project from a user experience perspective.

Client Perspectives

Looking at the project from a client perspective

User Perspective

Looking at the project from a users perspective

The client perspective often starts as an abstracted, inside out view of the project via feature lists and technical specifications.  A user perspective on the other hand looks at the project from the viewpoint of those who will use it. By re-framing the project in terms of the intended user experience we shift to this perspective. This perspective is necessarily more concrete because it forces us to take context into account. In order to effectively think through the project from the user’s point of view we must think though some of the variables of the situation in which it will be used. This is the role of tools such as personas and scenarios; they work to ground the project in the real world, ensuring we don’t design in a vacuum.

Creating user stories

User stories are collaborative design tools which help the team to think through what the project needs to deliver from the perspective of those who will use it. User stories are generated by means of a critical translation of all existing project information (e.g scope, project objectives, business requirements, content analysis, comparative analysis, brand guidelines). User research is also analyzed through this method and the majority of the user stories are generated from this resource.

User stories (derived from agile development practices) are short statements that include the role of the user and the activity they wish to perform: the achievement of some goal, in the context of some constraint. They articulate the future system from the perspective of those who will use it (see examples below). Personas and scenarios provide supporting background and context.

Example of how user stories are created from existing data:

Requirement: Display all new news content on the homepage

gets translated into:

“regular readers are able to easily see all new news content”

Or a feature description like: Podcasting

might get translated into:

“As a member I can subscribe to news stories about gardening”

It is common in the early stages of design for clients to communicate a solution as a way of communicating an intention. E.g. “users can see their shopping cart from every page on the site”. What we want at the start of the design process, however, is not a proposed solution but rather a clear understanding of what the project, and the users, are trying to achieve. User stories place the focus on what the user is trying to do, not how the system delivers it. User stories frame the problem space without identifying the solution.

During the strategy phase the user stories remain high level. They can be broken out and refined in more detail for estimating and implementation in later project phases.  At this stage of the project we also capture business goals as user stories, naming the institution as a stakeholder e.g. “As [client] I can promote the institution”. This ensures (and reassures the client) that all the objectives and emphasis in the original project assets are captured, though these kinds of user stories are likely to be replaced out over time by related stories that take a users perspective. There are some things that are not converted into user stories, for instance standards, business rules and specific technology specifications (e.g database descriptions, browser specifications etc). These are resources to return to later, as it becomes necessary to interrogate those particular aspects in detail.

Theming Stories

Once all user stories are generated, grouping and theming the stories provides a top level picture of what the site contains and reveals an initial ‘loose’ structure. It enables team members to confirm that all bases are covered and indicates the major types of patterns and flows the site is likely to support (e.g searching, looking up contact details, applying for scholarships).

Theming User Stories

In the next step, user stories are edited from a list of all the things we could have, to the things we should have. Determining what the project should do is central to developing an effective strategy. The user stories become the framework for supporting these strategic discussions about project purpose, goals and approach.

Prioritizing User Stories
The aim of the prioritization process is to enable the client team to come to an agreement on the overall goals that (in principle) must be met by the site and why. Many factors motivate clients when prioritizing the scope of a project; cost and time are common motivators, but personal preferences can also play a part. The focus on user experience provided by user stories helps people to think through the priorities in a different way. This is in part because they offer a common language that all team members can access. Talking “through” user stories also allows the client team to better understand the implications and differences between various decisions and approaches.

The value each user story has to the project depends on its relationship to the primary user groups (represented in our case by personas) and to the overall project goals. User stories are evaluated individually and in relation to each other, through open discussion with the client team. The following sort of questions occur during this discussion:

  • What kinds of things would we have to do to get this done?
  • Is it really important that these stakeholders (users) are able to do this?
  • Is it actually possible for us to support this activity currently?
  • Is it important enough to us that we should consider infrastructure/policy changes?
  • Can we meet these goals another way?
  • Do we need to meet these goals now?
  • Is this a short or long term project goal?
Changing shape of the project

Essentially, this is a discussion where the client team thinks through how the project would “look” with or without certain user stories. The aim is not to decide how the user stories should be met but rather to allow a more holistic view of the project goals and constraints to emerge. As the implications of meeting different user stories are considered, team members can get a sense of how their choices about priorities impact on the overall shape and form of the project. Based on these discussions clients are prompted to rank user stories, using the MoSCoW_Method of method of Must Have, Should Have, Could Have, Wont Have . This means all issues are captured for future reference, but the most important issues are clearly stated and agreed to by all.

Our role in this process is to facilitate the discussion and guide decision making so that agreed project goals, primary stakeholders and prioritized user stories align and support each other. Sometimes a user story will appear important, yet it won’t align with the stated objectives. In this case it is our role to ask questions like: “This user story doesn’t support you to meet your currently stated objectives, so does the user story need to be re-prioritized, or do the objectives need to change?

Why User Stories?

Flexibility, accessibility and manageability
Compared to other project documents, user stories are conceptually very accessible, they are also fast to generate. Clients can easily edit existing user stories and add their own, regardless of their technical capability. Depending on the project, users can also be directly involved in the generation of user stories. From a project management perspective, they reduce potentially hundreds of pages of documentation to just 4 or 5, making them suitable for circulation and as a shared resource for discussion and feedback.

Cohesive and exhaustive
The translation of core project information into user stories is a relatively easy way to get an early handle on the project. Reading through the user stories gives a much clearer sense of “what the project is” than lists of features or content and functional requirements. Clients can easily read through the list and ensure that their concerns have been captured. In the early stages of a project we can often be anxious of missing things, and this methods allows all possibilities to be easily collated into one place.

Common language
User stories become a common language for the client team as well as the design team. They remove the emphasis on solutions and features, and instead frame the discussion around what the project is trying to achieve. This helps clients to focus conversation around the future design possibilities, rather than be held back by existing constraints or agendas. This is particularly important when there is a conflict between different client stakeholders as it allows team members to refocus the conversation on the end goals and work backwards from there.

Shift perspective on the project (for everyone)
Lastly, and most importantly, user stories fundamentally shift the perspective of the project from a list of abstract (and potentially arbitrary) requirements to a description of user focused activities; these are necessarily more concrete and tangible and allow the stakeholder team to conceive of the project in different ways.

The UX perspective provided through user stories becomes a framework through which we can examine and explore the future project strategically and holistically. The process of prioritizing the user stories with the client team becomes a strategic intervention, facilitating discussion around project goals and purpose. The project goals and possible ways of achieving them simultaneously emerge as a result of thinking through the project from a user perspective.


In this article, we have outlined the initial step in collaboratively developing a project User Experience Strategy via the generation and prioritization of user stories. However, any single user story could be implemented in a number of different ways during the design and build phases. Different approaches will require different levels of investment, and be more or less appropriate given the constraints. Prior to moving into design a better sense of the actual scale of the project is needed. To to this we use visual, tangible and collaborative design tools such as paper prototypes, which allow team members to think through core user pathways and key interaction elements in more concrete ways. While user stories help us to get a shape of the project (what), its purpose (why), these tangible design tools support a shared conversation about potential implementation strategies (how). These steps will be presented in a future article.

The reflection on methods outlined in this article was largely made possible through project work completed on behalf of Digital Eskimo, a social design agency in Sydney whose Considered Design methodology makes embracing these methods and approaches possible. We would also like to thank our clients UNSW, Melbourne Journal of International Law and Inspire Digital and our project partners Zumio and Redrollers for their generous commitment to sharing the design experience and process, and to all the participants who give time to our projects.

UX Australia

Michelle and Penny will be giving a presentation called “Emerging a user experience strategy: People, pencils and post-its,” at UX Australia 2009. Their presentation will outline a collaborative approach to developing a User Experience Strategy: a shared vision for the project that aligns all perspectives (e.g business, technical, marketing, brand), but is driven by the potential user experience.

Penny Hagen

Penny is a Design Strategist with over 10 years experience in interactive technologies having designed or produced a range of online and interactive community projects in Australia and New Zealand. She specialises in social change projects and recently completed her PhD in participatory design methods for social technologies at the University of Technology, Sydney.

Michelle Gilmore

Michelle has been exploring design in its many forms for over ten years. With a foundation in industrial design, her study, project experience and knowledge of business, evolved to focus on Service Design. She has led multi-disciplinary teams, in Australia and internationally, on a variety of projects Michelle has taught and lectured at various design schools including Limkokwing (Malaysia), UTS, RMIT and Melbourne University. She co-founded Neoteny Service Design in 2009.

45 comments on this article

  1. Yes! yes! yes! “It is common in the early stages of design for clients to communicate a solution as a way of communicating an intention.” This happens so often. I was facing this situation earlier today. Can be tricky to “reverse engineer” the solution.

    I’m curious about the differnce between user stories and user scenarios. I use scenarios in the same way you describe user stories. What’s the difference in your mind?

    P.S. love your diagram of how a project changes shape as different approaches are considered. So true.

  2. Pingback: User Stories: a strategic design tool- Forex4Trader

  3. Jax on

    Great article ladies…
    definitely on the money…
    see you at UX Australia…

  4. Pingback: Twitted by rickmans

  5. Thanks for your comments Suze. There might be no difference between user stories and user scenarios, depending on your definition. As far as I have been able to tell surveying different design materials and speaking to practitioners the terms user stories and scenarios (and sometimes use cases) all get used quite differently by different people in different contexts, sometimes interchangabley. In our work we user the term user stories to make reference to the single sentences that name the user and the goal they are trying to achieve as per the examples above, (though they change in their level of detail depending on where you are in the project). The term scenarios (for us) refers to longer descriptions that provide more background context (e.g why someone wants to do something and what happens before and after). In this way scenarios and personas provide supporting contextual material for user stories.

  6. This is a brilliant article. You have taken the idea of user stories and explained it in an way that gives a clear and concise reason for why projects should use user stories as the foundation for any software project.

    One thing that I would like to know more about would be about the process of selecting/creating personas. I have the general idea down, but personas always end up being the exact same as the roles that are identified in the technical requirements.

    Is this how personas are done, or is there more to it?

  7. Preeti on

    Great article and very well explained! I was just wondering if this process can be applied by starting with personas and where you already ahve user goals and business objectives in place. How does this method help, in this case?

    Also, if you were to convince your client about teh scalability of the project in future..How should one go about this?
    In most cases , the business analyst fail to understand or agree to the future scalability and say ” We can have a new design if there is any scalability , in terms of content/functioanlity”
    How to convince them?

  8. Pingback: links for 2009-08-14 | burningCat

  9. Great read!

  10. Suze:
    “I’m curious about the differnce between user stories and user scenarios. I use scenarios in the same way you describe user stories. What’s the difference in your mind?”

    I use both user scenarios and user stories – and in my practice, they are different. User Scenarios are long-form narratives, sometimes as long as a 3-4 sentence paragraph that describes the user, their context, and the entire life-cycle of their engagement with a product, service, or system. They are written into the Personas and attempt to create a human narrative of interaction mediated by time and space. User Stories, on the other hand, are just as Penny and Michelle describe – they are simple one sentence statements that for me are derived from the user scenarios and they articulate a discrete activity. One user scenario could instigate many user stories.

  11. Pingback: Twitted by uxs

  12. reinko on

    Thanks for your article. As a designer who has worked on many different websites, intranets and other interactive tools and made use of personas to improve the UX design, I agree with pretty much everything you write here. The shift from a client to user perspective is a particularly important one, that will not always be easy to make within the scope of a process.

    As a reader, I find the article long and not always convincing. I am struggling to grasp the essence of you story, which I think is to promote the use of user stories and help us apply them well. I think you could be more convincing and I would also love to read some examples, which I’m sure you’ve no shortage of.

    Thanks and good luck!

  13. Pingback: Partial Recall » Links for 2009-08-14

  14. @preeti, thanks for your comments, you can definitely introduce user stories anytime in the project, they will help consolidate the existing project information that you have. But sorry not sure exactly what you mean with regards to the question of scalability though?

    Thanks for you feedback. Without knowing more about what your technical requirements look like and how they are developed I can only make some general points about personas. The value of personas is that they help us to think through in a very grounded way who your users are, the kind of situation they will be in when they use the system and why they are doing so. (They also allow us to document this for the benefit of others). This means they need to be based on real information about real users. Personas are not driven necessarily by roles or demographics. Different personas might have the same “role” but be using the system in different situations and for different purposes or emphasis. It is these differences that need to be represented in different personas and it is this contextual information that will impact on design decisions. Hope that helps?

  15. Pingback: User Stories – strategic value? « UX think

  16. Pingback: Johnny Holland - It’s all about interaction » Blog Archive » UX Australia ‘09 report: Day 1

  17. Pingback: Twitter Trackbacks for Johnny Holland - It’s all about interaction » Blog Archive » User Stories: a strategic design tool [] on

  18. I am Francisco and I m researching about all the agile methodologies to be applicated to a mobile software development, and I found FDD (Feature Driven Development) which has the Features Lists, and then in this point I has the question:
    What is the diference between a User Stories with a Features Lists of FDD ? …even being the feature lists prioritized like the User Stories. Can I mix the User Stories with a Features Lists in one model of development, using both ?

    Thanks in advance
    Kind Regards

  19. Pingback: Johnny Holland - It’s all about interaction » Blog Archive » A UX Strategy through stories, scenarios and sketches

  20. Pingback: estetika » Blog Archive » links for 2009-11-10 | portfolio of interaction, art and stuff

  21. Pingback: Putting people first » User stories: a strategic design tool

  22. Pingback: Putting People First in italiano » Racconti degli utenti: uno strumento di design strategico

  23. @Francisco

    You might be better placed asking that question in an agile forum (like the agileusability group on yahoo). I can’t speak for how others do it, but in my experience we chose to either use prioritised feature lists, or user stories, not mix them together as they represent the system from different perspectives.

  24. Pingback: TwittLink - Your headlines on Twitter

  25. Pingback: links for 2010-01-18 « Köszönjük, Emese!

  26. Pingback: Anonymous

  27. Pingback: Bronnen Agile at ting

  28. Pingback: Hello world! | Neoteny Service Design

  29. Pingback: User Stories: a strategic design tool | Neoteny Service Design

  30. Hands down, Apple’s app store wins by a mile. It’s a huge selection of all sorts of apps vs a rather sad selection of a handful for Zune. Microsoft has plans, especially in the realm of games, but I’m not sure I’d want to bet on the future if this aspect is important to you. The iPod is a much better choice in that case.

  31. Who wants to hear something refreshing? Easy is as easy does is what I always say. So I found an easy way to make money. This technology was secretly “copied” from one of the top internet enterprises. The fact is, that this software is 100% legal, “white hat” and ethical, that even giant enterprises use it. And the best part – it is really running on full autopilot. Some people are tempted to exploit this software and use it for unethical web promotion but the owner is asking that everyone who is lucky enough to get it, please try to respect the laws of the internet. If you can spend no more than 3 minutes to download and setup this software, and then click the ‘Start Button’ just once to start this autopilot push button software… Then you can make money online. This never seen before push button software proved that the best and most profitable traffic on the internet is free traffic. You might be tempted to try to disect this software in order to ‘see the magic’ but why bother? All you really need to know is that you can download it (if the link hasn’t been taken down yet) and then push a button and watch the magic. Test it out ->

  32. Pingback: Our Bookmarks: Nov 7 - Nov 15 | Border Crossing Media

  33. Pingback: UX Strategy: Designing For The Multifaceted User | Photography in Australia

  34. Pingback: UX Strategy: Designing For The Multifaceted User | DigitalMofo

  35. Pingback: Today’s Links |

  36. Pingback: UX Strategy: Designing For The Multifaceted User |

  37. Pingback: UX Strategy: Designing For The Multifaceted User | Web & PC Geeks

  38. Pingback: UX Strategy: Designing For The Multifaceted User | Affordable Website Design - Wordpress Website Development

  39. Pingback: UX Strategy: Designing For The Multifaceted User | Gold Coast Creative Agency | 24hr Design Quotes

  40. Pingback: UX Strategy: Designing For The Multifaceted User - rehavaPress

  41. Pingback: UX Strategy: Designing For The Multifaceted User | Diancin Designs

  42. Pingback: UX Strategy: Designing For The Multifaceted User

  43. Pingback: UX Strategy: Designing For The Multifaceted User | | Tips | Photoshop | Java | Illustrator | Dreamweaver | After Effects | Graphics | Animation | Design

  44. Pingback: UX Strategy: Designing For The Multifaceted User | BoonJack Media || We make Multimedia easy.

  45. Pingback: UX Strategy: Designing For The Multifaceted User | Designer Brisbane blog