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.

Five levels of fidelity

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 

Why the A-team never lost, or how to be a great team and do good work.

My name is Roger… and I have a hero complex.

But what else would you expect of me? I grew up in the eighties watching Airwolf, MacGyver and The A Team.

For me, TV was all about Airwolf and it’s main character Stringfellow Hawk, the brooding loner Vietnam vet who stole the super-copter from the CIA so they couldn’t use for morally-questionable missions, MacGyver, the a pacifist creative problem who went on secret missions to rescue people who had gotten themselves in trouble, and, best of all, the A Team, four ex-Green Berets who were accused of a crime they didn’t commit and promptly escaped from a maximum security stockade to the Los Angeles underground where they survived as soldiers of fortune. If you had a problem, if no one else could help, and if you could find them, maybe you can hire the A Team.

The A team were the best. Every Saturday afternoon they would go up against some drug-smuggling Central American dictator or nasty land-owner who was forcing the people of a nearby town to leave their homes, and every Saturday that team of four friends and comrades-at-arms would win. They never lost.

Now, the cynics among you might stay that they always won because the show was about them, but my hero worship won’t allow for cynicism. I choose to believe that the A Team always won because they had a few special qualities.

Values
The A Team had values, they had a mission. They wanted to help people, to use their special skills in service of the ordinary people who couldn’t fight for themselves. Teams need a mission to get behind, a cause to fight for. They need to have shared ambitions and goals.

Diversity
The A Team had diversity. Although from not the most politically-correct decade, they had a black guy, a man with mental health issues, and a serial philanderer with commitment issues. But they accepted each other. These different personality types didn’t always get on, but each having their strengths and weaknesses they knew they were better as a team. Every team needs diversity. Diversity of opinion and experience, of approach and of skills are essential for a great team.

Leadership
They had a strong leader. Colonel John ‘Hannibal’ Smith always had a plan. Hannibal knew his team members strengths and he knew how to get the best from them. The team could always rely on him to get them into trouble, and to guide them to work together to solve whatever problems they faced. He loved it when a plan came together.

Creativity and ingenuity
The A Team had creativity and ingenuity. They could be locked in a shed, surrounded by gun-toting bad guys, but they would always be able to build a tank out of a school bus and flamethrower out of a drain pipe. Being able to be creative, find new ways to solve problems and different ways to do things is important for a team to feel in control of itself.

The A Team had values, diversity, leadership, and creativity. They were a good team. That is why the A team never lost, or, if you apply it to real life, that is what you need in a great team and to do good work.

And yes, everything I know about life I learned from eighties TV.

T.E.A.M.W.O.R.K

Total commitment 

Empathy and awareness 

Adversity management 

Mutual respect 

We thinking 

Ownership of the project 

Relinquishment of ego

Kinetic leadership 

-Robyn Benincasa