As designers, we’re taught to take a human-centered approach to solving problems. This means spending time gaining perspective on a new project in order to empathize with our audience and deliver a successful solution. When you’re in a room full of like minded creatives this human-centered approach comes naturally, but it gets tricky in the real world when you’re working with stakeholders throughout a company. At Sharethrough the design team has cultivated a method of working that promotes design thinking by treating each new request as a small piece of a much larger story. By helping stakeholders tell these stories, we can better define the problem and implement a solution.
Storytelling is a difficult skill. To be effective at it you must be knowledgeable about your subject matter and cognizant of your information hierarchy, clearly defining a situation and the way in which your narrative plays a part. Luckily, Barbara Minto developed an easy framework for telling a compelling story that makes your points easy to grasp. The foundation of her Minto Pyramid Principle is SCQA, or Situation, Complication, Question, and Answer. Beginning a story with these steps concisely lays out your argument in a way that focuses solely on your solution, and with that groundwork laid, the bulk of your story can be structured around arguments and evidence that supports your answer. For an analytical audience this is the best way to frame a story, as all your effort is put behind enforcing your hypothesis.
The design team at Sharethrough has adopted the SCQA method as a way to prompt internal stakeholders to better tell their stories and help us guide the narrator through telling them. Having the stakeholder explain the situation will provide context, the complication details the problem, the question asks how to solve the problem, and the answer states your hypothesis.
Often, a request that comes into us begins with a brief explanation of what’s wrong and a description of how to solve it. The requestor has thought about their problem and decided design could help implement their solution. But this gives the design team no information about the situation or why this solution makes sense. We’re missing parts of the story and therefore unable to provide meaningful insight or deliver real benefit.
The process starts by defining the situation that surrounds a request in an effort to understand the full story. Our team has been able to do this by taking a step back from the problem and walking through the situation with the stakeholders. Asking questions to find the surrounding context, understanding the things stakeholders take for granted, and getting a full explanation of assumptions. A clear story begins with an outline of the situation as a foundation, and moves forward from there.
We arrive at the complication naturally, through the course of explaining the situation. Working together with the stakeholders, and with all our new contextual knowledge, we’re often able to redefine the problem in a meaningful way that centers more around people and behavior, and less on prescriptive creation. Having a solid problem statement is critical to discovering an impactful solution that has real benefits, and ensures our attention and energy is focused in the right place.
The question arises as a direct outcome of the complication that’s been defined. It always asks: how can this problem be solved?
Naturally, the answer is generated in response to the question. Because we’ve nailed down a solid problem statement and have taken the time to understand the context surrounding the situation, we’re in an ideal place to start generating solutions in response to our question. On a small scale this means independently generating ideas and working through sketches. For larger problems that have widespread impact, our team will brainstorm together with the stakeholders, talk through our ideas, and choose one to move forward with.
The output here will be a quick prototype to test our chosen solution. This could be in the form of wireframes, sketches or a clickable mock — anything to get the point across and start validating our assumptions. This is where we pick-up with the traditional design process, iterating on our ideas with reaction from user tests or interviews, or from simply seeing the solution laid out in front of us. Along with direct feedback from the stakeholders, iterating on this process delivers our final product.
Prompting stakeholders to approach their problems as a story has been a great way for our design team to gain quick access to situational context and generate a solid problem statement. It forces us to use a design thinking approach, define problems around behavior or actions, and deliver human-centric solutions that solve pressing problems.