Galls Law is a rule of thumb or heuristic which indicates that complex systems that work are normally found to have evolved from a simple system that worked. Trying to design a complex system from scratch is never successful and it cannot be made to work once created. It is necessary to begin again with a simple system before trying to make it complex.

Galls Law originates from John Gall’s book Systemantics: How Systems Really Work and How They Fail. The law supports the idea of under-specification and explains the success of the World Wide Web and Facebook. Both of these began as fairly uncomplicated systems. But over time have become highly complex ecosystems.

There are of course many examples of complex systems that have failed, especially in IT. The evidence for Gall’s Law does appear more anecdotal than scientific.

The other principles of Gall’s Law are:

1. Complex systems rely on many variables and interdependencies. Designing complex systems from scratch doesn’t work. They haven’t been shaped by environmental selection forces that allow them to become more complex.
2. Uncertainty means that designers can never predict all of the interdependencies and variables to build a complex system from scratch. This means such complex systems are prone to failure.
3. Environmental constraints which change over time and are unpredictable, suggest designing a simple system that works in the current environment. Then adjust the system over time to improve it.
4. As prototyping and iteration are so effective as value-creation processes it is much easier to use these methodologies to verify that a system meets critical functional needs. Rather than try to build a complex system from scratch.
5. Developing that prototype into a minimum viable offer enables project managers to validate critical assumptions and produce a simple system that can work with real users.
6. The organisation can then use iteration and incremental augmentation to develop an extremely complex system. Over time that can be adapted to environmental changes.

Implications for conversion rate optimisation:

1. Focus on critical customer needs.

This means aim to begin by building simple apps and websites that are not overly complex and don’t have too many features and functions that most customers are unlikely to ever use. Snap Chat for instance started out as a very simple messaging app and has only gradually become more complex over time. Get the basic right first.

Unfortunately this is not ‘sexy’ or ‘cool’ and so often product teams add features based upon their personal preference rather than evidence. Avoid this if you can.

2. Get the basic right first.

All too often people get obsessed with the latest feature or functionality that competitors offer without first getting the basics working on their own site or app. For example, most users won’t change default settings. So there is little to gain from giving customers more choice in the settings tab if no one ever uses them.

3. Allow for your app or website to evolve over time.

A key principle of Gall’s Law is that software starts simple and then evolves to become more complex over time. Optimisers and project managers should make allowance for this evolutionary change. Build in feedback and reporting mechanisms to facilitate this process. Listening to customers and using A/B tests and multivariate testing should be part of the iterative process for allowing your app or site to evolve over time.

Conclusion:

Galls Law should be a reminder for designers, project managers and optimisers to stay focused on key customer needs and avoid the dangers of mission-creep and over-complicating a new user experience. Get the basics right first and allow for evolutionary change via customer feedback and optimisation experiments.

Galls Law could have been written for conversion rate optimisation as one of the key principles of CRO is to establish an evolutionary optimisation strategy rather than going for regular site re-designs. This makes for less disruption for users and it provides optimisers with more opportunities to understand the impact of small changes on success metrics.