Staying in the problem Space
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
― Albert Einstein
“I want people to be Solution Oriented!”. “Come with solutions, not problems!” How often have you heard those adages and axioms repeated ad nauseum by your boss or your CEO when they’re trying to inspire others to take action or be creative. Have you noticed how often that you hear that same repeated words a couple months down the line about the same problem?
When we are asking people to think about solutioning, we often might forget or miss what problem we’re trying to solve. It is a natural tendency to want to move along and create a quick action/resolution because many work cultures have bred us to want to show immediate results. However, by moving too quickly out of (or not even entering into) the problem space, there is a higher chance that the solution created in time is not addressing the right problem. Staying in the problem space is an iterative process that allows you to collaboratively work through a process to discover and surface opportunities ( pain points, needs, and desires), while not just addressing the symptoms.
If we think of designers/ organizational development professionals as doctors for organizations, wouldn’t it make sense that we are getting down to the root cause of organizational ineffectiveness? Particularly with complex problem spaces, staying in the mindset of discovering those new opportunities, allows people to take a complex problem, and dissect it to smaller digestible chunks and opportunities. It allows us to think more creatively and avoid groupthink.
I’ll end with this question “How do you eat an elephant?”. One bite at a time. By staying in the problem space and iteratively thinking through the opportunities, you can come with solutions that are addressing the overall problem. Perhaps, we should “Come with the problem space, not solutions.”
Using Theory as Inspiration
As students of design thinking theory and human capital models, we immerse ourselves in many theoretical models of change, organizational design, reflection. Our Masters program builds on the foundation of community learning, where the instructors and students learn from and teach each other. We accumulate knowledge over time and then we are continually reflecting on what we learn through learning out loud, and engaging with our classmates to see how we might adapt our thinking.
When developing new solutions, we constantly refer back to the theories we learn. That theory is the bedrock of our knowledge, and we as designers customize and adapt what best works for our organizations or clients. What we add/customize becomes a part of our ever growing toolkit. One of the first classes I took was 430-Creating and Sharing Knowledge, and one of the key concepts we took in was the idea of a Community of Practice. This community is a group of practitioners constantly reshaping and retooling their human capital practice and knowledge. The community of practice sustains by continuing to attract new people. What new members we bring is our experience with the application of theory and our community of practice aims to learn how others use theory in their organization.
While I understand people’s hesitancy to want to jump to theory as the start of solutions, for not wanting to sound too academic or science based, but most organizational effectiveness solutions have roots in some level of theory, even if they don’t necessarily mention it specifically. What successful organizational practitioners do is that they take time to adapt what they have learned from others into what works for their specific context or situation. And they will always look back to learn from and give back to their community.
Developing Empathy for users
It’s not ‘us versus them’ or even ‘us on behalf of them.’ For a design thinker it has to be ‘us with them’”
– Tim Brown, CEO and President of IDEO
Empathy is at the heart of Human-centered design. For a reminder of what empathy is, watch this short, enjoyable video (brought to you by the letter E). As mentioned in this IDEO blog: “Without the understanding of what others see, feel, and experience, design is a pointless task.” While the design thinking process inherently focuses on the end user, having a human centered design is an overarching mindset to apply to the whole process.
When you are developing empathy with the users, you are continuously developing a deeper understanding of their needs, desires, pain points, instead of designing a process/solution and hoping that they will adopt it. When you look at the problem space through the user’s experience, that allows you to develop solutions that can help “hack” at the specific opportunities through insightful problem-solving. Taking their needs into account as you design and prototype solutions, allows you to share back out with them for feedback as you are tinkering and testing. When you are experiencing work the way they do, you will be able to focus your solutions on solving the problem space as pertains to them.
A design process that does not have an empathy led/ human centered design approach can be less sustainable in the long run. Developing empathy is a mental model that a designer must manage to either build on or change their way of thinking. For me, my mental model was always to build solutions based on assumptions and archetypes, because it was what I viewed to be more expeditious. In retrospect for past projects, intentionally focusing on the end user, would have been the more expeditious choice, as my solution would have met the needs of the user and been more readily adopted during implementation.
Drawing/mapping your way to clarity
If you had told me before MSLOC that I would be spending a good portion of my grad school experience drawing and mapping, I would have shook my head and chuckled.
I’ve come from a corporate and consulting world, where the default mode was to take copious pages of notes full of words. We then would spend an immense amount of time trying to synthesize notes and pull out meaning from them, and create a story for a PowerPoint. I see drawing and mapping similar to the storyboarding that a TV/movie director would do. When a director storyboards, they are translating a detailed and complex script into a visual artifact. When I am drawing and mapping, I am distilling my notes into visuals to see if it makes sense.
Maybe you don’t see yourself as an MC Escher or Da Vinci (I am definitely not). Or, what could be hard for many designers is that they can see it as being too simplistic, since you’re just drawing on a page, and you can only fit so many things on one page. However, maybe that is the point, and a picture is worth a thousand words, right?!
First off, by synthesizing your information in another format, you then are able to mentally encode and see information in a completely different way by creating an additional artifact. Secondly, drawing and mapping allows you to distill specific moments in time, and allows you to look across multiple stories to find commonalities/themes. Finally, I also think of it as a mental reset that allows you to step back in order to step in. Zooming back out, before you zoom in again, allows you to re engage with the bigger picture and problem space.
Surfacing Assumptions underlying solution Options
“Your assumptions are your windows on the world. Scrub them off every once in a while, or the light won’t come in.”
― Isaac Asimov or Alan Alda
When we are designing solutions, we are typically thinking of a final product/process that we can implement. When you peel back the layers, a solution contains many smaller individual assumptions. Some assumptions are more important and more known than others. By rooting out the most important and unknown (aka riskiest) assumptions, we are creating a prioritization process to figure out what assumptions we need more information on before we proceed. Testing those most unknown and important assumptions, is a way to figure out if the minimal viable product will work. The more we prototype the more we know about the assumptions. By removing the unknown about the assumptions, we are mitigating the risk of the solution, before we fully implement/develop.
I suspect, knowing my challenges with understanding this step, that many other practitioners might also struggle about 1) Wanting to test Everything and 2) Being clear about what assumptions they’re testing. At first, it can be a little illogical to think about how you can test a solution before you have a full solution or prototype to test. (I guess that would be the proverbial elephant in the room). Taking the “eating the elephant” analogy from earlier, what I like about surfacing assumptions is that breaking down the solution to more manageable chunks and testing bits and parts of it. If you have ever seen a tech implementation go awry, some of it likely is that an organization didn’t test some of the most important assumptions about the solution. Solutions can and will be complex by nature, and the way to simplify it is to boil it down to its most simple elements. Testing assumptions allows an organization to course correct before it’s too late when we’ve wasted time and resources.
Creating Solutions that incorporate the unique context of the organization
The idea of a “one-size fits all approach” just doesn’t work anymore. Organizations, even if they are in the same industries, may have different purposes, cultures, and opportunities and processes. Yet, how often do you hear about organizations that adopt an idea merely because their competitor or another organization did? While the surface level problems might seem the same, there is a fallacy to follow that easy path without assessing what the specific organization opportunities are.
You can mitigate that fallacy by continuing to stay in the problem space and developing empathy for your users. For our remote working DOEC team, we collected the work stories from many people who didn’t work in the same organization. As we went through the process of testing our prototypes, we were testing to see if the assumptions we surfaced would be applicable to mostly different organizations. This issue highlights that as practitioners, when we are designing our solutions, we have to always think back to the specific user/organization that we are designing for, and think if the solution solves for the specific organizational needs/challenges. This issue you need to look at whether you are implementing a completely de novo/unique solution, or an out of the box solution. The reality may say that you have to go with the simpler out-of box solution. There is nothing wrong with using an out of the box solution, as long as you’ve determined that the solution solves for what that organization needs. If it doesn’t, look at a la carte add-ons that can help supplement, if it doesn’t address some organizational need. In the end, your solutions will be significantly more impactful and sustainable, if the solutions are a co-creation of you, as the designer, and your end users.
Eric Wu's MSLOC DOEC Digital Learning Portfolio 