How to Prevent Feature Creep with User Story Best Practices

As part of a larger digital product narrative, working with user stories throughout the design process helps designers focus on improving UX. Clearly written user stories can help keep people at the center of the design process, empathize with a product’s target audience, and generate ideas that better fit people’s lives.

How often do product designers find themselves in the proverbial “putting the cart before the horse” situation? As the project kicks off, we work out the tech details and how we’re going to deliver it. Development frameworks are defined, target devices determined, screen sizes set, then the team springs into creating solutions, adding product features at random.

During this process, we frantically generate a plethora of UX artifacts: mood boards, sitemaps, user flows, personas, and empathy maps, to name a few. The boat is loaded but sailing without a rudder or a map. Then one day, we wake up, and it hits us, “why are we making this product, how do we define its features, and how do we prioritize them?”

A classic wake-up call.

The dreaded “feature creep” is sneaking closer right under our noses.

Fortunately, there is a countermeasure to combat it. It’s a design tactic called user stories.

User stories are a collaborative design technique for product teams, adopted from Agile software development methodology. Agile teams are typically focused on achieving small goals during sprints. They emphasize speed, objectives, and results instead of extensive documentation, hence the concept of user stories.

For most Agile teams user stories are the main vehicle of incremental software delivery. Agile Alliance

What Is a User Story?

A user story describes something the user wants to accomplish. User stories can help designers and dev teams stay focused on user needs, rather than becoming caught up in the frenzy of adding product features.

A user story is short, specific, and goal-oriented. It’s a one-sentence statement framed from the user’s perspective that has the following structure:

“As a (type of user), I want (the goal), so that I can (derive a benefit).”

User stories enable a team to hold better conversations about the project throughout the development process. It helps prevent feature creep because working with them facilitates a shared understanding of what the team is attempting to build and why.

If there is any principle that is sacred to those in the field of user-interface design and human-computer interaction, it is know your user. Don Norman, co-founder and Principal Emeritus of Nielsen Norman Group

Aligning User Stories Between Design and Agile

User stories are a concept developers understand. Whether at the start of the project or during product development, designers can collaborate with developers more effectively by working with user stories. Product features can be planned together, optimizing development and clarifying what outcomes the team should focus on.

That said, many designers don’t subscribe to the idea that Agile and UX can play nice together. One of the convictions is that the two disparate motivating forces and timelines don’t align well—user stories don’t fit readily into a holistic design process because, in development, the focus is on short-term delivery cycles. Another notion is that user stories are not substantial enough as a design approach—they lack the perspective that considers the bigger picture: the entirety of the user experience.

These beliefs are valid to some extent but are also misguided.

Let’s clear the air. First, designers need to recognize that working with user stories is a collaborative design process. While it may not perfectly align with Agile sprints on the development side, they can very much be part of a more extensive asynchronous design process when collaborating with developers. User stories also make it easier for teams located in different locations to collaborate.

Second, user stories are part and parcel of human-centered, activity-centered design. Instead of focusing on adding more and more product features—the proverbial “feature creep”—user stories make it real. User stories are behind every activity people perform, which are composed of tasks, which in turn are a series of actions. As a result, products are developed with a deep understanding of user activities. Working with user stories fits nicely into the holistic endeavor of designing a delightful user experience.

User Stories for Product Testing and UX Metrics

Clearly stated user stories power various aspects of great product design. Periodically revisiting user stories and checking whether a particular user goal is achievable—the acceptance test for a given user story—will help keep the product team on track.

Businesses often spend a lot of time and money building products that customers don’t need or want, wasting both time and resources. The products may be well-intentioned, but they fail because they don’t address an identifiable need in a way that consumers understand.

By user testing the product on potential customers, product teams can understand if the product solves a clearly identifiable need. It’s a way to measure success. Building and testing prototypes based on well-defined user stories, designers can measure task completion times and success rates. Not only during the early product design phase but throughout the product development life cycle. In doing so, teams can see if the product is getting better and better at meeting customer needs.

In addition, user stories can be employed to define UX outcomes (evaluated by UX success metrics) and help designers check the product’s evolution with UX progress metrics.

• UX outcomes sync everybody up on what is being built.
• UX success metrics tell teams when they have accomplished the outcome.
• UX progress metrics enable teams to track and assess progress along the way.

How to Generate Great User Stories

User story creation starts with personas distilled from user research insights. A deep understanding of personas will help designers create meaningful stories that connect to larger user goals. In this process, unmet user needs can be uncovered, and product narratives built (called Epics in Agile).

Designers can take substantial UX narratives, driven by personas and user goals, and divide them into smaller pieces: the user stories. For example, let’s say we’re working on a mobile banking app. The Epic’s goal would be “to manage money on the go.” This larger user goal can then be split into smaller user stories, such as:

• As a business owner, I want to make mobile deposits, so I can save time.
• As a business owner, I want to apply for a loan on the go to get credit faster.
• As a business owner, I want to check my account with an app to stay on top of my finances.

How do we come up with such user stories? By employing a variety of UX research techniques, such as shadowing (an observation technique), diary studies, and user interviews. Alternatively, designers can use product analytics to identify patterns of user behavior and surface the underlying structures that drive those patterns.

For example, by observing event flows, the data may show that several tasks could not be completed. Tasks were started, progress was made, but indicated by the unexpected exits in the middle of the task, they did not reach a conclusion. Such patterns would point to people giving up in frustration because the product does not provide an easy way to accomplish a coordinated set of tasks. A perceptive UX designer would spot the issue, investigate with more user research, redesign the product feature that is not performing, and test task completion again.

How to Write and Prioritize User Stories

Who writes user stories? Traditionally, writing user stories has been the responsibility of product managers to move the development along (often when there is no designer on the team). However, when there is a designer on the team, it may be best if designers wrote them. They’ve conducted user research and are the most familiar with the user personas and their needs.

As a technique, user stories are meant to be compact and light, allowing teams to build products rapidly. As mentioned earlier, they need to be written as a simple, one-sentence statement from the user’s perspective: “As a (user), I want to (do something/the goal) so that I can (achieve the desired outcome).”

User stories created in such a fashion help justify every feature added to a product and keep the rationale behind every design decision at the forefront: the “why we do what we do.”

To write a great user story:

• It should be clear, focused, and actionable.
• It should capture the story in a way that feels valuable.
• It can be translated into a product feature.
• It has an acceptance test (was the goal achieved?).

Once written, user stories need to be prioritized into a matrix. Something familiar to product managers, a priority matrix helps ensure that the product team focuses on the most impactful features first. For designers, this means prioritizing user stories that provide the most value for customers.

Several aspects influence the priority index of a user story:

• Business objectives. A user story that directly impacts a company’s revenue should get a higher index value than that of merely desirable ones.
• Functional dependencies. If multiple user stories can only be implemented after a particular story, the latter becomes critical and gets a higher index value.
• Development time. If the dev team evaluates a user story as being fast to implement and essential for achieving business objectives, then the story gets a higher index value.

The Benefits of User Stories in Design

Working with a user story framework ensures that the product only has the features that users need vs. features the product team hopes they will use, based on hypotheses. In other words, working with user stories prevents feature creep.

Working with user stories has several benefits:

• Provides a common language. User stories become a common language for the entire development team, eliminating the focus on solutions and features. Instead, they frame the discussion around what is to be achieved.
• Fosters collaboration. They motivate collaboration between users, designers, and the development team.
• Enables a shared understanding. They help develop a shared understanding of user needs by using a common language.
• Increases transparency. They boost openness between team members, which reinforces trust.
• They’re comprehensive and cohesive. The translation of project requirements into user stories is comparatively easy in order to get a handle on the project. Walking through user stories gives a more definite sense of “what the project is about” than lists of features and functional requirements.
• Provides flexibility, accessibility, and manageability. User stories are conceptually straightforward compared to other documentation, and they’re fast to create. Users can also be involved in their generation, and stakeholders can effortlessly edit user stories or add their own.
• Shifts the project perspective. User stories shift a project’s perspective from a list of potentially random and abstract requirements to a representation of user-focused activities.
• Facilitates highest-value delivery. They help deliver customer-focused features that yield the most benefit.
• Provides a checklist. They enable measurements against successful task completions. If a user is not able to accomplish tasks, the product has failed.

Better Product Design with User Story Mapping

Designers ought not to rely on user stories alone to drive product design—a comprehensive product design process involves many other methods and artifacts. Well-integrated user stories should complete each other like pieces of a puzzle that make up the whole product’s UX. Conversely, disjointed user stories will disturb the cohesiveness of the user experience.

Other potential issues when relying exclusively on user stories to drive design:

• Lack of context (ignoring the overall UX outcome)
• No sense of completeness (uncertainty whether bigger goals are covered)
• Confusing user stories with use cases
• Not evolving the product (user stories are not fixed, they tend to change over time)

Building a user story map helps us focus on the big picture – the product as a whole instead of getting myopically focused on an individual story. Jeff Patton, author of the book User Story Mapping

Summary

Working with user stories in design provides the critical measurements designers need to deliver well-designed products. The discipline of adhering to a user story framework also means never putting a design element in a UI that doesn’t have a corresponding user story.

The appeal of user stories is that they identify functional needs but don’t stipulate how to design the product in order to meet those functional needs. They focus on the problem first before prescribing a solution.

Designers should view user stories as valuable building blocks in product design, map user stories to create a cohesive UX, and employ user story best practices. It will prevent feature creep, enable product teams to deliver better-designed products, and empower designers to create products with frictionless, delightful user experiences.

Let us know what you think! Please leave your thoughts, comments, and feedback below.