Systems thinkingis often heralded in different circles as a competency thats worth investing in.
Most product designers tend to default to design systems as a proxy for systems thinking.
The ecology around building design systemsdoesrequire maintainers to think systematically.
However, this doesnt mean that building a design system is the only natural outcome of thinking in systems.
Astronauts often recall the overwhelming experience they felt when looking at the fragile blue ball they called home.
Astronomy author Frank White called this experience,The Overview effect.
Designing software often requires us to situate ourselves at both a macro and micro level.
As a result, we risk becoming distracted with the details when we cant afford to do so.
We are surrounded by systems that weve directly or indirectly shaped or been a product of.
That being said weve done very little to represent any of them.
In other words, systems are messy.
Now trying to articulate all that through text isnt exactly the best way to explain whats actually going on.
Thats wheresystem diagrammingcan come in handy.
Below are a few examples.
This graph helps us see patterns and interrelationships that emerge over a specific period of time.
We can use it to observe how and why something is happening.
Lets use something were all too familiar with as an example product debt.
Quadrant matrix
This is another common diagram, that also has likely donned a few whiteboards.
It is mainly used to represent the strength of relationships between several different items.
Lets say youve finished up a moderated usability testing session and youve come away with a few insights.
Its not enough to swap things around, change information flow or incentives.
Youll need to expand the perception and shift mental models to have leverage and upend the system.
Lets take a real-world example of a product team thats trying to meet a deadline.
An event would be that the team doesnt ship in time.
The natural tendency is to be reactive and start to find people to blame.
Instead of playing the blame game start looking at the trends that might have led to this.
Reinforcing feedback loops
However intentional it might have been, youve probably designed a reinforcing feedback loop.
Unsurprisingly, reinforcing feedback loops are usedandabused.
The diagram above illustrates this example.
Both are examples of a balancing feedback loop.
There are usually things that happen in between or outside of the model that have an effect.
Our feedback loop is still looking a bit too convenient.
Lets introduce another component, such as an update to the EHR software.
That in itself might eat upsomeof that time the staff is saving since there might need to be retraining.
Thats called an external factor.
Gaps can also be another feature of causal feedback loops.
A gap can exist between the actual quality and the actions were taking to improve that quality.
These are just a select few of the tools available in your systems utility belt.
Needless to say, theres an abundance of other ways you could visualize systems.
Quite frankly, being able to produce these artifacts is a superpower.
That superpower, however, shouldnt go unchecked.
Systems can also be consciously designed to manipulate, cheat and sometimes even harm people.
Currently at Casumo, an online casino, building entertainment products that enable responsible play.
you’re free to read the original articlehere.
