Obstruction · European Union
Dead end
The label “Dead end” describes this recurring design mechanism: a consumer-favourable route cannot reach its represented outcome and instead loops, stalls or loses progress. It is a design and research taxonomy, not a standalone legal conclusion. Depending on the complete journey and likely effect, current EU consumer or sector rules may require separate assessment. No published Digital Fairness Act proposal currently creates a pattern-specific prohibition or duty under this label.
- Family
- Obstruction
- Also known as
- Journey stages
Definition
What is this pattern?
A consumer-favourable route cannot reach its represented outcome and instead loops, stalls or loses progress. The label describes a recurring design mechanism; whether a particular implementation is harmful or unlawful depends on the complete journey, audience, evidence and rules within scope.
How it works
A consumer-favourable route cannot reach its represented outcome and instead loops, stalls or loses progress. A route represents that a request can complete but then loops, errors or changes no durable state, without a working recovery path or confirmation record.
Warning signs
- The interface represents or reasonably implies that the outcome is available.
- Repeated execution cannot reach that outcome under controlled conditions.
- A business-favoured route remains functional or the failure systematically burdens the alternative.
Potential harms
- A customer may abandon a valid request after repeating work without a way to complete or recover.
- The represented outcome is not reached, leaving the subscriber exposed to another charge.
Learn by comparison
What does this look like?
These fictional examples make the design mechanism easier to recognise. They do not depict a real company and do not establish that an individual interface is unlawful.
Illustrative example 1 · Order support
A fictional refund form accepts every field, then returns to the first screen with “Something went wrong” and no saved state or alternative route.
Potential consumer harm: A customer may abandon a valid request after repeating work without a way to complete or recover.
Illustrative example 2 · Subscription account
A fictional service shows “Cancellation complete” but returns the user to an active-plan dashboard and continues renewal without a receipt or status event.
Potential consumer harm: The represented outcome is not reached, leaving the subscriber exposed to another charge.
Refund form loops after submission
A fictional refund form accepts every field, then returns to the first screen with “Something went wrong” and no saved state or alternative route.
Submit refund request. The form loops to an empty first screen without identifying a fix.. Order number: Enter order number. Refund reason: Enter refund reason. Requested amount: Enter requested amount. Try again
We could not submit the request. Entered details are saved and a supported fallback is offered.. Saved order number: Enter saved order number. Saved refund reason: Enter saved refund reason. Saved requested amount: Enter saved requested amount. Resume or contact support. Purpose and refusal effect, expanded: The form explains why “Resume or contact support” is requested and what happens if it is not used.
Why the first version can mislead: The route adds avoidable effort between the user’s stated intention and completion. In this order support example, the obstacle is: “The form loops to an empty first screen without identifying a fix.” Evidence should show whether the alternative remains usable and whether “Resume or contact support” reaches the represented state. A customer may abandon a valid request after repeating work without a way to complete or recover.
What a fairer design does: Preserve entered data, explain the specific error and provide a tested fallback route with a reference number.
Show annotated differences (2)
- Try againIn “Refund form loops after submission”, this element shows how dead end can shape the decision.
- Purpose and refusal effect, expanded: The form explains why “Resume or contact support” is requested and what happens if it is not used.In “Refund form loops after submission”, this element keeps the clearer alternative visible at the same decision point.
Review questions (3)
- How many steps, waits and channel changes separate “Try again” from the completed order support outcome?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “The interface represents or reasonably implies that the outcome is available”?
- Measure the same task through the clearest available route: does the effort difference persist once “General outage affecting all paths” is accounted for?
Cancellation confirmation changes no account state
A fictional service shows “Cancellation complete” but returns the user to an active-plan dashboard and continues renewal without a receipt or status event.
Cancellation complete. The plan remains active and no confirmation record exists.. Blocking step: Back to account: current. Obscured outcome: Download confirmation: current
Plan ends on 30 September. The account status, renewal setting and receipt all reflect the completed request.. Completion step: Download confirmation: completed. Recorded outcome: Back to account: completed. Request recorded: Download confirmation
Why the first version can mislead: The route adds avoidable effort between the user’s stated intention and completion. In this subscription account example, the obstacle is: “The plan remains active and no confirmation record exists.” Evidence should show whether the alternative remains usable and whether “Download confirmation” reaches the represented state. The represented outcome is not reached, leaving the subscriber exposed to another charge.
What a fairer design does: Update the account state atomically, display the effective date and issue a durable receipt that support can verify.
Show annotated differences (2)
- Obscured outcome: Download confirmation: currentIn “Cancellation confirmation changes no account state”, this element shows how dead end can shape the decision.
- Request recorded: Download confirmationIn “Cancellation confirmation changes no account state”, this element keeps the clearer alternative visible at the same decision point.
Review questions (3)
- How many steps, waits and channel changes separate “Back to account” from the completed subscription account outcome?
- Count steps, waits, offers and channel changes through final confirmation; where does the route meet “Repeated execution cannot reach that outcome under controlled conditions”?
- Measure the same task through the clearest available route: does the effort difference persist once “validation error caused by invalid fixture input” is accounted for?
What is a fairer alternative?
Provide a functional completion route, preserve progress, and surface recoverable errors equally across options.
Legal and information status
Legal position at a glance
A consumer-favourable route cannot reach its represented outcome and instead loops, stalls or loses progress. A route represents that a request can complete but then loops, errors or changes no durable state, without a working recovery path or confirmation record. Risk increases where the mechanism changes a material consumer choice, hides a consequence or makes a genuine alternative harder to use. The taxonomy label remains a review prompt and does not establish an infringement.
Dark-pattern research taxonomy
Editorial analysis
The cited research sources support identification and comparison of this recurring interface mechanism. They do not determine that a particular interface is unlawful.
UCPD Articles 5 to 9, where applicable
Possible risk indicator
Depending on the trader, audience, overall presentation, material information and likely transactional effect, the facts may require a separate assessment under the applicable UCPD provisions.
Evidence layers and open questions
Applicable law, enforcement records, policy preparation, stakeholder input, editorial analysis and unknown future details remain visibly distinct.
Current lawCurrent law
The UX label “Dead end” is not a standalone EU offence. Depending on the trader, audience, complete presentation, omitted information and likely transactional effect, the observed facts may require a separate assessment under the applicable UCPD provisions or another instrument within scope.
Under considerationUnder consideration
The Commission is preparing a Digital Fairness Act initiative, but the call for evidence does not select a final rule for dead end or establish that this taxonomy term will appear in a proposal.
Editorial analysisEditorial analysis
The pattern definition, variants and examples on this page use the cited research taxonomy sources to support recognition and comparison. That analytical classification is not a legal conclusion about an individual interface.
UnknownUnknown
No published DFA proposal currently establishes a definition, covered actor, legal threshold, duty, remedy, transition rule or application date for dead end. Those details remain unknown pending primary legislative text.
Context matters
Context and boundary cases
- The interface represents or reasonably implies that the outcome is available.
- Repeated execution cannot reach that outcome under controlled conditions.
- A business-favoured route remains functional or the failure systematically burdens the alternative.
- Exclude or qualify the label where general outage affecting all paths.
- Exclude or qualify the label where validation error caused by invalid fixture input.
- Exclude or qualify the label where clearly unavailable option.
When a similar design can serve a legitimate purpose
- A similar design should not be classified this way where general outage affecting all paths.
- A similar design should not be classified this way where validation error caused by invalid fixture input.
- A similar design should not be classified this way where clearly unavailable option.
Operational review
What teams should review
- Teams
- How many steps, waits and channel changes separate “Try again” from the completed order support outcome?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “The interface represents or reasonably implies that the outcome is available”?
- Measure the same task through the clearest available route: does the effort difference persist once “General outage affecting all paths” is accounted for?
- How many steps, waits and channel changes separate “Back to account” from the completed subscription account outcome?
- Count steps, waits, offers and channel changes through final confirmation; where does the route meet “Repeated execution cannot reach that outcome under controlled conditions”?
- Measure the same task through the clearest available route: does the effort difference persist once “validation error caused by invalid fixture input” is accounted for?
- Which complete journey evidence supports or contradicts the dead end classification?
Evidence to retain
- Versioned captures of the Account Management and Cancellation states before, during and after the relevant decision
- Configuration, content and event records supporting the observed dead end mechanism
- Responsive, keyboard and assistive-technology review of every material option and consequence
- Control defaults, validation rules and consent or selection state changes
Legal map and implementation tools
Evidence base
Sources
- An Ontology of Dark Patterns KnowledgeGray et al.; ACM CHI 2024 · Secondary · checked 2026-09-14 · DOI 10.1145/3613904.3642436; arXiv:2309.09640
- Unfair Commercial Practices DirectiveEuropean Parliament and Council of the European Union · Primary · checked 2026-08-09 · Directive 2005/29/EC; CELEX 02005L0029-20220528
- Digital Fairness Act: call for evidence for an impact assessmentEuropean Commission · Primary · checked 2026-08-09 · Initiative 14622; Ares(2025)6275573
- Commission work programme 2026: Europe's Independence MomentEuropean Commission · Primary · checked 2026-09-14 · COM(2025) 870 final; CELEX 52025DC0870; Annex I item 30