Here’s the process I use for designing high-quality performance solutions.
You can use this to solve a problem as opposed to doing what I like to call the McDonald’s conveyor belt of just taking orders and not doing anything that has a return on investment.
Let’s be hypothetical here.
Imagine someone has come to you with a performance or capability issue in their team. I like to look at the problem as a window and break it down into four sections.
The Four Performance Discovery Zones
1/ What are the key things users need to know about that topic?
How can you get them from A → B in a logical manner?
Consider the things which will move the needle.
2/ What do they know today?
It’s key to get an assessment of what is known today.
Without this, it’s like the blind leading the blind. You’re going to find it difficult to pitch your solution at the right level.
Consider:
- What do these people know today about this topic?
- Do they know its importance?
- How it supports them in their role, and how it supports them potentially in their future growth.
3/ What do they need to know that’s not been identified?
Your stakeholder’s view is only one side of the coin.
Think like a consultant (or detective) to uncover what might have been missed.
Reflect on things that they need to know to succeed in the modern era but have not been identified either by the team or the stakeholder. We can frame this as what they think they need versus what they actually need.
Quite often I find stakeholders will come to you and say, ‘This is what I think we need’.
Sometimes that might be 100% of the picture.
But I find that 9 times out of 10, there is more than meets the eye to what is shared in those conversations. It’s key that you take a consultant approach to dig down and find out what is it people think they need to know, but what is it they actually need to know?
This enables you to trim the fat.
→ You can add lots of value by taking things away.
4/ The not-known zone
The last bit is what I call the not-known zone.
This data will become apparent during the design process as you speak with both stakeholders and users in more detail.
At the beginning of the process, you don’t know about this. It’s something that reveals itself because it’s unknown to everyone during the process. It reveals itself through retros and continuous feedback.
This is a good thing. This is not something to worry about at all.
It’s part of the design process. It’s why I advocate looking at building solutions or products as minimal viable products where you can ship something that meets the basic user needs quickly.
This enables you to test and learn at speed and tweak your solutions for a final product.
Happy problem-solving!
Before you go… 👋
If you like my writing and think “Hey, I’d like to hear more of what this guy has to say” then you’re in luck.
You can join me every Tuesday morning for more tools, templates and insights for the modern L&D pro in my weekly newsletter.
