Requirements
One of the key characteristics of a high-performing team is the shape of their requirements backlog, no matter if the team is co-located or distributed. During my career, I haven’t seen enough examples of well-executed Product backlogs. I found this to be a sweet spot where I am contributing as a practicing Product Designer.
I am trying to bridge the gap between a great idea and delivery through evidence-based problem-solving. There are many tools and techniques to choose from to define outcomes in each project phase. From Ethnography and User Research through User Journeys, Service Blueprints, Scenarios, User Stories to UI hand-offs and Design Systems. What truly matters is how these deliverables can effectively communicate the intent to other humans.
Project Repository
Requirements. Features. Specifications. Backlog. Stories. Roadmap. UI Specifications. Kanban boards.
The success of a project repository is defined by its content structure. I found wiki knowledge base such as Confluence to be the best way to complement the user story backlog and keep promoting this taxonomy for quite a few years.
Myths
The number one excuse why teams don’t bother with detailed product specs is that it changes over time. People are just assuming that it is not worth bothering to document it in detail because something is changing.
Some teams believe they have a product backlog, but all they have is a discrete collection of implementation Stories. You can see implementation Stories defined as “As a user, I want to externalize the Hook_UP API so that I can query the DB6 without auth” or “As a user I want the button to be blue because it would be awesome.” I am yet to see a user who wants any of this.
Specification documents are a communication tool targeted towards another human. There is a programmer, trying to figure out what he is supposed to do and why. No matter how reasonable the templated formulation looks like, I have the best experience with communicating in plain language, what we are supposed to do here and why.
Something like that
A common Agile misconception is, that since the process is iterative, a perfect outcome is achieved by an iterative sequence of vague specifications. This “Agile” approach is often manifested by constant re-work, where the first story is a start of never-ending series.
- Story 1: Let’s develop some calendar picker like this [static picture].
- Story 2: Not that one, a better one that includes time selection.
- Story 3: By the way, timezones too.
- Story 4: It looks horrible man, let’s completely re-design it.
- Story 5: It’s not possible to re-skin this 3rd party stuff, we need to find another one.
- Story 6: Where did my timezones go?
This might be not true for a handful of technological requirements, but the best product documentation is based on user interaction. This does not always have to be in the form of pixel-perfect UI Screenshot. Sometimes, a plain simple use case with a clear initial state and outcome can do magic.
Sure we have Backlog
A very challenging situation arises when there are multiple instances of the definition of what should be done to achieve a successful product release. Some of it lives in PowerPoints, Emails, as over-the-air verbal agreements coming from meetings and workshops. Other pieces of information are living in tools used exclusively by programmers for technical specs, while the design specs are completely separated from the roadmap and actual project planning.
Just the existence of a central cloud-based tool will not guarantee the backlog centralization. Some people might still take screenshots, customizing, and virally spreading their own and modified reality snapshots. The best conclusion I was able to draw from my observations is that people need to become comfortable with sharing their work-in-progress and step into someone’s else draft to contribute directly. Gluing various tools together with links and embedding widgets can do magic, and my personal favorites remain to be Atlassian Confluence and InVision tools.
Conclusions
I am spending a significant portion of my capacity maintaining the backlog. I found this to be an activity that enhances my efficiency as a designer, not a burden.
As Designers, we have the tools and craft to bring transparency into the process and define the functional product specification in a much more coherent way than “As a user.” We can include diagrams, workflows, use cases, scenarios, UI component states, or even short animations directly demonstrating the intention and match this to User Research outcomes or Personas.
