Building the ultimate user experience through user stories

Is a quick sketch of the desired user experience (UX) sufficient or does development need more detailed specifications? How do re-usable interaction patterns, such as entering an address or the behavior of a slider, fit into an agile method. In this post, I provide some tips and examples for product owners and UX designers on how they can apply user stories and epics to deliver a better user experience.

In an agile setting, user stories serve as an important framework for design activities. However, the scope of user stories is often too narrow for UX design. For users, a given feature always exists within a larger context. In this way, the addition of a travelling companion is always an element within the larger context of purchasing or amending a travel insurance policy. A proper user experience can only be designed when the UX designer takes this context into account as well.

In more complex situations, the user story is also often not broad enough in order to deliver sufficient value for the user. In these situations, adding an epic might help.

In an epic the product owner documents all the necessary activities to deliver user value. Imagine then a “80% design” (a concept), the roll-out plan, checks of quality requirements such as a Product Approval Review Process by the business, staff training and the organization of marketing campaigns.

(Bron: Agile Alliance)

At Informaat, we have successfully applied epics for UX design within large organizations, both in contexts where large legacy systems and many interdependencies played a role, and in situations where the team created a new product from scratch. This offers the opportunity for design to include more features and functions within one concept design, and therefore deliver a solution which is more consistent and user-friendly.

Tips for UX design in epics

• Add a concept design to the epic to provide a context for individual user stories. By doing so, all stakeholders will understand the intent of the design and can therefore better contextualize and assess design decisions.
• Refine the epic in collaboration with the business. Do we expect this to deliver the desired user value? Validate the design through user testing in order to validate this.
• Split the epic into user stories to be built by, for instance, using techniques such as story mapping.
• Then use the concept design in subsequent refinements for individual sprints to further visualize customers’ desires. But make sure that the concept design is not the final solution. Rather, it’s an initial visualization of the customer desires, in order to make them tangible and to be able to discuss them.

Examples of epics

Suppose the business wants to launch a new insurance product. The possible epics could be:

• As a traveler I want to insure myself, so that I am reimbursed in case of theft or injury.
• As a traveler I want to be able to adjust my insurance so that it better fits my personal situation.

Or suppose a healthcare provider wants to develop a portal to assist consumers in living a healthier lifestyle. Epics could then be:

• As an affected person I want to consult health information, so I can alter my behavior in order to live a healthier life.
• As a patient I want to consult information about my illness, so that I can alter my behavior.

User stories are in fact short, simple descriptions of a characteristic (‘feature’), formulated from the perspective of the user. The product owner is responsible for these user stories, but he or she can delegate the writing or assessment of them to someone else, such as a UX designer.

There is no perfect formula for a user story. Just like for all methods in an agile context, each team can decide what best suits them. Relevant aspects include the maturity and size of the product, the maturity and capabilities of the team, the maturity and structure of the organization and the product definition (is the website a product or a ‘feature’, such as payment?).

Tips for user-centered user stories

• Formulate the title of the user stories as easy to remember and use a noun and a verb, like ‘Setting preferences’. When it is not feasible to realize the user value in the user story within a single sprint, then use the epic instead, and formulate as many user stories as necessary to realize this value.
• Specify the user as much as possible, preferably in terms of a persona or in terms of the user type that the persona represents.
• Describe a clear objective in the “in order to” element of the user story, and avoid repeating the intended action in indirect terms. It helps to imagine what would make things easier, better or more relevant for the user. Position yourself in the user’s perspective and don’t be led by business objectives or assumptions.
• Add a wireframe and/or a visual design as an appendix. If possible, refer to the style guide. Finalize the design in collaboration with the team during the refinement phase.

Acceptance criteria for a user story describe the requirements the features must fulfil in order to be accepted. In practice, we see that UX designers integrate UX aspects in these criteria. In the spirit of agile working, this design forms the outlines of the proposed solution. This provides freedom for the team to come up with solutions which are feasible within the time constraints of the sprint.

Tips for acceptance criteria

• Identify the acceptance criteria which influence the UX, so they can be quickly identified during the test.
• Refer in the acceptance criteria to a specific version of the design system or the style guide. If no design system or style guide exists, refer to general design principles and indicate how these principles have been interpreted.
• If necessary, include criteria for text and copy. For example, think of the tone of voice, writing style or standard formulations for messages.
• Adjust the design approach to the situation. When the team has longer experience working together, the criteria might be shorter.
• When the same principles and solutions regularly reappear, this can be seen as a starting point for a design system or style guide. A design system is a framework containing all the relevant principles for the organization, rationales and re-usable components. With comprehensive design system, proven solutions can be re-used quickly.

The Definition of Ready (DoR) determines if the user story is ready to be included in the sprint. Sometimes a user story is ‘ready’ when there’s a fully specified design, but many user stories are understandable with only a sketch. In this case, the team further specifies the design during the sprint.

The Definition of Done (DoD) determines whether the software is ready to be launched. UX specific criteria in the DoD assist in demonstrating the resultant user value, and proving whether it has truly been preserved during the design and development.

With a few simple activities you can already make a start:

• Select with your team one or two proper examples of epics and user stories for your situation. Hang them on the wall, ensuring they’re readable from afar.
• Reserve a retrospective to focus on the quality of your user stories. You can use one of the standard formats for the retrospective, like Keep doing, Stop doing, Start doing, Do less or Do more.
• Check on a regular basis if your way of working is still effective and efficient. Is the team too often reinventing the wheel? Are you too frequently discussing basic starting points of the design? If so, look into the possibilities of developing a design system. Use an existing design system as a foundation in order to speed up its implementation.

Do you also have tips to extract real user experience from user stories? Let me know.