This article draws on Diana Deibel’s recent conversation on Design Chats. She is the Chief Design Officer at Grand Studio and co-author of Conversations with Things.
Big ambiguous design problems are both exciting and daunting. On one hand, the possibilities are endless. There is no solution in mind—it’s pure exploration. On the other hand, it can be difficult to know where to start.
For example, I worked with a large healthcare institution in the U.S., and they were growing fast through acquisition. Hospitals work a bit like individual entities and do things their way because they need to serve their community, which makes sense. So, if you have more than one hospital under your umbrella, you have more than one way of doing something.
With all of the acquisitions, each of the locations in this hospital system were approaching the same work differently. The system wanted to make changes and streamline operations so that if someone walked into a hospital in Illinois and another hospital in Texas, the experience would be similar.
Here is the process we used to approach this big, ambiguous problem.
Step 1: Narrowing the Scope of a Design Problem
To start tackling this problem, we had to narrow the scope, and the organization settled on surgical scheduling. They knew they wanted to build the solution—not buy or partner. Those were the only two elements we knew going into this project.
Step 2: Discovery Work
After those initial conversations, we had to get on the ground and see what happened at these hospitals and uncover the actual problems that needed solving, not just what the stakeholders said needed to be solved.
While trying to understand the current process at these different locations, we talked to the surgical schedulers, surgeons, nurses and anybody that had a hand in the process, from getting the patient diagnosed to the patient going back home after the surgery.
We were trying to answer questions like “What are the pain points?” and “Who are the pain points for?”
To help communicate this web of what was not working, we created a service map to show problems that were happening, technologies that were being used and people who were involved. By understanding where the pain points were, we could focus on solving these key issues and significantly improve the surgical scheduling process.
Step 3: Stakeholder Mapping
As part of discovery, we often do stakeholder mapping.
You want to do stakeholder mapping for a number of reasons, including understanding what could impact your work, who you’ll need to involve to ensure all points are considered and so that the people affected by the design work don’t feel like you’re springing things on them and taking over workstreams they’ve previously been in charge of.
Because a project’s organizational and political elements can be one of the most challenging aspects to navigate, we can better plan and execute our project by understanding the stakeholders’ interests.
For example, there’s always someone funding the project, and they have a specific need in mind. But to solve that specific need successfully, you may have to coordinate with other stakeholders to move a project forward. This can be particularly difficult when competing interests exist or the large and complex project involves multiple departments or groups.
There are many different ways to approach stakeholder mapping. We usually start by mining the people that we’re working with to identify any potential stakeholders. Then, we reach out to those stakeholders to better understand their interests, how our project might impact them and find any other potential groups we may want to connect with.
Step 4: Communicating with Stakeholders
Getting back to the hospital project, after we’d gathered input on who should be involved and did our research to compile our service map, we brought the stakeholders into a share out to talk through what we’d learned and where we might go from here. To do this, we brought our service map and some concepts and sketches.
The sketch concepts outlined some directions we could go to solve the problems but kept the ideas at an intentionally low fidelity to ensure people felt like they could still change things. We’ve found that, overall, this approach helps with stakeholders who haven’t been involved in the design process before and with whom design artifacts may not resonate.
The clinicians we worked with in this project were, of course, used to running the hospital—that’s important. So the sketches helped ground the bigger ideas we were discussing. And our clinical stakeholders were able to respond to them in a way that allowed them to prioritize both the problems as well as the potential concepts.
As with most design work, the solution needed to work for the business overall while also solving the problems we saw at the specific locations where we were researching and we’d be piloting. Getting this kind of feedback was crucial to helping us collectively build a design brief that made sense.
It is important to bring the stakeholders along with specifics when the problems are so broad and ambiguous.
This is because it’s a big jump from “Here is the problem” to “Here is a specific solution.”
Some stakeholders are more open and willing to participate in the process actively. But some are either not interested or don’t have the bandwidth to participate. In this particular example, they were literally saving lives, so, fair enough that they didn’t have time to sit in on concepting sessions with us.
Still, it is essential to ensure that all voices are heard and that everyone understands the implications of the project. This will help to avoid any surprises or disagreements down the road and will help to ensure that everyone is working towards the same goal. Milestone checkpoints are incredibly useful to this end and help make sure the train doesn’t roll down the tracks too far without everyone being on board.
Step 5: Explaining the Problem in the Right Context
When you do have those critical checkpoints with stakeholders, it’s important to focus on honing the story and relating it to their problems and the things that matter to them.
Share some of the things you heard and how they relate to what you were asked to do. Remember that they may not be familiar with the research and context you have. It is essential to summarize the key findings in a way that is easy to understand while also conveying the importance of the information.
Along the way, you’ll probably need to share some things they may not know about, which will impact what they asked you to do. Sometimes these other things may feel like they are on a tangent, though they still impact the thing you are focused on. It’s important to connect the dots so people can understand why what you’re discussing matters to them
If you can, record the research through photos or video. Sharing documentation directly from research can impact how stakeholders understand the research, even if they aren’t actively present in the work.
Audio quotes are a great option if you want to avoid identifying a specific person but want the stakeholder to hear the emotion in the person’s voice. That can help bring people along and help them why you’re focusing on a particular problem, recommendation or concept.
By putting the findings into a human-centric context, we can help our stakeholders see the impact of our work. And when they provide feedback, it’s important to have empathy for their situations and knowledge, since often they can impact the end user’s experience too.
It also generally just doesn’t hurt to remember that we are all human and should treat everyone with respect to achieve our common goal of making things better.
Step 6: Designing Solutions Both for Now and Later
When we think about solutions, we look at every possibility: organizational design, service design, conversation design or digital solutions. Then we start looking at the solutions and identifying which problems they are solving and where there are overlaps.
We have a working group that we check in with once or twice a week, so we never work too far from the client, because we don’t want to surprise them with anything. That regular conversation also helps us understand the kind of solutions the organization can support.
For example, there might be an excellent digital solution, but it will take a year for them to implement it. In a case like that we’ll try to design a short-term solution for the immediate future while the longer-term solution is in the works.
Having this bend and flex between short-term fixes and long-term vision helps us create a roadmap of improvement that shores up the value of design across not just the group we’re working with but often across the organization. (And you know what that builds you, right? Supporters!)
In the case of the hospital system, we were able to churn out a quick small-scope digital tool for the short term while building out more robust features that were going to take a little longer. Going this route helped the folks on the ground get a solution more quickly, as well as helped the organization set up their design and product practice in a scalable way.
To connect with Diana and the Grand Studio team about this or other work they do, reach out to give them a shout.
Want to increase your strategic impact?
In Pragmatic Institute’s course Business Strategy and Design, you’ll learn how to contribute to strategy conversations, measure and communicate design’s impact, and how to navigate potential conflicts between the buyer, user and business goals.
