One way of making sense of your data is to share with your team the most inspiring stories you’ve heard from the people you’re designing for. Think about user stories or experiences that have stuck with you: stories which surprised you, made you curious, or verified or falsified your assumptions. Please note, it’s also important to look for stories which falsify your previous assumptions as you don’t want to risk moving forward just confirming your own wishes without really paying attention to your users’ core stories and needs. Stories will most likely not provide you with the ultimate solutions to your design challenge, but chances are they’ll resonate with your team. At the international design company IDEO, team members share inspiring stories with each other so that user stories become part of their collective consciousness.
The goal is to build a repository of stories for your team to draw from, tell, and retell. Capturing those resonant ideas and feelings, and building them into the very narrative of your team’s work helps everyone down the line.
Best Practice: Construct Your User Story Madlib
Try to tell the most essential stories and consider them to be a series of steps within a broader system.
- As a [who are they], he/she wants to [what do they want to do], so that [their end goal].
- Example: As a freelance consultant, Peter wants to easily schedule meetings, so that he can ensure his schedule is always organised and effective.
- Example: As a corporate web designer, Lisa wants to improve the company’s website, so that users can easily find and get access to what they need.
Problem & solution statements:
- Get the problem right
- Before you get the right design
That you have conducted all this research,
- What did we learn?
- What is the point of it all?
- How did we communicate this succinctly?
- Then….what do we do next
- The problem statement itself should refrain from being specific about what technology or software was used.
- Try to identify whether the issue is to do with the people involved, or the way they are currently doing things. If it’s to do with the users and their processes, not technology will fix that core problem.
- Based on your research you should be able to see most likely problem trend you are intending on solving
- Sometimes it’s not just about problems, it can be about opportunities.
- Depending on the maturity and confidence of our findings, you may insist on further investigation, iteratively, later on.
we are primarily focussed on the objective solution: the WHAT as opposed to the HOW.
- the solution statement itself should refain from being specific about what technology or software will be used.
- by not locking out statement to a specific device or platform, this helps keeps our mind open to innovate various solution implementations.
- Appreciating that problem & solution statements are meant to guid the research and design process, not restrict it.
- practice crafting statements to articulate the problem, and direction for the solution.
- try to understand the human situation, not the technology.