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.

Background

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 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.

Looking at the project from a client 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).

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?

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.

Next…

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.

Acknowledgments
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.