Getting to the heart of the problem
When working with PO’s to help solve business and customer needs it’s important to get to the core of why you’ve been asked to design a solution. Unless you’re working for a company with high UX maturity, you will be familiar with being asked to mock up designs for a predefined solution.
So how do you make the shift from solution design to problem solving?
One of the tools I used when managing a team was to use a consistent template to document what we were being asked. I set this up on Jira so that whenever we created any new work for the UX team it was there ready to be filled out. It was very simple and only required a quick call to make sure we understood the bigger picture before taking on the work. It also meant that there was enough information that anybody could pick it up.
Here’s the template:
What
What is the high-level overview of what we’re being asked to do?
What’s the problem statement?
Who’s involved
Who’s on the team? POs, Dev, Analytics?, Research, Design, Marketing, legal and anybody else that will need to input to the outcome.
Why
This is the most important question and can take the most time to get to the bottom of it. I find using the “5 whys” format great for getting to the true reason we’re picking up this piece of work, especially if someone has come to you with a pre-defined solution. Is there some data highlighting the problem? Has this been informed by user research? Is there a legal need for it like GDPR?
I tend to break it down into three categories, why are we doing it:
For the customer
For the business
From a legal standpoint.
When
Do we need the solution by? It’s always good to know if there’s some time pressure to get this out, as this will impact the solution you design. You can also ask if there’s some wriggle room and negotiate for longer if you feel like there’s a high risk of getting the solution wrong.
How
Now that you understand the ask and the timeframes, how are you going to approach the problem? List out the methodologies while on the call and break them down into the double diamond.
Discover - Why does this problem exist? Is there any data or research that you can review or do you need to organise some? It’s great if the outcome of this stage is a list of HMWs.
Define - Are there any workshops that you need to organise so that you can collectively review the HMWs and refine the primary problem statement together? The outcome of this stage should be an agreed HMW.
Design - What steps will you go through to ideate and test low-fi solutions and who’s involved E.g. Crazy 8’s, usability testing? This is your chance to explore options and test which one works best. The outcome of this stage should be a validated concept.
Design Delivery - Refining your solution. Do you need to organise a design review? How needs to be there? PO’s? Stakeholders? UI or Design System rep? Devs? QA? The outcome of this stage could be a high-fidelity mock-up of the solution so that the dev team can easily pick it up. The level of UX maturity will influence the level of detail you will need to go into.
If you use any digital project management tools like Jira then this is a great way to keep everyone in the loop using comments and track all the working files through to delivery. It also means that when the devs pick up the work they will have easy access to the full context and documentation.
If you use this template then I’d love to hear how you found it. What worked well and what do you think needs improving?