“Understand”: Adding Systems Thinking to the Design Thinking Framework
How can Design Thinking evolve to be more effective and inclusive? Many DT practitioners are asking this question while looking to an uncertain future. Some have added “Implement” to the original DT framework, some are saying we need to add Inclusivity, and some are saying it’s simply time to move on. I believe the original DT framework is still compelling and can continue to provide value, but I do think it’s missing something: Systems Thinking.
I’m not at all the first person to suggest organizations can benefit from both Design Thinking and Systems Thinking. IDEO created a course on integrating the best of both worlds, while the d.school has created a Systems Thinking exercise for their DT resources. Both Systems Thinking and Design Thinking have been converging in different ways for a while now, mostly in recognition of the need for each other, and a few systems thinkers have even called this symbiosis the “Third Generation of Design.”
I love this convergent evolution! Having taught “Empathize-Define-Ideate-Prototype-Test” framework extensively, I’m still a fan of both its flexibility and relative ease of conveying different ways of working to cross-functional groups. This is why instead of treating them separately I like the approach of adding Systems Thinking into this framework.
Empathize-Define-Understand-Ideate-Prototype-Test
When facilitating DT exercises, I coach my teams to consider system complexity during Prototype and Test, guided by the questions “How can we uncover the most ‘unknown unknowns’ in the shortest amount of time?” and “Who should be included in test sampling to represent different stakeholder groups?” Watching the right people test an idea is the fastest way for product teams to counteract their implicit biases and realize hidden gotchas. But I’ve realized waiting til “Test” to uncover system complexity is often too late. We are too far down the solution path to radically change course.
“Understand” would be a new section focused on systems and would happen between the problem being identified in “Define” and concepts being generated in “Ideate”. Upon gaining empathy for an individual person (Empathize) and defining a problem space (Define) the team would zoom out and consider system context. What processes will a solution intersect? What non-intersecting processes will nonetheless affect a solution? What incentives in this system run perpendicular or parallel to this problem space? Who are the stakeholders whose actions will be required to impact this solution? It doesn’t have to be exhaustive, as this can be done at a high level and still help frame the problem space when teams enter Ideation.
Of course, this is when the framework is approached linearly. As any DT proponent knows, the components of the IDEO/d.school version were intended to work as standalone “mindfulnesses” as much as a linear innovation model. Sometimes you only need Empathize, and other times you only need to Prototype-Test. It’s all based on the current goal or objective. So sometimes you may only need a view into underlying causation. “Understand” would serve as an exercise to surface stakeholders, processes, or potential new problems that could arise from altering the current state. “Understand” could involve a stakeholder map, a simplified causal loop diagram, and a basic list of incentive structures that contribute to the problem space as it exists. I can see this as a helpful exercise to gut-check a new feature or initiative already in the works, or for senior leadership to gain quick insight on a thorny issue.
A helpful modification to the original d.school framework
Example 1: New Feature Gut-Check
When the business decides to build a product with a set list of features, they do so with the intent of certain positive outcomes. As a systems-thinking product manager or designer, you may find yourself receiving a list of requirements and become concerned one of the features will conflict with existing systems in a way that will undermine the success of the product. I once worked on a product setup feature that had no recovery model within it, meaning a person would have to start over from the beginning if the setup process failed at any point. While this was a core usability red flag, the dev team said that any change to the technology would put the entire project timeline at risk, which made any fix a seeming non-starter.
I asked the product team to map a light causal loop together. (I actually called it an experience map and a technology flow, but because we overlaid them to understand how they interacted, it was essentially a casual loop). We looked first at a diagram of the tech system to understand why the setup flow would have to restart rather than recover, and we realized the amount of complexity in the stack. We then created a diagram of the user flow that also included the outside factors that influenced user competency, and we realized the amount of complexity in their context. The entire team then understood that a balance would have to be achieved, and we found a way to allow people to recover in the middle of setup (UX concern) in a way that didn’t involve a fundamental change to the technology (Dev concern), which would keep the person on track to using the product (Business concern).
Often, a slight modification in how we design/build a feature is enough to counter this risk. Conducting an “Understand” session with the cross-functional team can give everyone a shared understanding of underlying issues due to competing forces that can be addressed during implementation.
Example 2: Thorny HR Issue
Much like working in the public sector, there are myriad complexities of human interaction when considering changes to workplace policy. I once worked with a human resources department on flexible work schedules for a group that was a traditional butts-in-the-seats approach to productivity. HR had wanted to simply change the rules to allow for more flexibility, but they knew a big change should be thoughtful and asked me to help them approach the problem with Design Thinking.
I advised as they interviewed teammates to help define what the new policy should be and helped plan a prototype/test approach once they’d ideated a set of guidelines. But in Systems Thinking style, we created a list of stakeholders and their associated goals and incentives before drafting the policy to test. To HR’s surprise they uncovered complexity in how teammates, managers, and executives thought about the concept of work flexibility. For example, they realized an adoption of the new approach would be thwarted by teammates’ hidden incentive to be seen working at their desks. As a result, executive and manager advocates were later included in the policy test as positive reinforcement.
“Understand” can help groups realize invisible forces at work and devise sometimes simple counters that help solutions succeed.
If It’s Broke, Fix It
It’s notable that the d.school, the ones responsible for the democritization (and marketing) of DT, no longer focus on the once-ubiquitous “Emapthize-Define-Design-Prototype-Test” in their resources. Perhaps that’s intentful evolution, perhaps it’s self-distancing from the framework’s publicized failures. Even if they’ve left it mostly behind, the core approach is still a valid and accessible summarization of a human-centered process, and there is value in evolving it to include the complexity of systems.
The need for human-centricity is as important as ever, and many companies are just now implementing their DT programs (with actual resources and head count!). Nothing is gained if we toss it aside in favor of the next shiny, consultant-hawked framework. Adding “Implement” predictably did nothing to increase the implementation of DT-generated concepts, and Inclusivity should just be part of our evolution of everything we do (not relegated to a specific DT step). “Understand” would be a concise integration of Systems Thinking that addresses the most common reason DT concepts don’t get used: their failure to consider the complexities of the systems in which they will live.
Out-of-the-box thinking is great, but only if we understand the complexity of the box.