I’ve been working on a way to quickly and iteratively develop and capture the understanding of people from different teams with different skills and perspectives as we define new products.
The process, and following document that structures and records our understanding, is based on five layers with progressively finer fidelity of understanding. The first layer helps to paint the big picture about ‘why’ we should be building this new product. The second layer is ‘who’ we are building it for. That breaks down into ‘what’ those users want. The even more detailed level describes ‘how’ we are going to do it. And ‘when’ introduces an element of time and knits all the parts together to create the entire product experience.
We’ve had people from different teams working together in a single shared document, using calls to discuss things quickly, chat to discuss things together, and comments in the document to raise questions that we should answer later. People join in when they are available and drop out when they have other things to do but the work flows on. It’s an interesting way of working synchronously and asynchronously, and it helps to shift the focus away from hierarchical decision-making structures towards collaborative decision-evolving.
Where there is uncertainty we have lots of activity as people work through questions, and as certainty emerges the activity reduces to the point where no more changes are being made because everyone feels settled on their understanding and how it is expressed. This is what I mean by decision-evolving, rather than someone working in isolation to create a document that is reviewed and approved by a single decision-maker.
The document uses existing methods from a variety of sources at a very superficial level, trying to put twenty percent of the effort in to get eighty percent of the benefits and move on quickly. Once that method has yielded greater understanding about the product experience it has served its usefulness. Understanding is the outcome, not the using of the methods, tools and techniques.
This way of working has a sense of narrative about it. It isn’t about producing finished artifacts to present to people who weren’t involved in the process, it’s about reaching shared understanding.
There are no wrong answers, as long as those answers help us understand together.
It’s still a work in progress, far from finished but this is what the document looks like:
This document describes the experience for users of the _______. It follows a simple ‘why’, ‘who’, ‘what’, ‘how’, ‘when’ format where each layer increases the fidelity of information to get a shared understanding from the bigger picture of ‘why’ we are providing the product to a more detailed picture of ‘how’ and ‘when’.
Is this product replacing an existing product or meeting a newly identified opportunity? What do we know about the background and origins of the idea for the product?
The ‘Why’ section helps us articulate the reasons for considering building this product. It gives us the big picture
An elevator pitch is a single paragraph summary of the product experience that encompasses the five levels of fidelity. It is used to communicate why we are offering the product and experience through what outcomes the users will achieve.
What makes our product different to others on the market, and what benefits will users get from our product that they don’t get from competitor products?
We can define success for the product as being one that users want because it solves a problem for them (desirable), that (viable), and that we have the resources to build it (feasible).
This section helps us to understand ‘who’ will use the product so that we can have more confidence that what we build will meet their needs.
Personas are generic descriptions of types of users with information about relevant characteristics.
Problem statements describe the current situation or problem the user, how it affects them, and what a solution might look like. It is important to understand the user’s problems in order to ensure the product we build can solve them.
How are users solving problems without our product? The solutions people use can include other technology and products, but they can also be more manual solutions.
What assumptions do we have about our users (what they do, how they do it), and also how we think we can solve the problems / meet the user needs?
Describe what the users will do, and not how they will do it. Examples of use cases are ‘Upload a document’ and ‘Search for content’.
User journey map
A User Journey Map is a diagram that explains the sequential steps a user goes through to achieve the Use Cases.
What pages are needed and what will look like?
What brand style guide and design patterns should the product follow?
This section describes the details of our expectations about ‘how’ the product will be built.
What accessibility standards does the product meet?
Does the product integrate with other products and services?
- Microsoft Active Directory SSO
What page load times are we expecting?
What is the average uptime of the product?
Does it work in all modern browsers?
Does it work on desktop, tablet & mobile devices?
Is the product able to be maintained, updated and patched as required?
Are account holders identified to other users?
Is password strength enforced?
Is two factor authentication available?
Is data encrypted in transit and at rest?
Is data validated upon entry and/or processing?
Does the product comply with data retention policy (6 months)?
Is user data stored in the EU?
Process maps describe functional tasks that happen within the product such as integration into other systems.
The Service blueprint is the most detailed artifact, showing what the user sees and does in a sequential horizontal view along with what processes people and technology support those actions on a vertical view. It can be produced as understanding develops from the work detailed above or once earlier stages