You’re Sitting on a Gold Mine!
INTRO TO THE DEFINE PHASE
If you’re like many innovators & problem solvers (myself included) you get a great deal of enjoyment out of deciding what to do about the problem (also known as ideating, brainstorming, etc.) and then bringing it to life (prototyping and testing). At this stage in the Systems Design Thinking process you’ve defined a Challenge and you’ve Empathized with folks related to your challenge. You may feel like you have a good grasp on the needs related to a potential solution; you may have an idea for a solution. It is very tempting to jump straight to idea generation and prototype building. What if, though, you still don’t truly understand the nuances of your challenge? Will you build something that your potential end users actually want? What if I told you that you’re sitting on a gold mine but to unearth riches you must do some digging? The gold mine is your empathy work, in its raw form. There is work to be done to extract valuable insights and the true essence of your challenge from each empathy session. This is the Define phase of Systems Design Thinking.
If you need to catch up please review the previous blogs which introduced the Systems Design Thinking method, how to define an ambitious yet tenable Challenge statement and how to Empathize with those related to your challenge so you may understand their perspectives more so than your own.
The Define phase of Systems Design Thinking entails a fair bit of work - very valuable work. It can be broken into two sub-phases: Define I & Define II. At the end of the Define phase you will have a very clear understanding of the true nature of the problem core to your Challenge. You will define what a future solution must DO in order to address the problem you now fully understand, without defining what the actual solution IS. Defining what the solution is occurs in the next phase - Ideation - and is refined through testing and iteration.
Without further ado, let’s jump in.
DEFINE I (UNPACKING)
Define I can also be referred to as “unpacking” empathy sessions in order to generate “emotional data.” These data are the gold ore from our analogy. They will be analyzed (refined) during Define II to create the outputs of high value that set the direction, focus and tone for your project.
If you recall, there are three ways to empathize with potential end users: immerse, engage & observe. Unpacking each type has slight variations, but the goal is the same: identify the driving user needs along with notable insights or observed surprises for each empathy event. Let’s break these three emotional data types down:
Needs - as you would think, these are basic or higher level needs expressed by the people you empathize with. To commonize the vocabulary used by you and your team, you may want to refer to a standard set of needs such as those published by the CNVC. In Systems Design Thinking, Needs are to be expressed as verbs. You may see the need for “food” in a standard inventory. Instead, identify the need as “to have food” or “to enjoy food.”
Insights - these are inferred by your own empathic understanding of the empathy subject.
Surprises - like with Insights, these are not directly expressed Needs but can emerge from your own empathic clues and, as suggested, are contrary to how you expected an empathy session to unfold.
As you identify emotional data, be on the lookout for particularly interesting, odd or “juicy” details, as our instructor Sirietta Simoncini calls them. These data can provide valuable insights for the sheer fact that they make you consider something previously unknown.
Another important aspect of unpacking in Define I is noting relationships that emerge amongst the emotional data (Needs, Insights & Surprises). Systems Design Thinking defines the following relationships that help gain further understanding of the empathy session:
Tension - for example, when someone says they want to do something, but lacks the time, resources, etc. This sets up a tension between need and means.
Contradiction - for example, when someone says they want or need something but their behavior suggests they do not, or any other obvious contradictory statement.
Consistency - when statements or actions are congruent.
Synergy - when expressed needs or actions can be combined to yield something greater.
Hmm… - these are head scratchers. You’re not quite sure how to classify these data, but they’ve piqued your interest. Intuitively you know there is something to discover and it will emerge as you progress through your work.
Now we’ve defined the basic elements of unpacking emotional data, here is how to unpack each of the three empathy event types. An important note, unpack EACH EVENT INDIVIDUALLY. Do not lump them together by type or any other pattern. Likewise, if you identify the same or similar needs, insights or surprises across multiple events, RECORD THEM EACH AND EVERY TIME. Identifying patterns and themes belongs to Define II as you analyze the emotional data. Now, in Define I, you want to generate emotional data and it is helpful to repeat similar data. It actually facilitates the identification of patterns and themes in Define II.
Immerse
Immersion Unpacking Template
Reuse the picture or sketch (if you have one) from the Immersion event. Refer to your notes and capture the emotions you recorded during the event. Next identify Needs, Insights & Surprises. Use the color-coded Post-its (real or virtual) for each data type. Likewise, use the suggested colors to identify relationships amongst the data. You’re free to create your own colors or patterns, just be consistent across all your unpacking.
Engage
Engagement Unpacking Template
As with the Immersion unpacking, reuse your picture and notes from your Engage session. To unpack an engagement, capture what the empathy subject is Saying and Doing in the left two quadrants of the grid (shown above). The “Saying” and “Doing” quadrants are factual while the “Thinking” and “Feeling” quadrants often require your own empathic understanding. With the quadrants completed, now identify any relevant Needs, Insights and Surprises. Remember to draw emotional data relationship lines where appropriate.
Observe
Observation Packing Template
To unpack the final empathy type, Observe, it starts the same way as the previous two: reuse your picture / sketch and notes. In an Observation you do not actually interact with the empathy subject, therefore the only concrete data you have is what you watch the subject do. This is the “What?”. For “How?” you must infer what emotions may be present by observing the manner in which the subject does what they’re doing. Body language is often a good reflection of emotion. Use your empathic intuition here. Likewise, for the “Why?”, you want to ask yourself five times “Why is that?” to empathically discover underlying motivations, beliefs or emotions behind the behavior you’ve observed. From here you can identify the Needs, Insights and Surprises for this session, and don’t forget to draw relevant relationships amongst your data!
You can complete Define I in myriad ways (virtual whiteboard, modeling tool, physical whiteboard & post-it notes, etc.) but keep in mind that you will eventually need to digitize your unpacking efforts. Also keep in mind that unpacking can move very quickly. For these reasons we suggest performing Define I in a virtual whiteboard (as the example shows) - it allows you to move quickly, it’s automatically digitized and can later be transferred into a more permanent modeling tool.
Define I in a Virtual Whiteboard
DEFINE II
Themes & Sub-themes
If Define I is mining gold ore then Define II is refining it for high value use. There are several outputs of Define II. We’ll step through them one by one. The first is to identify Themes & Sub-themes implicit to the emotional data you discovered. At the end of this step, you’ll have an excellent understanding of what is truly driving your challenge.
The creation of Themes & Sub-themes can also be referred to as conducting affinity mapping. Other methods include rose, bud, thorn from design thinking and KJ Analysis from six-sigma methods. Regardless of what it’s called, the goal is the same: identify patterns in your fuzzy data that help you move in the direction of a concrete understanding of the user needs driving or underlying your challenge.
The process is straightforward, but it does take some time. The investment is well worth the effort and this stage is critical to developing a clear understanding of your challenge. We have personally witnessed “aha!” moments during this step that shape the direction of the project.
Here are the steps to identify Themes & Sub-themes:
Gather all the Needs, Insights & Surprises developed in Unpacking. If you’re using physical stickies take a picture of your unpacking boards for documentation. You may need to refer to them later. If you’re using a virtual whiteboard tool, copy and paste to create a new set of elements. The same reason applies, you may need to refer back to your unpacking. If you’re using a modeling tool (eg. SysML-based) create a new diagram for identifying themes and REUSE your need, insight & surprise elements. This is an advantage of modeling tools which we’ll discuss in a later post.
Identify Patterns in the Data. To minimize the impact of personal bias, do this together as a team. Or, if you’re using a virtual whiteboard or modeling tool, each team member can do this on their own and then reconcile everyone’s individual assessments into a final team output. Try to keep all Themes & Sub-themes to no more than three levels of granularity, that is for each Theme, have at most two Sub-themes. Likewise, it’s common for only a handful of Themes appear in the data. Too many Themes or too many Sub-themes can suggest a couple of things:
You’re approaching the data too literally. Allow adjacencies, similarities, contradictions and other insights to lead to pattern identification.
You don’t have enough data for themes to emerge. You may need to revisit your unpacking sessions to ensure you generated all relevant Needs, Insights and Surprises. You may also need to conduct additional Empathy fieldwork.
Draw Relationships Across Themes. Remember the emotional data relationship types (Tension, Contradiction, Consistency, Synergy & Hmmm…) from unpacking? Use those to understand how your newly developed Themes & Sub-themes are interrelated, providing additional insights to your data.
Like we said, it’s straightforward but do not rush this step. It can be helpful to work for a bit, step away and revisit. You may find that new patterns emerge, earlier themes may be renamed or shuffled, or they may be validated and built upon. You’ll find that your understanding becomes more clear as your Themes & Sub-themes become finalized.
Since your needs, insights and surprises were captured in a virtual whiteboard tool it’s most convenient to continue in this environment. Some virtual whiteboard tools are rolling out generative AI features that you can use for this work. In our experience they yield pretty generic, common place results. We recommend taking the time to go through all the data yourself, using your intuition and understanding. This is the best way to generate meaningful insights.
Themes & Sub-themes in a Virtual Whiteboard
Flow of Thoughts
After developing your themes & sub-themes, next create a verbal summary of your empathy fieldwork. This is important because, until now, the work of unpacking and identifying themes & sub-themes has been highly visual. Writing out a flow of thoughts helps you relay a verbal understanding of your work so far. The flow of thoughts, along with the themes & sub-themes, allow you to communicate a summary of your empathy work clearly and completely, both visually and verbally.
The Flow of Thoughts is also conveniently created in a virtual whiteboard. Again, some virtual whiteboard tools offer AI-generated content but it’s only going to summarize what it has to work with and will lack meaningful depth. Take the time and write these yourself. Remember, this work isn’t a check-the-box activity. You’re trying to develop true understanding, which can only occur if you’re the one actually doing the work!
Flow of Thoughts in a Virtual Whiteboard
You can certainly continue the final work items in a virtual whiteboard, but we’re going to switch gears and show them in a modeling tool. The primary reason is that traceability will become important moving forward. At some point in time someone will ask “how is this related to Persona A?” or “let’s remove Feature x, what all does that impact?” or “why did we make this decision?” and so forth. These questions are relatively easy to answer in the beginning, when a small team can get their heads around the entire solution. This won’t last long, though. Imagine months or years down the road when your solution has matured, team members have come and gone and a small group can no longer handle every aspect of the solution - this is where a model brings massive value.
Personas
Personas are also referred to as ideal customer profiles, customer avatars and various other phrases. Personas are fictitious characters that represent aspects of real folks you’ve encountered during your empathy work. You will give these characters backstories and link them to relevant themes, sub-themes and capabilities (developed next). Personas are for whom you will design a solution. This step is very powerful for it personalizes your efforts. It’s often easier, and more rewarding, to design for an individual (even if they’re fictitious) than for a set of abstract needs and requirement statements.
How Might We Capabilities
The How Might We statement is a concise definition of your project’s goal. This may be a refinement of your original challenge statement or it may be a completely new focus; it all depends on where your empathy work led you. Just like a challenge statement, the how might we statement must be bold and ambitious yet tenable. Capabilities are what your soon-to-be-identified solution must DO in order to enable the How Might We statement and satisfy the needs of your Personas. Once capabilities are defined they can be related to relevant Personas.
Persona Context
A simple diagram that defines relationships from Persona to Persona and from Persona to your eventual solution. This can also be referred to as stakeholder mapping. There are different methods used to create this diagram, regarding how to label the lines of interaction. We prefer to identify things of VALUE (time, money, resources, ease, comfort, etc.) that flow amongst the Personas and future system. In doing so, you enable this diagram to be analyzed which helps in prioritizing your efforts. We have some prior work demonstrating this method.
In the image that follows we show several diagrams: identification of personas, definition of the How Might We statement and system capabilities, the persona context diagram and a relationship map for a persona. The relationship map shows how easy it is, within a modeling tool, to start with a persona, and quickly navigate all the information related to them (needs, emotional data themes, system capabilities, etc.). You can imagine, as the solution matures and more “layers” are added such as solution elements, decisions related to those elements, risks, mitigations, test activities, etc. this map will allow you to quickly answer the questions listed above, no matter how complex your solution becomes.
Define II in a Modeling Tool
In creating the work products of the Define phase, you have fully defined the problem. You can communicate a clear and concise goal and capabilities for your eventual solution (backed by real-world data insights), you know for whom you’re designing and you know what values your solution will provide to those folks.
It may seem like you’ve done a ton of work and still don’t have a solution to show. Think of it this way: moving forward, every idea you have you can be confident that it is addressing an actual problem experienced by real people. You couldn’t be so confident if you rushed right into idea mode without understanding the true essence of the problem and those it impacts. You would’ve designed a solution based on your own assumptions and biases. All of this work in the Define phase will pay off; you’ll see as you use this knowledge in the next phase of Systems Design Thinking - Ideate - which we’ll cover next time.
Until then, and as always, please reach out if you have any questions or want to get started on your project. We’re happy to get you up and running!
If you’re itching to get going on your own project and can’t wait for our next blog, please reach out! We’re happy to help you get going as quickly as possible. And before you go, don’t forget to subscribe to our monthly newsletter (scroll to the bottom of this page) so we can let you know when the next blog is ready and keep you updated on all things Aureus.