From systems thinking to systems doing

A primer to apply Systems Thinking in Product Design

Arturo Ríos

Published in

UX Collective

6 min readSep 20, 2021

Example of Narrative Object Model, a systems thinking tool — Example of a Narrative Object Model, a systems thinking tool. Source

A product team is struggling to improve the engagement metrics of their mobile app.

Last year, they released an onboarding UX to educate users on how to perform essential tasks within the app, but they’re dealing now with low engagement on both the onboarding and core features.

Besides, they now have to work with the dedicated onboarding team, causing more triangulation, as every time a product team releases a feature the onboarding team needs to figure out a way to include it on the flow (not to mention that onboarding is rarely a good solution).

How to move forward?

The product manager is betting strong on A/B testing the steps of the onboarding.

The engineer is advocating for creating an algorithm that customizes the onboarding steps based on user cohorts.

Visual designers think micro-interactions will solve the problem.

Taylor, a product designer and systems thinking enthusiast, recently joined the company. Taylor proposes not to solve the onboarding problem, but to dissolve it.

By conducting fishbone analysis, Taylor and company identified the pain points about learning to use the app. Taylor then mapped mental models and conducted usability tests on the new conceptual models the team designed.

A few development cycles and the experiments are shipped, one at a time.

After moving the engagement needle, they decided to get rid of the onboarding flow, making the app simpler.

This writing is not only about what does systems thinking mean, but what can we do to apply it on our design work.

Speaking a shared language: the language of systems

If you’re working on the experience of a digital product, then you have a systems’ problem.

If you’re working at a company with different teams, then you deal with systems’ problems.

If you’re working on service design, then you deal with a (quite complex) systems’ problem.

Approaching a problem from a Systems Thinking perspective means acknowledging that complex systems are interconnected, and every change or impact on any part will likely affect the system as a whole.

Systems Thinking Axioms

When learning a new skill, the first step is becoming literate at it –understanding the language.

Following are a set of Systems Thinking axioms to better understand the way complex systems behave and respond.

A system is never the sum of its parts; it’s the product of their interaction

As Russell L. Ackoff stated:

The performance of a system depends on how the parts fit, not how they act taken separately

As designers, our responsibility lies in making decisions about the user experience. Every time we’re working on defining the way a system delivers an experience, we should be mindful of (but not limited to):

Entry points: How will users access the product?
Actions: What activities will users be able to do? Creation, edition, deletion
Data: How will new users input their data? What about existing data?

A complex system that works is invariably found to have evolved from a simple system that worked

This premise predates Lean Startup and the Theory of Disruption, and still holds true. For Product Design, a key yet hard skill to learn is drawing the line between what’s minimum and what is actually viable to build. As David J. Bland describes on his article:

The second hardest thing about Minimum Viable Products is that while you decide what’s Minimum, the customer determines if it is Viable

When you learn to deconstruct complex systems and ruthlessly prioritize what is important to deliver first–the simple system–, then you become a trustworthy ally for your business and tech partners.

The system always kicks back

Complex systems exhibit unexpected behavior. It is almost as they would have their own will, and that will is not friendly with changes.

Design systems, for example, might require more people to maintain them than the people needed to create them in the first place. Given how they grow in complexity, the more robust they become, they also become more brittle and inflexible. They kick back.

It is important as systems designers to be mindful of how a system could kick back after making a change or even attempt to make it.

A whole talk about the willingness of design systems to fight back

From Thinking to Doing

How can designers be fluent in systems and apply the theory to our day-to-day job? Following are some mindsets and tools I’ve collected to tame the inherent complexity of systems so we can play by their rules.

Draw models

It is well known that all models are wrong, but some are useful. There are 3 useful types of models designers can map out with their teams to spark conversations about systems’ complexity.

Mental models: These models represent the way your users understand the world–how things work. Mapping these models can better help your team identify the expectations of users and what they’re familiar with. Mental modeling by Indie Young or task analysis are great ways to craft them.
Conceptual models: These are the models teams envision about how the experience will unfold– the future state (also known as to-be scenario). It is important to address the knowledge gap that exists between a mental model and a conceptual model. The more separate these two are, the more difficult for a user will be to learn how to use the system.

The knowledge gap is the path from mental models to conceptual models. Source

System models: These models are depictions of the way a system is laid out. Class Diagrams and Entity Relationship Diagrams are clear examples. However, I have found Narrative Object Models to be more eloquent at showcasing the intricacies of a system in a more relatable way (thanks Cristina Vasquez for pointing me to them).

Don’t solve problems. Dissolve them

We learned at the beginning about the value of dissolving versus solving problems.

A common mistake product teams make is trying to fix problems by adding more features. Shipping more does not mean adding more value. As stated before, systems will always kick back.

John Gall couldn’t express it better on his book Systemantics:

When a system is set up to accomplish a goal, a new entity has come into being — the system itself

Systems designers break down problems to identify how to render them obsolete, instead of adding more functionality that will create more problems in the future.

A great way to deconstruct problems is NOT using 5 why’s. If the answer to the first why is wrong, then you’re setting up to fail. Instead, I’ve learned pre-mortems and fishbone analysis are more useful activities to identify root causes, so the teams can ideate about how to dissolve them before jumping into “let’s build this on top of it” mode.

Image of Jared Spool explaining Fishbone analysis — Jared Spool discussing fishbone analysis. Source: Tina Lee

Other Tools

Modeling and dissolving are 2 ways to embrace systems thinking. There are other frameworks and activities that systems designers can take advantage. These are some of them:

Eventstorming: A workshop to understand the big picture of an application based on the events the software produces, so the team can identify relationships and bottlenecks.
Cynefin: A decision-making framework that allows teams to better understand the space they are in and the type of problems they’re dealing with: simple, complicated, complex, or chaotic (thanks Chris Donnelly for sharing this tool with me).

Takeaways

Systems thinking can feel like a buzzword or smoke and mirrors, but when effectively understood and applied, it can unlock the potential of teams to tame the complexity of the products they work on, to avoid Experience rot, technical debt, and more importantly, frustrated customers.