Use systems thinking to make better product design decisions

I spent the past week reading "Thinking in Systems: A Primer" by Donella Meadows. It is an introduction to systems thinking that explores how interconnected elements within a system affect a wide range of issues beyond digital products, such as government, war, and poverty. The following are the highlights I noted down from it.

Simply put, systems thinking is the approach of looking at a product not as an isolated object but as an interconnected set of elements. This is how Donella defines it:

"A system is an interconnected set of elements coherently organized to achieve a function or purpose."

Goals and measurements ultimately shape the product's behaviour. We should be careful when we set them and make sure we follow them correctly.

System purpose: Always align the design with the system's purpose. If an app claims its purpose is "community" but its behavior only rewards individual vanity metrics (like likes or followers), the true system purpose is status-seeking.

With any new changes you make to the product (be it a new feature or changing a current one), ensure it's consistent with the system's purpose.

Measuring success (don't seek the wrong goal): Your product will optimize for exactly what you measure. If you define success by "time spent" or "number of clicks," you will build bloated features. Specify indicators that reflect the real welfare and true success of the user.

Metrics as a "Geiger counter": Do not let easily quantifiable metrics dictate your entire design. As a systems-thinking designer, your role is to be a "Geiger counter" for quality, advocating for the unquantifiable things like trust and delight.

Stock: A stock is a store or quantity of something. Think of the water sitting in a bathtub, the money currently in your bank account, or the total number of active users on your app.

Flows: A flow is the filling or draining of a stock. Think of the water pouring out of the faucet (inflow) and going down the drain (outflow), money deposited and withdrawn, or users signing up and canceling their accounts.

Boundaries: A boundary is an imaginary line we draw around a system to make it small enough to understand. Where we choose to draw that line simply depends on the specific questions we are trying to ask or the problem we are trying to solve.

A "stock" of users can be increased just as effectively by decreasing its outflow rate (churn) as by increasing its inflow rate (acquisition).

If a renewable resource is driven below a critical threshold, it effectively becomes nonrenewable and collapses. For example, if you spam users with ads, their goodwill and attention become a non-renewable resource that eventually gets depleted.

When you force users into strict rules (e.g., mandatory onboarding), they will "rule beat" by providing fake data or skipping steps. Treat rule beating as useful feedback; it means your UI is fighting the user's natural intent. Redesign the flow to align with that intent rather than tightening validation rules.

The three core characteristics of a functional system and how they apply to product architecture.

Resilience: The ability to bounce back after being pressed, stretched, or shocked. We make products brittle by ignoring "unhappy paths." A resilient product has overlapping safety nets, such as clear error states, graceful degradation during outages, and robust "undo" functions.

These safety nets should not be an afterthought; they should be a core part of the product.

Self-Organization: Instead of hard-coding every possible user path, provide flexible building blocks (e.g., tagging systems, modular dashboard widgets, open APIs). Trying to over-control the user experience can kill the experimentation required for creative behaviour.

Hierarchy: As systems increase in complexity, they naturally form hierarchies or subsystems inside larger subsystems (e.g., cells into organs, organs into a body). Hierarchies are efficient because they reduce the amount of information any single part of the system has to track, effectively reducing cognitive load.

Tip: A system breaks down when a subsystem prioritizes its own local goals over the goals of the entire system (e.g., the ads team ruining the core user experience to hit their click targets).

Low leverage (numbers and structure): Most of our political and societal energy is spent arguing over numbers, but tweaking them rarely changes how the system fundamentally behaves.

E.g: the Hungarian road system was built so that all cross-country traffic had to pass through central Budapest, guaranteeing air pollution and traffic jams that cannot be easily fixed by tweaking speed limits.

Or, spending more on police doesn't magically make crime disappear.

Tweaking UI parameters or physical structures rarely changes how the system fundamentally behaves (e.g., changing button colors does not fix a broken core workflow).

Medium leverage (Delays and feedback loops): You gain more power when you start altering how the system responds to change.

If a system responds too slowly, it oscillates wildly. For instance, it takes years to build an electric power plant, but demand changes quickly. Because of this long construction delay, almost every electricity industry in the world suffers from long cycles of overcapacity and brownouts.

e.g: Uber uses past data to send drivers to busy areas before the rush hits, while a built-in dampener slowly lowers the surge pricing instead of letting it drop off a cliff.

High Leverage (Information Flows and Rules): You can drastically change a system by changing who gets what information. In a Dutch housing study, moving electric meters from basements to highly visible front halls reduced electricity usage by 30%. What hidden information can you make visible to your users?

Delivering feedback to a place where it wasn't going before is incredibly powerful.

Ultimate Leverage (Paradigms): These are the deeply shared, unspoken assumptions and beliefs. Changing the paradigm changes the entire purpose of the system.

Apple Music shifted the product paradigm by redefining digital music from something to be owned into something to be accessed. Instead of designing an interface for buying and storing individual tracks, the system pivoted to algorithmic discovery.

We should find ways to put ourselves in the user's shoes, and not work isolated by other areas of the product. A true systems thinking mindset can be achieved if you have a good holistic idea of the full system; how it works interconnected with each part and how it will be used by the end user.

Intrinsic Responsibility: You and your team must "dogfood" (use) your own product. If a workflow is frustrating, you should be the one suffering through it to truly understand the user's pain.

Defy Disciplines: You cannot understand the full user experience if you only talk to other designers. The user's journey crosses through marketing, sales, customer support, and engineering. To truly design a holistic system, you must "defy the disciplines" and collaborate deeply with these other departments, stripping away jargon to solve the actual problems your users face.