Gall's Law
A complex system that works has invariably evolved from a simple system that worked; complex systems designed from scratch rarely work.
See it in action
The same screen without and with Gall's Law. Watch both sides play out, then compare the outcome.
Designed complete from scratch, the system fails in ways nobody can trace or fix.
A small working system evolves into a complex one that still works.
What to watch: complexity added one working piece at a time versus all at once.
Launch the smallest system that works, learn from real use, and grow it in steps.
Specify and build a large system in one go and hope it works on day one.
Key takeaways
- Start with a simple version that works and evolve it.
- Validate core flows before adding complexity.
- Big-bang redesigns carry high risk.
Quick facts
- Also known as
- —
- Described by
- John Gall
- Year
- 1975
- Category
- Product strategy
- Related laws
- Occam's Razor, Tesler's Law, Pareto Principle
Gall's Law explained
Gall's Law argues that complex systems cannot be designed perfectly in advance. There are too many interactions and unknowns. Systems that work grow from simpler systems that already work.
For product design, this means starting with a minimal, valuable core and evolving it based on real usage and feedback.
It also applies to design systems, information architecture and onboarding flows: build a simple version, learn and iterate.
Where it comes from
Paediatrician and systems theorist John Gall described the principle in his 1975 book Systemantics: How Systems Work and Especially How They Fail.
How it shows up in apps
Successful products usually start with one focused use case and grow features over time. Teams that try to launch complex platforms all at once often face confusing products and costly failures.
Gall's Law examples
A team building a project management tool launches with simple task lists and due dates. After validating that teams rely on it, they add timelines, automations and integrations step by step.
Minimum viable products
Start-ups launch a focused product that solves one problem well, then expand once they understand how users use it.
Design systems
Teams start with a few core components and grow their design system as patterns are proven, rather than designing every component upfront.
Incremental redesigns
Large products roll out redesigns section by section, reducing risk and learning as they go.
How to apply Gall's Law
- Define the simplest version that delivers core value.
- Launch, measure and learn before adding complexity.
- Add features incrementally based on evidence.
- Keep systems modular so they can evolve.
- Avoid large, all-at-once redesigns where possible.
Want Gall's Law checked in your own product? Our saas ux audit evaluates it alongside the other principles that shape how users decide, onboard and stay.
Common mistakes
- Designing complex systems upfront without validation.
- Adding features faster than users can absorb them.
- Rewriting entire products instead of evolving them.
How to measure it
Track how each incremental release affects core metrics such as activation, retention and task success, and compare the risk and outcomes of incremental versus large releases.
Frequently asked questions
What is Gall's Law?
A complex system that works has invariably evolved from a simple system that worked; complex systems designed from scratch rarely work.
Where does Gall's Law come from?
Paediatrician and systems theorist John Gall described the principle in his 1975 book Systemantics: How Systems Work and Especially How They Fail.
How does Gall's Law apply to app design?
Successful products usually start with one focused use case and grow features over time. Teams that try to launch complex platforms all at once often face confusing products and costly failures.
What book is Gall's Law from?
It comes from John Gall's 1975 book Systemantics: How Systems Work and Especially How They Fail.
How does Gall's Law relate to MVPs?
Both suggest starting with a simple, working version and evolving it, rather than building a complex system from scratch.
How do you measure Gall's Law in a product?
Track how each incremental release affects core metrics such as activation, retention and task success, and compare the risk and outcomes of incremental versus large releases.
Sources
- Gall, J. (1975). Systemantics: How Systems Work and Especially How They Fail. Quadrangle/The New York Times Book Co. Find on Google Scholar ↗
Gall's Law in practice
- App developmentWhat is an MVP? Examples, cost and how to build oneAn MVP is the smallest version of a product that tests whether people want it. Definition, famous examples, types, cost in India and how to build one.
- Everyday design scienceWhy the human body is shaped the way it is: the design logic behind every partWhy is every body part shaped the way it is? Domes protect, tubes carry, folds add surface, levers move. The design logic of 164 parts, and which can be moved.
- Making moneyApp monetization strategies that don't annoy users — designed with behavioural scienceMonetize your app without wrecking retention: value-first paywalls, honest trials, rewarded ads, anchoring and decoy pricing done ethically, and what to avoid.
- Everyday design scienceWho invented infinite scroll? Aza Raskin built it in 2006, and has spent years warning about itAza Raskin invented infinite scroll in 2006 to save clicks, and now regrets it. How it works on the brain, what research shows and how regulators are acting.
- Templates & tools50 user interview questions that uncover real problems — grouped by goal, with the questions to avoid50 user interview questions for discovery and usability research, grouped by goal, with a simple script and the leading questions to avoid.
- Everyday design scienceLondon Tube map history: why Harry Beck's 1933 diagram isn't to scale, and why that worksLondon Tube map history from the 1908 geographic maps to Harry Beck's 1933 diagram. Why it isn't to scale, how it shapes route choices and what research shows.
Certifications that test it
- Free certification · UX/UI, Design, Research & CreativeProduct Design CertificationCertifies end-to-end product design: framing problems against business goals, designing and shipping solutions with engineering, and measuring their impact.
- Free certification · UX/UI, Design, Research & CreativeDesign Systems CertificationCertifies that you can build, document, govern and scale a design system — tokens, components, documentation, adoption and design–engineering collaboration.
- Free certification · Product, Project Management & Business AnalysisProduct Manager CertificationCertifies that you can run product well — discovery, strategy and prioritization, metrics, delivery with design and engineering, and launch.
- Free certification · Product, Project Management & Business AnalysisDesign Leadership CertificationCertifies that you can lead design — build and grow teams, set design strategy, run design operations, measure design's impact and influence the business.
- Free certification · UX/UI, Design, Research & CreativeService Design CertificationCertifies that you can design services end to end — customer journeys, service blueprints, research and co-design, and delivery and measurement across channels.
- Free certification · Product, Project Management & Business AnalysisAgile Product Owner CertificationCertifies that you can do the product owner job in agile teams — Scrum roles and events, backlog ordering and refinement, user stories and acceptance criteria, and value-focused releases.
Get the ideas, not the noise.
Sign up with Google and we’ll send you short UX psychology tips by email — why people tap, stall and leave, and what to do about it. Unsubscribe anytime. Prefer something to keep? Get the free Laws of UX guide as a PDF.











