System Thinking and UX Part 1: Exploring Systems and Our Addictions

I have a hypothesis. It is that the best path to the simplest user experience is through understanding the whole experience and that we are addicted to surface thinking, a way of thinking that leads to bad, shallow and fragile results.

This hypothesis was formulated whilst working on a wide range of different projects, working as a User Experience contractor. I have worked with some amazing people and with some amazing companies on some amazing projects. The less than positive things I will say in this article are not a reflection on individuals or companies, they arise from work practices that are obvious and appear to work. It is just that, over time, I have seen many situations where, either during or after a project, I realise that the chosen solution was not the right one. It may have been an agile project where there was pressure to deliver wireframes without fully processing the user reviews. Or it might have been a project where there was no real solid objective to the project and the notion that a proof of concept needed to be created to test online transactions.

For years I’ve been uneasy with teams rushing to solutions and that unease has grown with the rise of ‘Lean’ methodologies. Something is missing and this article is an attempt to turn that feeling into something more solid.

Here is my hypothesis.

  • Too many teams and organisations have become addicted to surface thinking, often without knowing it.

  • This leads to User Experiences that lack sustainability and become fragile over time.

  • Teams don’t embrace what I call the Messy Middle as it’s opaque and scary.

  • There is a false belief that embracing complex problems lead to complex experiences.

Here is an explanation of the terms I use here.

Surface Thinking

dribble Surface thinking is when the most obvious, attractive and easy approach to a project is used first and last. It is the path of least resistance. For example, in the world of User Experience the user interface is the most obvious and attractive thing. They can be made visually appealing and grab the attention. If, given a large problem, the team starts to sketch interfaces then that is surface thinking. Design portfolio sites, such as dribbble, has lead many of the new generation of designers to confuse visual design with UX design. This has lead to what has been called ‘The Dribbblisation of design’ where there are thousands of weather, dashboard and ticket mockups which, if they were implemented, would prove to be worthless or simply fail to deliver on the needs of the user.

Surface Think goes beyond visual design. If a developer starts to code without the application architecture being defined, that’s surface thinking. If a product manager comes to a meeting with a solution rather than a business requirement, that’s surface thinking. It is trying to rush to a solution before the real problem is discussed or understood.

There is a concept called ‘Bikeshedding’ that explains more about why surface thinking happens. This comes from Parkinson's Law of Triviality, a semi serious ‘law’ that says that a committee responsible for a Nuclear Power Plant will have a tendency to spend more time discussing what materials the staff bikeshed will be made of than the vastly more complex and expensive details of the cooling system for the actual Power Plant. The tendency is to avoid the complex and to discuss things that are accessible and easy to have a view on.

To put this in design terms it is when the meeting lingers on a detail of the design, such as the colour of blue for a logo, something I labeled ‘The Wrong Colour Blue Syndrome’. It was good to discover that this was another version of Parkinson's Law of Triviality. Surface Thinking is a form of the love of the trivial.


If a site is being completely redesign every year or so then it’s a good indication that the site is not being designed to be sustainable. If a site needs constant tactical projects to make it work then that’s also a good sign that it was not designed to be sustainable but was designed without the future, or even the present, in mind.

Some projects I have worked on, such as a cinema listing, have been live for over ten years whilst others have had several big bang redesigns. Some have had visual redesigns yet the core information architecture put in place still remains. It is the sites that evolve that indicate that the problem was approached in the right way to start off with and it works for users now as it did then. These are sustainable solutions, they are hardy and survive.

It is very tempting for a new agency or a new member of staff to want to start a project with a blank sheet of paper and start afresh rather than attempting to understand what has been done and why it has been done. The clean sweep method of design is very tempting and can lead to good ideas that work being thrown out with those that don’t. Trends, pet ideas and chasing after competitors can all lead to unsustainable projects.

Messy Middle

This phrase I coined to describe all the stuff that isn’t on the surface. It’s all the differing requirements for different users, it’s the needs of the business and how they interrelate. It is about spreadsheets and lists of features from multiple meetings as well as going through any history of the project, trying to work out why the project is being done in the first place. It is seeing where the interdependencies are and how work flows lead into the final project. It is all messy and rarely are the records of past work recorded and often the people who did the work are somewhere else.

It can often be the case where a User Experience person arrives on the project and is given a set of signed off requirements to work from. From this wireframes are often expected. If any research and analysis is done, for the sake of the UX, then it is very common to find the requirements are not a destination but a starting point. The requirements may have been a wish list created in a meeting or from customer feedback. Neither of these methods look at the messy middle effectively. There is often a gap between what is understood to be needed and what is actually needed.

An example of Surface Thinking: Sky Plus Homepage

Occasionally I post a quick UX name and shame on twitter to share bad user experiences that I come across. It will be no surprise that iTunes has been mentioned several times. Sometimes I get to have a discussion with the people behind the experience who give me insight into their own frustrations that led to a less than perfect UX.

Often the reason why something turns out the way it does is obscured by a chain of decisions made over multiple meetings. In this example I have an inside view as I was one of the UX team who worked on it. I share responsibility for this.
The project is the new Homepage for the Sky Plus system in the UK. The home page makes up part of the EPG (electronic programme guide) which sits behind live TV. It is where viewers to go to see what is on, what they’ve recorded and to find on demand content. The on demand content was effectively patched into the existing EPG and used many of the same interaction methods as the TV guide. As few ventured far into the EPG it meant that on demand content was buried. When viewing a recorded programme, or even watching an on demand bit of content, there was essentially nothing to lead a user onto another bit of content or to tell them other episodes were available. The home page is an attempt to bring this on demand to the viewer.
Here is a diagram that gives some context to this problem and shows the ‘universe’ of the EPG. This represents the ‘as is’ state at my time of working at Sky and has no indication of future work, the reason it is safe to post. What it does show is how messy the platform had become. The circles represent the different areas of functionality with size showing amount of use and importance to the company and the colours relating to different tasks. The box in the middle is the EPG with TV watching above it, the ancient on demand services to the left and interconnection with other devices on the right.
To add to this, here is a diagram showing the button presses for some of the most common viewer tasks. With an experience driven by a remote control each action is labeled with the appropriate button press. Mapping out the journeys shows how many button presses each thing takes. Each changing of button is something a viewer has to think about and using colour buttons often requires a viewer to stop and look at the remote. This map showed that even simple journeys carried a high cognitive load.

From this work I could see there was a fundamental issue with the way the EPG worked. The main issue was the lack of a programme information page where the user could select options for a bit of content. There was a ‘before playing’ screen but it was minimal. Instead users highlight an item from a list and, without having more information, choose what to do with that item. Each action requires a different button press, many hidden under coloured buttons. As buttons were limited, it made this screen limited and also required instructions to tell the user what to do, which took up vital screen space.

A programme information page can be thought of as a product page in an ecommerce experience. It is a page where users can perform actions using the arrow and action keys. It also has space to allow for related programmes to be shown - which was our suggested solution to how to make discovery easier. Other TV platforms use these information pages well and it allows the platform to grow, so can be viewed as sustainable. Each addition on the Sky platform required moving what buttons do and would lead to confusion for the users.

What the home page does is either add or remove a step from the user’s progress, depending on what the user is looking to do. It does bring on demand to the top of the EPG but often at the time when the user is more interested in doing something else. The addition of the search is good. It is an improvement on the initial work I did with some well thought out simplifications.

Overall the Sky EPG remains a mess and with the current approach discovery content will have to be added in unnatural places. If programme information pages are added, as well as meaningful information after watching something then this discovery content would appeared at natural points of the users journey. The homepage It is a surface thinking solution to a problem that can be solved by looking at the whole experience.

Exploring my Hypothesis

If surface thinking leads to solutions that are shallow, then what are the alternatives? The Messy Middle idea is a messy concept, and how can it be solidified? Who else has written about it and how can it be separated from the instant gratification of sketching an interface?

Another way to think about the messy middle is about trying to see the whole system seen from an interaction design point of view. Therefore, what we do is design systems, interactive systems. This leads me back to the title of my degree, Interactive System Design. My first business card proclaimed I was an Interactive System Designer. I still consider that is a more descriptive title than User Experience Design, mostly because the system part could lead less end customers to think that I ‘do Photoshop’ and just design UIs. ‘System’ appears to be the key word here.

Towards the end of my degree, I developed a parallel interest in the field of ‘Artificial Life’, the study of life like systems. For my final year project I created a web site on the subject, the first on the course. This was back in 1994, a time when Yahoo had only just put up its directory of web pages and interaction designers focused on software and CD-rom creation.

Artificial Life provided my introduction to the world of non-linear systems and emergence. Non-linear systems are systems where there is little or no central control and where many simple small systems interact. The behaviour of the system does not follow one linear path. The results can be chaotic and unexpected as well as being surprisingly resistant to change.

Emergence is the behaviour that comes from non-linear systems. Emergence is when something becomes more than the sum of its parts. One example is an ants nest. It is a common misconception that the queen ant rules the nest. In reality the queen is as much a slave as any other ant. The behaviour and intelligence of the ants nest emerges from the interactions of all the ants. Studying one ant may give the rules for that one ant, but only when that ant is interacting with other ants do those rules start to make sense. Just as an ant will not tell us how a system works, so surface artifacts are unlikely to tell us how the system really works.

Discovering System Thinking

It was time to delve back into the world of systems. I read some system theory books and researched the subject online. After a few dead ends I discovered a book called Thinking in Systems: A Primer
This book proved to be readable, accessible and covered systems in a way that started from basics before crossing over with my past reading. It introduced me to the concept of System Thinking.

System Thinking focuses on approaching a problem as a system, both from a practical point of view and from a philosophical point of view. Just as emergence changes how we view an ants nest so System Thinking is about rethinking how nearly anything works. My knowledge of system theory is still far from complete yet in my voyage so far I have discovered that importance of the System in Interactive System Design and how System Thinking is very relevant to User Experience.

Defining Systems

To say anything can be viewed as a system, whilst no incorrect, is too broad a concept. Thinking in Systems provides a clearer definition in its appendix. Keep in mind we are talking about systems in general and not just User Experience. Here is the book’s definition.

  • A system is more than the sum of its parts.

  • Many of the interconnections of a system operate through the flow of information.

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

  • System structure is the source of system behaviour. System behaviour reveals itself in a series of events over time.

I’ll work through these point with a User Experience perspective.

More than the Sum of it’s Parts

This is another way of describing emergence, a concept that is part of Artificial Life and Chaos Theory. This confirmed for me the importance of not dwelling just on detail as that will not lead to an understanding of how a system works. In other words, fixing the User Interface is not the same as fixing the User Experience.

Recently there has been a rise in relying on A/B testing to evolve sites and applications. These tests appear to be scientific and provide hard figures that are a good tool to persuade stakeholders. By trying different variations on a live audience it is possible to find interface solutions that perform well. There are some obvious problems, like the issue of local maxima, where a solution finds a peaks on a fitness landscape but can’t cross a valley to a higher peak and a better solution. Emergence tells us that if we change individual parts of a system we are likely to see effects in places other than where we make the change. In a busy live system these will be hard to see, yet System Thinking tells us they happen.

The Flow of Information

Information that flows through a system needs to start somewhere and end somewhere. It is how this flows that form the structure of a network. An example of the simplest form of system is a bathtub. It has an inflow (the taps), a tub where water (the information) is stored (called a ‘stock’ in system terminology), and an outflow (the plughole). If the inflow is tied to the state of another flow or the stock in the system, like how much water is in the tub, then that is a feedback mechanism. A feedback mechanism is also a flow of information in the system. It is these flows that determine the architecture of a system.

A website, for example, is also a simple system with information taking the place of water. There are multiple flows, such as the amount of users visiting the site and feedback is fed back via content statistics and other forms of user interaction. The more complex the application, the more levels of flows and feedback mechanisms there are, and the less linear the overall system becomes.

The Least Obvious Part of a System, its Function and Purpose, is often the most Critical

From a UX point of view, the purpose of a project is often both clear and unclear at the same time. The aim of a site may be to sell things. That doesn’t carry enough information to design a good user experience. Who the site is selling to, what items are sold from a brand and business point of view, and how the site changes with the rhythm of the year - all these factors define the function and purpose of the system. How John Lewis sells televisions requires a different approach to how Harvey Nicks sell dresses so the purpose of each site is beyond just selling items.

The set purpose of a system alters the way the parts interact. What is counted as success changes the feedback mechanisms which, in turn, alters the behaviour of the system. For example if a political party changes its doctrine and prioritises new jobs over, say, education then this will change the behaviour of a government more than the change of its leader. Even in human systems, presidents and prime ministers have far less influence than their high profile in the media would lead us to believe.

System Structure is the source of system behaviour

So if changing the purpose of a system changes the behaviour of a system for a given system. What happens if you change were that feedback goes?

From an Information Architecture point of view, it has long been understood that the hierarchy of information presented to a user radically changes how the user interacts with it. For example I have worked on the product hierarchy for John Lewis online, the large UK department store chain. Doing so, increased the sales of items such as dresses, TVs and games consoles. The products were the same but the structure altered.

To understand how changing the structure of a system changes behaviour requires looking beyond single events. We need to look at how information, or users in the case of an online store, flow around a system. Single page stats told us very little but by building journeys we could see when users resorted to the search function, or bounced between sections on a regular intervals, or simply gave up.

How a system is organised, or not, is often overlooked when looking to improve a system. Many large organisations have evolved by finding what works and often the reason for that solution is lost in the fog of time. A new person looking at how an organisation works might not be able to see the benefits of the way it is structured and, instinctively, want to reorganise that company into something that is more ‘common sense’. Systems obey the rules of common sense. Changing too much, too often will have effects that simply cannot be seen if measurement only focuses on what has been changed. The complete system behaviour may have been changed but it will not be visible from the few metrics selected.

The information flows are altered by the goals of a system and where these flows go is determined by the structure of the system. All these flows, feedback loops and structure lead to non linear behaviours that are more than the sum of their parts. Any change will therefore have an effect beyond the locality of that change.

In Part 2

We look in more detail how System Thinking can be applied to UX. We look at a couple of potential ‘system traps’ that lead to badly designed systems, including how it is easy to become addicted to interventions rather than solutions. I also explore some of the advice given in ‘Thinking In Systems’ and how it applies to UX.

Go to: System Thinking part 2

See Also:

More UX Stew Posts