---
title: "Goal-Gradient Effect"
source: "/reference/goal-gradient-effect"
description: "Motivation can strengthen as people perceive themselves getting closer to a meaningful goal."
---
# Goal-Gradient Effect
Motivation can strengthen as people perceive themselves getting closer to a meaningful goal.
### Principle
Motivation can strengthen as people perceive themselves getting closer to a meaningful goal.
### Why it matters
Visible progress turns an abstract task into a path with a reachable end. Progress indicators, completed steps, milestones, and remaining work can help users sustain effort. The effect should reflect real advancement. Inflated, reset, or misleading progress damages trust and can make completion feel farther away than before.
### Deeper design interpretation
Progress changes effort when the user can see that meaningful completion is getting closer. A visible path converts an abstract task into a bounded journey and reduces uncertainty about how much work remains. This is useful in onboarding, long forms, migrations, uploads, learning, and setup.
Progress must correspond to real work. Decorative percentages or artificially inflated completion can produce the opposite effect when they stall, reset, or reveal unexpected work near the end. Trust in the progress model is part of the experience.
Layr should prefer truthful stages over false precision. When exact percentage cannot be known, milestones such as “ingesting,” “mapping,” “relationships,” and “validation” can be more informative than a number.
### What the agent should reason about
Compare the displayed model of progress with the actual job or task state. Determine whether optional work is counted as required completion. Check whether progress persists across sessions and whether completion clearly communicates what has been achieved.
The agent should also inspect whether the next step becomes clearer as the user advances, rather than only whether a progress bar exists.
### Common failure patterns
- Progress percentages jump or stall without relation to actual work.
- Optional enrichment prevents a task from reaching 100%.
- Long tasks reset visible progress after navigation or refresh.
- Users cannot tell which stages are finished, active, or remaining.
- Completion celebration obscures validation or exceptions.
### Audit questions
- What does the progress indicator actually measure?
- Can the system support the precision it displays?
- Are required and optional work clearly separated?
- Does the user know what completion unlocks or changes?
### Example agent finding
> **High — Migration progress is decorative rather than state-based.** The UI jumps to 80% immediately and remains there through several unrelated backend phases. Replace the fabricated percentage with durable stages and stage-specific counts where measurable so users can understand real advancement and remaining work.
### Agent directive
> Expose honest progress when a task has meaningful stages or accumulated effort. Show what remains and what completion unlocks.
### Apply this when
- Onboarding, checkout, setup, migration, learning, uploads, long forms, rewards, and long-running operations.
### Observable signals
- A multi-step task gives no indication of current stage or remaining work.
- Progress percentages jump unpredictably or stall near completion.
- Completed work is visually indistinguishable from remaining work.
- Optional steps are counted as required progress.
- A long operation resets visible progress when the user returns.
### Recommended actions
- Show stage, completed work, and remaining work using a model the system can support truthfully.
- Use milestones when exact percentage is unknowable.
- Preserve progress across sessions for durable tasks.
- Celebrate meaningful completion without blocking the next action.
- Separate optional enrichment from required completion.
### Do not over-apply
Never fabricate progress. If duration is uncertain, show stages or activity instead of a false percentage.
### Example
**Weak:** An import immediately displays 80% complete, then remains there for twenty minutes because the percentage is decorative.
**Stronger:** The import reports durable stages such as ingesting, mapping, relationships, activity, and validation, with stage-level progress where measurable.
### Evaluation notes
- **Default severity:** Medium; high when misleading progress causes abandonment, duplicate actions, or false expectations.
- **Typical confidence:** High when progress model can be compared with actual job state.
- **Primary evidence:** Job stages, completion logic, progress calculation, persistence, optional/required distinction.
- **Related rules:** Zeigarnik Effect, Doherty Threshold, Parkinson's Law, Peak-End Rule
### References
- [Laws of UX — Goal-Gradient Effect](https://lawsofux.com/goal-gradient-effect/)
## Related rules
- [Zeigarnik Effect](/__layr/pages/reference/zeigarnik-effect.md)
- [Doherty Threshold](/__layr/pages/reference/doherty-threshold.md)
- [Parkinson's Law](/__layr/pages/reference/parkinsons-law.md)
- [Peak-End Rule](/__layr/pages/reference/peak-end-rule.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Motivation, Progress & Experience Memory.
## Retrieve
- Canonical page: https://layr.design/reference/goal-gradient-effect
- Markdown for agents: https://layr.design/__layr/pages/reference/goal-gradient-effect.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "goal-gradient-effect"
title: "Goal-Gradient Effect"
category: "Motivation, Progress & Experience Memory"
origin: established
canonical_url: "https://layr.design/reference/goal-gradient-effect"
principle: "Motivation can strengthen as people perceive themselves getting closer to a meaningful goal."
directive: "Expose honest progress when a task has meaningful stages or accumulated effort. Show what remains and what completion unlocks."
applies_when:
- "Onboarding, checkout, setup, migration, learning, uploads, long forms, rewards, and long-running operations."
observable_signals:
- "A multi-step task gives no indication of current stage or remaining work."
- "Progress percentages jump unpredictably or stall near completion."
- "Completed work is visually indistinguishable from remaining work."
- "Optional steps are counted as required progress."
- "A long operation resets visible progress when the user returns."
audit_questions:
- "What does the progress indicator actually measure?"
- "Can the system support the precision it displays?"
- "Are required and optional work clearly separated?"
- "Does the user know what completion unlocks or changes?"
recommended_actions:
- "Show stage, completed work, and remaining work using a model the system can support truthfully."
- "Use milestones when exact percentage is unknowable."
- "Preserve progress across sessions for durable tasks."
- "Celebrate meaningful completion without blocking the next action."
- "Separate optional enrichment from required completion."
avoid_when:
- "Never fabricate progress. If duration is uncertain, show stages or activity instead of a false percentage."
common_failure_patterns:
- "Progress percentages jump or stall without relation to actual work."
- "Optional enrichment prevents a task from reaching 100%."
- "Long tasks reset visible progress after navigation or refresh."
- "Users cannot tell which stages are finished, active, or remaining."
- "Completion celebration obscures validation or exceptions."
evidence_types:
- "Job stages"
- "completion logic"
- "progress calculation"
- "persistence"
- "optional/required distinction"
default_severity: "Medium; high when misleading progress causes abandonment, duplicate actions, or false expectations."
typical_confidence: "High when progress model can be compared with actual job state."
related_rules:
- { id: "zeigarnik-effect", title: "Zeigarnik Effect", url: "https://layr.design/reference/zeigarnik-effect" }
- { id: "doherty-threshold", title: "Doherty Threshold", url: "https://layr.design/reference/doherty-threshold" }
- { id: "parkinsons-law", title: "Parkinson's Law", url: "https://layr.design/reference/parkinsons-law" }
- { id: "peak-end-rule", title: "Peak-End Rule", url: "https://layr.design/reference/peak-end-rule" }
```
## What to reason about
Compare the displayed model of progress with the actual job or task state. Determine whether optional work is counted as required completion. Check whether progress persists across sessions and whether completion clearly communicates what has been achieved. The agent should also inspect whether the next step becomes clearer as the user advances, rather than only whether a progress bar exists.
## Routing
Route a review here when the interface manages progress, interruption, completion, waiting, resumption, or emotionally significant outcomes. Avoid inferring motivation from UI alone; tie findings to observable journey states.
## 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
High — Migration progress is decorative rather than state-based. The UI jumps to 80% immediately and remains there through several unrelated backend phases. Replace the fabricated percentage with durable stages and stage-specific counts where measurable so users can understand real advancement and remaining work.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html
ImportProgress
Import progress80%
Unchanged since 14:0220 min
Decorative percentage · no stage, no remaining work