Design Thinking.
I use this design thinking framework for every new project I work on, every stage of the process can be re-visited dependant on findings throughout the project.
Empathise.
Understand the problem you are trying to solve
Kicking off:
Understand the brief
Get yourself into the mindset of the user
Who is using this?
What is the intent of the user?
What are they trying to do with this thing or problem you are interpreting?
What is the business intent
Is it clear what this is solving
Is this designed to achieve a certain aim for the business
is there customer value attached or do we need to design something to achieve a business aim but make the user want to do it
Do we know enough about the behaviour we are trying to achieve or how we can measure success in this design
Gather information:
What are we doing currently (if it exists)
Look for information on performance of this
Do we have any relatable customer verbatim or testing insights
On the current
Or on something that users are asking for
Or something else related that could become a part of the solution
Do we need to test the existing piece or competitors who may do a similar thing - do we know enough to identify just through feedback what the problems may be.
What are others in the same space or elsewhere doing
Run the customer experience:
Journey map the current experience based on the defined users and intents you looked into.
Look at specific points around pain, frustration, a lack of features a customer might want
What is the user saying thinking or feeling at various stages of the journey.
Relate this back to the frustrations you can identify in research.
Define.
Formalise the problem you have identified
Analyse:
What is our research telling us
What is the journey mapping telling us
Where do we think a problem/s may lie
Look for themes to help with this
Can we prioritise the key intents and actions a user is after
Form problem statements:
Take our perceived problems and wrap them into human centered statements.
bare in mind the business reason alongside this but this isn't a problem
the problem statement should help to solve the business problem by user action
How might we's can help with forming these.
it's worth including business outcomes alongside these, they don't form the way a customer thinks.
your customer for example is not saying "I really want to receive more emails selling me something" but they might be saying "I wish I received reminders of offers on the products I buy a lot"
Our problem statement should be something we can hold at the top of every piece of work and question it.
Include some OKR's or tracking metrics with this too. How can I prove that by doing this or encouraging this behaviour I have achieved an aim or business request.
Guardrails & Watchouts:
Is there anything we should be aware of before ideating.
Do we have technical constraints
Time pressure?
Reliances on other systems
Whilst these can stifle creativity if you are working on the near or now then we may need some guardrails to focus our ideation.
We might need to go back to the empathise stage with a technical team to understand more about the system behind a solution to help us design.
Ideate.
Work through solutions to the problem
Idea Storm
Start throwing ideas down into a board in word form
group them by themes
Attach hypothesis to these
Why would this be better…
Go back to the problem statement
I believe this will achieve this aim because…
Do we have enough ideas that we are confident in?
Flow the journey:
Pick more than 1 concept
What is the journey for the customer
Compare this to our as is
Does this address our identified pain points
Identify those which look promising to ideate further
Scamp, sketch & write:
Mobilise ideas quickly
Sketch & scamp them
Wireframes mean more than full visuals
Skeleton frameworks can help identify hierarchy and understanding
Words can mean more than visuals as well - our solution may be more strategic than a full visual, maybe we are just changing one small aspect of the experience than the whole piece.
Include everyone in this process:
Before working up full visuals, prototypes or detailed flows talk to my team
Especially if I have unknowns
Really useful to identify if a solution is a go-er before touching a customer. Capability wise it may not be possible yet.
Lean and fast - reduce overhead on designing multiple variants of something and then showcasing.
Prototype.
Realise your solution/s
Analyse:
Prototype with research in mind:
Start by engaging with UX Research teams to understand how we may need to test this.
Do we need something clickable or just checking that the structure works
By working with UXR we may find we don't need a visual designed to test the concept
Prototype right:
Develop prototype at the right level of fidelity for the need
Stark wireframes might be enough to validate
Enough to validate the experience
validation may include prototyping to speak with devs / business teams about capability
Enough functionality to test fully.
Click through prototype might be enough for a concept.
If we want to truly test usability and keep the user believing they are in a real experience then usable forms and multiple routes can keep the illusion.
Test.
Validate & learn on your solution
Key outcomes:
Work with UXR before the test to establish what it is we are trying to find out or validate.
Our problem statement should help with this
Recommendations & next steps:
Each test should end with recommendations from user researcher - be that continue with the current path. Switch completely or tweak this to achieve our aim.
Use the test to understand where to go next
Look back on our problem statement and key outcomes
Is it meeting the expectation for the user and business
Is this enough for an MVP or does it need further work