---
title: "Parkinson's Law"
source: "/reference/parkinsons-law"
description: "Work tends to expand to fill the time or space available; in product design, loose task boundaries can encourage unnecessary effort."
---
# Parkinson's Law
Work tends to expand to fill the time or space available; in product design, loose task boundaries can encourage unnecessary effort.
### Principle
Work tends to expand to fill the time or space available; in product design, loose task boundaries can encourage unnecessary effort.
### Why it matters
Parkinson's Law is not a direct usability formula, but it is useful when a workflow invites open-ended configuration before value is delivered. Setup tasks, editors, and administrative processes can grow because the interface presents every possible decision at once. Clear scope, defaults, and staged configuration help users reach a useful state without overworking the setup.
### Deeper design interpretation
Open-ended tasks tend to grow. In software, this appears when setup, profile completion, project creation, or configuration offers every possible refinement before the user reaches a meaningful done state. The user may continue because the interface implies that completion requires more work, even when the additional detail is optional.
A clear boundary protects time and helps users distinguish “ready to use” from “can be improved later.” This is especially valuable in onboarding and administrative workflows, where products often accumulate fields over time.
Layr should examine completion logic, optionality, and time-to-value rather than simply shortening forms.
### What the agent should reason about
Identify the minimum required state for the product to function correctly, then compare it with what the interface currently treats as mandatory. Look for optional fields presented with the same visual weight and progress logic as required ones.
Do not recommend artificial deadlines or time pressure for tasks that require careful review.
### Common failure patterns
- Optional customization blocks initial creation.
- Profile-completion meters count irrelevant optional fields.
- Setup combines creation with every advanced setting.
- Users can refine indefinitely without a clear “done” state.
- Progress indicators imply incompleteness after all required work is finished.
### Audit questions
- What does “done enough to get value” mean for this task?
- Which fields or steps are genuinely required?
- Can refinement happen later without risk?
- Does the interface create artificial incompleteness?
### Example agent finding
> **Medium — Workspace creation requires advanced configuration before first use.** Branding, integrations, notification policy, roles, and templates are all mandatory in the creation flow even though only name and owner are required to create the workspace. Create the workspace after the essential fields and move advanced setup into post-creation configuration.
### Agent directive
> Give tasks a clear completion boundary and avoid making optional refinement feel mandatory before users can obtain value.
### Apply this when
- Onboarding, setup, configuration, profile completion, project creation, editors, reporting, and administrative workflows.
### Observable signals
- A setup flow exposes many optional fields with no distinction from required ones.
- Users can continue refining indefinitely before the product confirms that the task is complete.
- 'Complete your profile' mechanics pressure users to fill irrelevant information.
- A creation flow combines initial creation with every advanced configuration option.
- Progress indicators treat optional customization as incomplete work.
### Recommended actions
- Separate required setup from optional refinement.
- Define a meaningful done state.
- Move advanced configuration after initial value when safe.
- Label optional fields honestly and avoid artificial completion pressure.
- Save partial work so users can refine later.
### Do not over-apply
Do not rush tasks that require careful review. Time pressure can increase errors, especially for financial, legal, medical, security, or destructive decisions.
### Example
**Weak:** Creating a workspace requires configuring branding, integrations, notification rules, roles, and templates before the first project can exist.
**Stronger:** The workspace is created after essential identity and ownership choices; advanced configuration remains available afterward.
### Evaluation notes
- **Default severity:** Low to medium; high when bloated setup blocks activation.
- **Typical confidence:** Medium because unnecessary scope depends on product requirements.
- **Primary evidence:** Required/optional fields, completion logic, setup sequence, time-to-value.
- **Related rules:** Paradox of the Active User, Tesler's Law, Goal-Gradient Effect, Cognitive Load
### References
- [Laws of UX — Parkinson's Law](https://lawsofux.com/parkinsons-law/)
## Related rules
- [Paradox of the Active User](/__layr/pages/reference/paradox-of-the-active-user.md)
- [Tesler's Law](/__layr/pages/reference/teslers-law.md)
- [Goal-Gradient Effect](/__layr/pages/reference/goal-gradient-effect.md)
- [Cognitive Load](/__layr/pages/reference/cognitive-load.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Interaction, Performance & Error Tolerance.
## Retrieve
- Canonical page: https://layr.design/reference/parkinsons-law
- Markdown for agents: https://layr.design/__layr/pages/reference/parkinsons-law.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "parkinsons-law"
title: "Parkinson's Law"
category: "Interaction, Performance & Error Tolerance"
origin: established
canonical_url: "https://layr.design/reference/parkinsons-law"
principle: "Work tends to expand to fill the time or space available; in product design, loose task boundaries can encourage unnecessary effort."
directive: "Give tasks a clear completion boundary and avoid making optional refinement feel mandatory before users can obtain value."
applies_when:
- "Onboarding, setup, configuration, profile completion, project creation, editors, reporting, and administrative workflows."
observable_signals:
- "A setup flow exposes many optional fields with no distinction from required ones."
- "Users can continue refining indefinitely before the product confirms that the task is complete."
- "'Complete your profile' mechanics pressure users to fill irrelevant information."
- "A creation flow combines initial creation with every advanced configuration option."
- "Progress indicators treat optional customization as incomplete work."
audit_questions:
- "What does “done enough to get value” mean for this task?"
- "Which fields or steps are genuinely required?"
- "Can refinement happen later without risk?"
- "Does the interface create artificial incompleteness?"
recommended_actions:
- "Separate required setup from optional refinement."
- "Define a meaningful done state."
- "Move advanced configuration after initial value when safe."
- "Label optional fields honestly and avoid artificial completion pressure."
- "Save partial work so users can refine later."
avoid_when:
- "Do not rush tasks that require careful review. Time pressure can increase errors, especially for financial, legal, medical, security, or destructive decisions."
common_failure_patterns:
- "Optional customization blocks initial creation."
- "Profile-completion meters count irrelevant optional fields."
- "Setup combines creation with every advanced setting."
- "Users can refine indefinitely without a clear “done” state."
- "Progress indicators imply incompleteness after all required work is finished."
evidence_types:
- "Required/optional fields"
- "completion logic"
- "setup sequence"
- "time-to-value"
default_severity: "Low to medium; high when bloated setup blocks activation."
typical_confidence: "Medium because unnecessary scope depends on product requirements."
related_rules:
- { id: "paradox-of-the-active-user", title: "Paradox of the Active User", url: "https://layr.design/reference/paradox-of-the-active-user" }
- { id: "teslers-law", title: "Tesler's Law", url: "https://layr.design/reference/teslers-law" }
- { id: "goal-gradient-effect", title: "Goal-Gradient Effect", url: "https://layr.design/reference/goal-gradient-effect" }
- { id: "cognitive-load", title: "Cognitive Load", url: "https://layr.design/reference/cognitive-load" }
```
## What to reason about
Identify the minimum required state for the product to function correctly, then compare it with what the interface currently treats as mandatory. Look for optional fields presented with the same visual weight and progress logic as required ones. Do not recommend artificial deadlines or time pressure for tasks that require careful review.
## Routing
Route a review here when evidence is measurable in interaction behavior: latency, target geometry, validation, parsing, task completion, duplicate actions, failed input, or recovery. Prefer instrumented evidence over aesthetic judgment.
## Review procedure
For every finding:
1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.
## Finding contract — emit exactly this shape
```yaml
finding:
rule_id: string
location: string
evidence:
- observable fact
impact: string
severity: low | medium | high | critical
confidence: low | medium | high
recommendation:
change: string
rationale: string
preserve:
- existing design-system behavior
- valid product constraints
```
## Example finding for this rule
Medium — Workspace creation requires advanced configuration before first use. Branding, integrations, notification policy, roles, and templates are all mandatory in the creation flow even though only name and owner are required to create the workspace. Create the workspace after the essential fields and move advanced setup into post-creation configuration.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html