At Hippo, we take a user-centred approach to our work. We believe in the approach of understanding people’s needs, problems and the constraints we need to operate within.
Then we design to:
- meet those needs
- remove problems
- remove or acknowledge constraints
People often ask me what is the value of taking a user-centred approach, with questions like:
“Why do I need a researcher when I am a user?”
“Why do I need a designer? Can’t the front-end developers do it?”
“I know what I need to build; why can’t we just build it?”.
I’ve heard lots of explanations about what the value of being user-centred is. But, in my experience, some descriptions put people on the defensive. Typically, they talk about testing things with users, understanding their needs, and making sure the service works.
I don’t think this always lands very well.
Answering the question about the value of a user-centred approach to creating products and services can be ideological debates. Defining terms like ‘user needs’ can become abstract concepts around what is or isn’t.
As someone who takes what I consider to be a user-centred approach, the answer is that we can’t always start with a researcher or a designer. Sometimes, situations out of our control mean we just have to build something. For example, during COVID, teams were able to take the design system and create a functional service quickly and then iterate after. This was vital when we had to create something quickly.
The work we do to deliver great products and services is about understanding the risks associated with the work. Then we decide which are high impact and have a high likelihood of occurring.
Understanding risks
From my viewpoint as a Product Manager, the user-centred approach is about risk mitigation. That’s probably not as exciting an explanation as some would give, but it’s ultimately what we’re trying to achieve. Remove risks, and make a service as successful as it can be. Being user-centred in your approach helps you mitigate your biggest risks. It can also help highlight unseen risks and mitigate those as well.
When starting on a new project or working with a new client, I like to understand what they’re worried about, the risks from their perspective, how likely they are, and the potential impact.
Every product or service carries some risk. Whether it has unclear needs or scope, lack of user involvement in understanding problems, or if we don’t get this done in a set timeframe, we’re going to miss the market we’re aiming for, or we’re not going to get the next round of funding.
These troubles are significant in products and services that go awry. In an ideal world, risks and constraints wouldn’t exist, but we live in an imperfect world. We have to mitigate the biggest risks to a product or service.
Teams remove risks
The starting point is to understand which risks are the most likely to occur and which have the highest impact. To do this, I like to run assumption sessions with people working on the project or service, but you can do a lot of other activities, such as pre-mortems or slider success workshops with stakeholders to tease out what they’re worried about.
When discussing the value different professions bring, I try to position them as risk mitigation experts. Each profession helps mitigate certain risks incrementally, sprint by sprint. For example, here are typical agile roles and a none exhaustive list of how they can mitigate risks:
- Product Managers mitigate the risk of not delivering something of value to users and organisations.
- Delivery Managers mitigate the risk of not delivering anything.
- Technical Architects mitigate the risk of the whole technological system not working with other products within the ecosystem and meeting users’ expectations.
- Researchers mitigate the risk of the team not understanding service users and what they want to achieve.
- Interaction Designers mitigate the risk of users not being able to use your product.
- Content Designers mitigate the risk of users not understanding the service, what they need to do and when.
- Business Analysts mitigate the risk of the team not understanding the acceptable level of quality to deliver great experiences for users and achieve an organisation’s goals.
- Service designers mitigate the risk of products and capabilities within and across organisations not forming a coherent experience for service users.
- Engineers mitigate the risk of a product never being available and performing to a sufficient level of quality.
- Performance Analysts mitigate the risk of not being able to measure our success in delivering value.
- Testers mitigate the risk of having a service that stops a user from doing what they want to do.
Then there is typically a wider team, such as marketing or communications, that helps mitigate the risk of people not finding out about the product or service, plus legal and compliance teams that mitigate the risk of breaking the law or the service being stopped.
I believe that Agile ways of working are also about risk mitigation. Show and tells de-risk the direction the team is taking to stakeholders, stand-ups de-risk the team not being continuously aligned, and retrospectives de-risk the team or environment becoming dysfunctional.
Agile teams constantly aim to deliver value by continuously reducing risk. We achieve this through continuous delivery as needs, problems and constraints are discovered. Agile provides the opportunity to recognise and mitigate risks early. It creates an environment and culture of a common platform and language within the team for people to communicate easily and ideally unambiguously.
Transparency at all levels is critical.
In summary
Risk mitigation is achieved through:
- cross-functional teams
- sustainable and predictable delivery pace
- continuous feedback and insight
- solid repeatable technology selection
- decisions making processes
- good engineering practices
Yes, Agile is about delivering value. But I believe that value and technical expertise only serve the greater purpose of Agile: to mitigate and reduce risk continuously.
If you want to de-risk the delivery of your service or the value of your service, then get in touch.
