System Thinking and UX part 2: System Traps how to avoid them

In the first part of this article on System Thinking, we started with a hypothesis that many projects become ‘addicted’ to ‘Surface Thinking’. It explored how often solutions where surface deep and did not examine the ‘messy middle’ to understand real needs. We then looked beyond the shores of User Experience to explore how understanding system thinking applies to Systems in general as well as designing digital experiences. In part two, we are going to look closer at how competent designers create poorly design systems. We also start to look at how System Thinking is an alternative way to look at the systems we design.

So what is System Thinking, in detail, and how does it relate to UX? To give a complete detailed answer would take a book, one with a lot more examples of real-world UX projects comparing results of System and Surface approaches.

This article is based on ‘Thinking in Systems’ by Donella Meadows. The book includes many instrumental lessons in systems applicable to UX. I’ll shine a light on two areas of the book. The concept of System Traps and some maxims of advice Meadows provides for those designing systems.

System Traps

The concept of system traps is especially useful when looking at how Surface Thinking is useful. Meadows explains in the book why good people create bad systems unintentionally. These ‘System Traps’ described in the book are ‘Archetypal problem-generating structures’. The traps result in unintended outcomes which are hard to trace. The effects are often far from trivial. It can lead to needless spending by government departments, incorrect blame placing and ineffective interventions. ‘Obvious’ solutions can have unexpected effects.

In the talk I gave at Euro IA in 2014, I focused on two of the eight traps from in ‘Thinking in Systems’:

Seeking the Wrong Goal

A core system trap. To understand this, I’ll revisit part of the definition of a system.

“The least obvious part of a system, it’s function and purpose, is often the most critical determinant of the systems behaviour.”

The ideal project will start with clear documentation of how the existing system behaves and a clear goal for the future. It will include details of customer behaviour, how the company is organised to achieve the desired result and all the nuance needed to fine-tune the design of a system. Reality is rarely ideal.

As UX designers, we need to look beyond requirements and at the needs of the user. We do this understand the problem so we can better understand the desired outcomes.

The quality of the goals for a project completely changes the direction of a project. The concept of ‘Do then ask for forgiveness later’ becomes the primary way things get done or the goal of a project is something that does not lead the system in the right place.

Here’s a real example. It is 1997 and a well-known technology set up a web team. The teams ‘goal’ was to publish as many pages that were on-brand as possible. The result for this chip-making company was a site was a sprawling mess with thousands of near-identical looking pages. Site stats showed budgets where being blown creating sections with next to no traffic. It was cheaper to give away products in many cases.

That team had goals that lead to an adverse outcome. Meadows provides some other examples. For instance, Gross National Product (GNP) as a goal does not lead to a growing economy. The amount spent on the military does not equate to national security. Taking money from crucial parts of a budget may be undermined Security in unforeseen ways. A sound education system is shown to lead to less crime which increases national security, for example. Imagine if the desired system state is to provide an excellent education. If it decided that that spend more on each student is the goal, then the result is a system where more spending per student, not that education improves. If the goal is a high pass on a standardised test, then the system will produce students that are good at standardised tests. The goal changes the way the system works, so goals matter and how they are measured matter. Or, to put it another way, we should be careful what we wish for — we might just get what you want!

In other cases, the goal is clear, but the solution is short term, which is the next System Trap.

Shifting the Burden to the Intervenor — Addiction

This trap is about the reliance on interventions to make a system reach its desired state as measured by the system goals. An intervention is a short term fix and is, in my view, equitable to Surface Thinking. In System Thinking, there is another word associated with the over-reliance on interventions to reach goals, and that is Addiction.

Addiction is most easily understood when we talk about drug addiction or addiction to gambling, computer games or Facebook. The concept of addiction also applies to systems large and small. An industry may become addicted to a government subsidy, or farmers may become reliant upon fertilisers to make their land fertile instead of using crop rotation or other methods. Many Western economies have an addiction to cheap oil to drive an economy or weapons manufacture as a way to bring in money.

This trap is known as addiction, dependence and, in terms of systems, shifting the burden to the ‘intervenor’. An Intervenordsafdfa is an act of intervention that makes everything appear to be working, on a short term basis. If the desired system state is to feel less depressed, then drugs will do this for a short while. Afterwards, the state can not only revert to where it was, but the world of the user may become worse. Likewise, if a business aims to increase sales of TVs, then a massive spend on advertising and pay per click search results will do this without needing to improve the website. But as soon as the spending stops, sales will slump again.

Here is an example from the world of atoms, the addiction to intervention by overusing street signs and street furniture. In this example, each step is logical and considered, but leads to a system that works but is expensive, complicated and needs constant maintenance.

The junction in the picture above is near Kew Bridge in west London. At the time of writing it has a dizzying amount of road markings, signs, barriers and traffic lights. It is a significant bottleneck. Each element is there for a reason yet; together, the overall system is close to chaos. Taking a higher-level system approach to traffic control could have avoided this.

The photo above is of Exhibition Road, a few miles away from the Kew Junction in Kensington, home of the Victoria and Albert, Science and Natural History Museums. Here division between road and passenger space has been removed to create a shared space. This project was led by architect Ben Hamilton-Bailee who is an advocate of removing as much clutter from our streets as possible. On the surface, this approach is highly counterintuitive and may appear to lead to a higher risk to pedestrians. The governing of the system is put back into the hands of the vehicles and pedestrians involved. Because there are less clear boundaries, it adds a degree of uncertainty drivers, and this then leads to lower speeds. This approach increases the safety of areas like this. The perception of risk leads to more careful users which then reduces the overall risk. This system approach has received criticism for being hostile to those with sight and hearing difficulties. The goal of this system is to allow access to cars and pedestrians and reduce the risk to both. This solution solves both well. It creates a working system by removing the interventions of behaviour on its users and instead relies more upon their intelligence and behaviour to create a better system. It decentralises control by creating an environment that stimulates careful use.

Is Surface Thinking all bad? When are Interventions needed?

At the Euro IA conference where I initially talked about this hypothesis, there was an excellent presentation by Jane Austin of the Telegraph newspaper. She recounted with great humour and insight the struggle they had had to drag a very conservative (with a small c) paper into the future. As part of that effort, she required a ‘laxative’ project; in this case, a redesign of the mobile app. Time constraints meant minimal research and in time to avoid an essential bit of middleware hitting its end of life. The team used many approaches, many of which were temporary patches and interventions. The result was an app that some loved, and some hated. This outcome is not surprising given the ‘build it and hope’ approach taken. The critical thing here is it got things going. A project that is far from perfect but is released is better than a project that is nearly perfect but never sees the light of day!

No organisation or project situation is ever perfect. A project may be without meaningful research or testing. We, as UXers, get dropped into agile projects that are several sprints in and is having difficulties. A UX team may try to drive change in an organisation where some areas are ignorant/resistant to the efforts of the team. The critical thing is to be aware of an intervention and to work towards converting any interventions into sustainable solutions.

Interventions in User Experience

So what interventions are we addicted to in User Experience? Here are a few examples of old and new User Experience outputs that can be considered interventions and, when heavily used, are addictions.

Microsites

For the world of advertising and marketing, the allure of building small, self-contained campaign sites is often too much to resist or merely the standard practice. Microsites get rid of a lot of complications by being stand alone. The budget is self-contained, the focus is evident, and the targeting clear. Creatives can go wild with no constraints from the legacy of other sites, and they might win an award at the end of it. Awesome.

Except once the campaign is over often the microsites disappear, with all the work put into them evaporating, or they are left to gather dust and get out of date. Meanwhile, the main site for that brand is left to customer support purposes and is generally unloved.

IIf the project is a campaign, integrate it. Let it benefit from all the existing long term content and let traffic be driven to it by the ‘main site’. Apple and others manage to do this. It’s not as easy, but it’s better for the brand in the long term!

Home Pages

Many experienced UXers working on websites know the problems with home pages and how they can become a lightning rod for anyone and everyone with an opinion. For this reason, leaving the home page to last is a good move. Home pages are like the bikeshed in the nuclear power station example given in the first part; everyone has a view and but feels it is easier to ignore the overall situation and focus on what can easily be understood.

Yet there are still many who feel creating an impressive home page should be the focus to the extent that some sites try to be all home page (one-page websites). These will only work for simple propositions that don’t require growth over time.

Radical Redesigns — Big Bangs!

If a website is not working, is looking terrible and in general everyone is fed up with it then often the most obvious solution is to knock it down and start again. It works for buildings so it should work for websites. Except this often ignores the considerable amount of lessons learnt from having a website live.

Spending time working out how to fix an older site is time-consuming, especially when there are sexy new sites out there that are responsive on more modern shinier platforms. So start again!

But going greenfield ignores the content that has been successful in the past. It is easy to throw the good and proven out with the old and tired.

The existing website should have a chance. First understand the old site in detail, seeing what worked, why it worked and is worth keeping. Avoiding these reviews can lead to a series of radical redesigns every couple of years as each site fails to satisfy the business, and no one knows why.

Visual / Trend Rehashes

Updating the look and feel of an app or website can be a good thing as trends change. This reskinning is not an alternative to improving the overall experience. It can also lead to the removal of existing-working content or features because they don’t work with the new design!

Concept Projects

These are small projects that think outside of the box and throw together some wicked visual concepts to convince the board/stakeholders/management. They are about driving change and are several degrees removed from the reality of everyday projects. They may iterate and heralded across the company. These concept projects are an addiction for many large companies where people want to show that things are happening.

These projects often whistle by me as I get stuck in the innards of big messy projects. Agencies love this kind of projects, especially in video form, and can often come unstuck when told ‘great — can we have that in three months’. I have been once asked to help work out the details of the UX for a large e-commerce site based upon a very slick and impressive video presentation with the time budget of about four days. In their mind and the client’s mind, that is the solution, and now it needs to be implemented. In reality, they had a bunch of barely connected ideas, with 90% of the experience missing.

If it appears such a project is happening, then the solution is to bring down the walls between the concept project and those already working on very similar problems. Let that inform what comes out of the project. Concepts are vital, but isolating them from how the existing system works will lead to ideas that are bright and shiny but ultimately disruptive in the wrong way.

A/B Testing

The idea is simple. By making variations to a live experience, usually interface changes, better solutions can be found and evolved. Measuring a set of metric determines what is better. The company is happy because they have hard evidence of improvement on the site. It’s hard to argue against hard figures.

Yet this approach to improving an experience hides more significant issues. System theory, for example, shows us that changing something here will alter something over there while we’re not looking. So for A/B testing to work, it would require measuring the effect on the whole of the site/app, not just the parts the changes are made on. That is very hard to do given the number of other variables flying around.

There is also a different problem. Evolution by gradual steps will hit local maxima. To understand this, picture all the possible solutions represented by a three-dimensional landscape. You end up with a fitness landscape, with multiple peaks. The peaks are the best solutions and the valleys things that need improving.

Evolution is like walking in this landscape. If you start on the side of a small hill and evolve, then you’ll end up at the top of a small hill. Having some knowledge of the whole landscape will mean you are more likely to start on a taller hill that will lead to a better solution. Also, the landscape will shift over time; the reason design is never done!

A/B testing appears to give reliable answers when, in reality, it is open to the unpredictability of any other approach. It is a useful tool for fine-tuning an interface, but ultimately a lousy tool for designing a user experience.

MVPs

Minimal Viable Products are a way to get things out there quicker and comes from the concepts in Lean Startup (and it’s sibling Lean UX). By creating something that does the minimum needed in a viable way, users can start giving feedback earlier, and things should, in theory, move to success quicker.

In theory, it’s a vast improvement on feature-rich projects taking many months or years to see the light of day only to fail. ‘Fail quickly’ is the idea here.

The issue with MVPs lies in the definition of what is viable. ‘Viable’ has been stretched in many directions and companies, big and small, allow external pressures to colour their interpretation. It is often confused with ‘what we can build quickly’ or ticking the boxes on a features list. A technology demo is not an MVP if it is unusable by the end-user. Likewise, if crucial parts of the user experience are missing, then it is also not viable.

There is also the danger that once a minimal site or app goes live the pressure to get something released disappears. In a side issue, the concept of relying upon customer feedback is also a deeply flawed idea compared to well-constructed testing and user interviews (see my post on evidence-based design for more on this).

So in summary, not going mad with features for launch makes sense, but missing the point of what is viable is not. What is released has to work as a system, not as a series of bits of functionality.

Some advice for dealing with systems

System Thinking has a habit of realising; we cannot have absolute control. Beyond the small and self-contained lies a world where top-down solutions fail. Here are some things to remember.

• We can never have complete control over a system.

• A series of simple interactions lead to complex results that can be unpredictable.

• We will never entirely fully understand a complex system, but we can study its behaviours.

We will never completely understand a system because of human perception. We only see and experience parts of the system even as we are creating them. Here is how I break down our understanding of a system.

Dean’s Rules of System Perception

Ideal — An understanding of how the system should work and what is should do. This is never how it actually works.

Perceived — how the system is understood by those that use it. This is often reinforced by training and communities.

Actual — how things really work or fail to work in many cases. This is rarely how it was designed or how it is perceived.

Summary: Learn to dance.

When we dance, we do not think about the movement of each limb. Our motion is in response to the music. We may be following a set choreography, or a set of moves from a given culture or just flailing around as if no one is watching. The feeling is similair. Each configuration of limbs moves to the next. It’s the same with playing music; each note does not live in isolation and the whole matters.

In ‘Thinking in Systems’ Donna provides a list of things to remember which she calls ‘the dance’. I see all of these points vital to being a capable User Experience person:

The Dance — Donella Meadows

1. Get the beat.
2. Listen to the wisdom of the system.
3. Expose your mental models to the open air.
4. Stay humble. Stay a learner.
5. Honour and protect information.
6. Locate responsibility in the system.
7. Make feedback policies for feedback systems.
8. Pay attention to what is important, not just what is quantifiable.
9. Go for the good of the whole.
10. Expand time horizons.
11. Expand thought horizons.
12. Expand the boundary of caring.
13. Celebrate complexity.
14. Hold fast to the goal of goodness.

To find out more about each point read Dancing With Systems: http://donellameadows.org/archives/dancing-with-systems/

Coming soon: System Thinking and UX: Part 3 — mapping of systems.