Dead end
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.
Individual HTML example · Obstruction
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.
This is an original fictional comparison. It depicts no real company and is not a legal finding or safe harbour.
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)
Potentially problematic version
- Try againIn “Refund form loops after submission”, this element shows how dead end can shape the decision.
Neutral alternative
- 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?
Complete pattern context
How this example relates to Dead end
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.
The full guide explains inclusion and exclusion criteria, harms, fair design principles, evidence questions and the relevant EU legal information layers. The example page isolates one scenario so it can be shared and discussed without reproducing the complete library on one page.
Continue comparing
Related examples
Open this example
Account deletion obstruction
Deactivation presented as deletion
A fictional platform labels a control “Delete account”, but the confirmation only hides the profile and leaves data and reactivation available indefinitely.
Account deletion obstruction
Deletion buried behind an unsupported ticket
A fictional retailer places account deletion behind six help pages and requires a support ticket containing an order number even for users who never ordered.
Sources and provenance for this example
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