Work expands to fill the time available for its completion. Given more time than a task needs, people tend to use all of it.
Overview
If a report is due in two weeks, it often takes two weeks; if it is due in two days, it often takes two days. Parkinson’s Law captures this familiar pattern: the time a task takes tends to stretch to match the time allowed.[1][2]
The law began as a satirical observation about bureaucracy, but its insight applies to how people experience digital tasks too. When a process seems open-ended, people may spend more time than necessary on it, or put it off. When it is quick and clearly bounded, they are more likely to finish it efficiently.
Parkinson also described a related idea, the law of triviality: groups tend to spend disproportionate time on minor, easy-to-understand issues while major, complex decisions get little discussion. His famous example was a committee that approves a nuclear plant quickly but argues at length about a bicycle shed.[3]
Why it matters
For users, unnecessary time spent on tasks adds up across an organization. Designs that help people complete tasks faster than expected, through defaults, autofill, and fewer steps, free time for more valuable work.
For teams and leaders, Parkinson’s Law and the law of triviality are reminders to timebox work and focus discussion on the decisions that matter most.
Key takeaways
- Set clear expectations. Telling people how long a task will take (“about 5 minutes”) helps them commit and complete it.
- Make tasks take less time than expected. Use autofill, saved information, and sensible defaults.[4]
- Do not ask for information twice. Reuse data people have already provided.[5]
- Break open-ended work into bounded steps with clear completion points.
- Timebox design and decision-making, and direct discussion toward the most consequential issues.
In practice
Common patterns in business applications, portals, and internal tools:
Supports the principle | Undermines the principle |
|---|---|
“This request takes about 3 minutes.” | No indication of how long a task will take. |
Forms pre-filled with known information and browser autofill support. | Re-entering name, department, and contact details every time. |
Long tasks split into short, clearly bounded steps. | A single open-ended page with no sense of completion. |
Reviews and workshops with clear time limits and agendas. | Open-ended meetings that drift toward minor topics. |
Design reviews focused on the highest-impact decisions first. | Extended debate about minor visual details. |
Questions to ask in a design review
- How long should this task take, and do people know that before they start?
- Which inputs could be pre-filled, defaulted, or reused?
- Is this process open-ended in ways that invite delay?
- In our own reviews, are we spending time on the decisions that matter most?
Origin
British naval historian C. Northcote Parkinson introduced the law in a humorous 1955 essay in The Economist, observing that the British Colonial Office kept growing even as the British Empire shrank. He expanded the idea in his 1957 book Parkinson’s Law, and Other Studies in Administration, which also introduced the law of triviality.[1][6][3]
The law has since been widely applied in management, project planning, and productivity, and in UX as a reason to design tasks that respect people’s time.[2]
Related concepts
- Goal-Gradient Effect — clear milestones accelerate effort
- Doherty Threshold — fast systems respect people’s time
- Principle of Least Effort — people take the easiest path
- Zeigarnik Effect — unfinished tasks linger in the mind
- Cognitive Load — fewer demands mean faster completion
- Analysis Paralysis — open-ended decisions invite delay
References and further reading
- Wikipedia. Parkinson’s Law. https://en.wikipedia.org/wiki/Parkinson%27s_law
- Yablonski, J. Parkinson’s Law. Laws of UX. https://lawsofux.com/parkinsons-law/
- Wikipedia. Law of Triviality. https://en.wikipedia.org/wiki/Law_of_triviality
- W3C. Understanding WCAG 2.2 Success Criterion 1.3.5: Identify Input Purpose. https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html
- W3C. Understanding WCAG 2.2 Success Criterion 3.3.7: Redundant Entry. https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html
- Wikipedia. C. Northcote Parkinson. https://en.wikipedia.org/wiki/C._Northcote_Parkinson
- Yablonski, J. Laws of UX (format inspiration for this series). https://lawsofux.com/