Blog

“What happened to [insert little-used feature here]?”

It can be panic-inducing to hear a stakeholder ask this during a design review — especially when it’s several months into a migration project, and initial design work is nearing completion on a key area of the site. 

Maybe someone has a quick answer that placates the stakeholder. Maybe there’s an awkward silence while the team tries to collectively remember why that decision was made so many sprints ago. Or maybe it’s immediately clear that no one in the meeting recalls, and some digging will be required to surface the full backstory and rationale. 

In any case, having those long-ago decisions documented and traceable is a helpful form of assurance and insurance. 

I’m always trying to strike a balance with documentation. I want to document just enough so that there’s plenty of context and detail for anyone who’ll need it (tomorrow or two years from now), but not so much that I’m over-investing in documenting every little thing. A tactic that my team has found helpful in finding that balance has been the creation and maintenance of user stories. User stories can act as an informational hub, provide background and connection to other documentation, and even help mitigate risk.

Defining and tracking user stories

Documenting user stories in a structured, consistent way allows you to braindump much of what you’ve learned in discovery — so in the future, someone doesn’t need to wade through docs, decks, Murals, Confluence pages, and more to get an understanding of what the team observed and learned early on and how the strategy and approach was formed. But how do user stories actually work?

Who’s a “user”?

I’m not a purist. User stories do not always need to come from the mouths of users themselves. I use the term “user” loosely, to include:

• External folks who use the site
  • People we’ve heard from via user research or other inputs
  • Presumptive users (this is where we hypothesize and make informed assumptions for features we don’t have research inputs for, often based on our knowledge of best practices for responsive design and accessibility)
• Internal site owners and users (stakeholders, CMS authors, etc.)

To avoid placing undue emphasis on internal requests or ideas that don’t trace their origins back to an external user, I annotate stories with where they came from. Stories from multiple sources are given higher priority. 

Structuring the story

A typical user story format is some variation of “As a [persona], I want to [goal or action], so that I can [desired outcome].” For example: “As a News editor, I want to set a featured article on the listing page so that it persists above the most recent news.” When initially collecting or brainstorming user stories, or when communicating them to stakeholders and decision-makers, it can be helpful to use this format, because it grounds the story in the user goal and outcome.

When to document

The discovery phase of a project is a crucial time for collecting insights from various sources and defining user stories. This is when we write user stories that track:

• Features and capabilities in the current state of an experience, via auditing and other exploratory efforts, to document decisions around which features might remain or be declined
• Insights from external sources, via competitive research, user research, and usability testing to identify gaps and opportunities 
• Requests and ideas from internal sources via workshops, “jobs to be done” exercises, or ad hoc conversations with stakeholders, subject matter experts, or the project team, to surface thoughts from the folks closest to the subject matter and product 

But don’t stop at discovery. In order to keep the user stories up-to-date across a project lifecycle, it’s important to check back and update them when needed. Stories might drop out of the MVP when requirements change, or new stories could be added when performing usability testing on design prototypes. Post-launch is a great time to do a refinement pass to ensure things reflect the reality of what went live and what will inform post-MVP.

Building your user story matrix

In my current project, we have begun to track user stories for most related work streams and features in a central matrix. Over the years, we’ve tried various approaches, locations, and ways of organizing them, but having our user stories in one place with plenty of structure and accompanying context makes them findable, scannable, and more easily managed, especially since many stories persist over time and across site features.

What’s in the matrix

My team’s user story matrix is fairly complex, with many columns to enable detailed filtering (Figure 1). I’ve found that Airtable is the best tool for this job. The primary columns for my project include: 

• Story: The goal, or the “I want to” portion of the user story. It starts with the action and is written from the user’s point of view, such as “See all revisions of a page” or “Find a link to update my staff profile information.”
• Site area: The site section or feature (e.g., homepage, navigation, news, etc.).
• Persona: The audience or persona of the user. Might be external (e.g., Press) or internal (e.g., News admin, CMS author).
• Source: Who reported the story, or where it was observed. This is multi-select, so we know if the story has been noted via multiple sources. You can even get fancy and set something up that tracks instances of reports in order to help quantify and prioritize.
• Context & notes: A long text field to provide plenty of context, background, and links to any relevant documentation.
• Status: Options might include Needs discussion, In review, In progress, Prioritized for testing, On hold, Declined, or Complete.‍
• Priority: Options might include Highest, High, Medium, Low, Lowest, and Not set. This may be informed by how many sources reported this story, whether it’s nice-to-have functionality or MVP, level of effort, etc.

Of course, this is very customizable based on your needs; I change my mind and reorder, re-label, hide, or add columns from time to time. Additional columns might include: 

• Value add: Options might include High, Medium, Low, and Uncertain. Consistent criteria (e.g., would it solve a problem for a user? Is it an accessibility issue?) is important!
• Link to tickets or additional documentation: Links to where the work is being formally documented and completed. Because user stories persist over time, the relationship between a user story and tickets to implement related work may be one to many.
• Design exploration: Links to design documentation.
• Links to site feedback or usability testing documentation: If the “Source” is an input such as feedback or research, we link to that documentation.
• Attachment: Screenshots are nice for tracking legacy states or CMS intricacies.
• Date added: This uses an Airtable field called “Created time” that auto-populates the record’s creation date.

Reducing overwhelm

That’s a lot of columns! And a lot of information when you have several site areas you’re tracking, each with (potentially) dozens of user stories.

This is where Airtable’s features come in handy, allowing for endless flexibility in how a single data set can be sorted, filtered, and presented across multiple “views.” That way, the user stories are a single source of truth but can be organized to meet our needs at a certain time or for a certain audience.

Here are some ways we organize the matrix to make it less mind-swimmingly overwhelming and avoid that deer-in-the-headlights look from colleagues over Zoom:

• To differentiate stories across site features, group by “Site area” so that related stories are together, and then by “Status.” You can also create a separate view dedicated to a Site area.
• To help determine what should be addressed first, sort by priority. 
• To track things to test soon, create a view for items with the status “Prioritized for testing.” ‍
• To easily reference user stories that are important to a particular audience, create a filtered view, such as a “Stakeholder requests” view filtered by Source: Stakeholder, or a “News admin stories” view filtered by Persona: News admin (Figure 2).

The matrix in action

Last year, my team was tasked with iterating on a popular (and complex) search function on our client’s site. There had been a lot of team turnover since the initial design work on this feature, but luckily, past team members had documented tons of user stories in a matrix. 

This knowledge transfer created continuity that otherwise might not have been possible, which meant:

• we were able to consider stories and insights we wouldn’t have been aware of without re-discovery;
• we were able to identify persistent questions we wanted to answer via usability testing; and
• we were able to demonstrate an understanding of previous pain points and opportunities, which helped us maintain trust with stakeholders.

Just enough documentation for future you (or someone else)

Gauging what and how much to document for any project at any phase is a gamble. If I’m too precious and invest a ton of time into meticulous documentation, inevitably, there’s a strategic shift, and what I’ve labored over is no longer relevant. If I think I’ll remember something (note to self: you won’t) or that I just don’t need to track a particular decision or insight, then it absolutely comes back to haunt me later.

I track user stories as a happy medium on the documentation spectrum in order to avoid organizational amnesia without a considerable investment of time. A matrix is flexible and scalable — it can be high-level and basic, or more detailed and interconnected with everything else going on with the project. Unlike other forms of documentation (requirements, design specs), the design team is both the owner of and the audience for the user stories, which means that we ultimately get to decide what it will include and how it will benefit and inform us in the future.