Towards a shared understanding of product experience
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:
Introduction
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’.
Background
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?
WHY
The ‘Why’ section helps us articulate the reasons for considering building this product. It gives us the big picture
Elevator pitch
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.
Value proposition
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?
Goals
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).
WHO
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
Personas are generic descriptions of types of users with information about relevant characteristics.
Persona 1:
Persona 2:
Persona 3:
Problem statements
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.
Alternative solutions
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.
Assumptions
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?
WHAT
Use cases
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’.
Account
Contents
Documents
Navigation
Reporting
Search
User journey map
A User Journey Map is a diagram that explains the sequential steps a user goes through to achieve the Use Cases.
Design layouts
What pages are needed and what will look like?
Style
What brand style guide and design patterns should the product follow?
HOW
This section describes the details of our expectations about ‘how’ the product will be built.
Non-functional requirements
Accessibility
What accessibility standards does the product meet?
Integration
Does the product integrate with other products and services?
- API
- Microsoft Active Directory SSO
Performance
What page load times are we expecting?
Availability
What is the average uptime of the product?
Compatibility
Does it work in all modern browsers?
Does it work on desktop, tablet & mobile devices?
Maintainability
Is the product able to be maintained, updated and patched as required?
Privacy
Identity
Are account holders identified to other users?
Security
Is password strength enforced?
Is two factor authentication available?
Data protection
Is data encrypted in transit and at rest?
Data quality
Is data validated upon entry and/or processing?
Data retention
Does the product comply with data retention policy (6 months)?
Data storage
Is user data stored in the EU?
Does the product use cookies?
Requirements
WHEN
Process map
Process maps describe functional tasks that happen within the product such as integration into other systems.
Service blueprint
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