Dark-pattern family · 6 patterns
Conditions access to a desired function on an additional action, disclosure or commitment that is not inherently required for the user's goal.
This family groups related interface mechanisms for learning and journey review. It is not a legal category and does not make every matching interface unlawful. Start with the mechanism, then examine the complete decision, audience, effect and EU rule actually within scope.
Recognition framework
Begin with the user’s stated goal, then list every additional action, permission, disclosure or payment required before that goal succeeds. For each dependency, record its functional purpose, whether a less intrusive route exists and what happens after refusal. The sequence matters: an optional request can become effectively forced when it appears after substantial effort or blocks an unrelated function.
Accounts, verification, payment and permissions can be necessary for a specific service. Classification should exclude dependencies that are inherent, proportionate and explained before data or commitment is requested. Convenience for the trader alone does not answer that factual question.
EU legal and policy context
A family name helps teams compare interface mechanisms. It is not an EU legal category, and similarity to an example does not establish that a current rule has been infringed or that a future Digital Fairness Act will use the same label.
The UCPD and any relevant sector instrument require their own scope, conduct, information and likely-effect assessment. The complete journey and evidence matter; a taxonomy match is only a prompt to investigate.
The Commission is preparing a legislative DFA initiative and currently places a proposal in Q4 2026. That planning date is indicative, and no published proposal yet creates a family-specific duty.
The call for evidence discusses possible policy responses to digital fairness concerns. Options, consultation questions and stakeholder submissions are not Commission proposals or present obligations.
Final instrument form, scope, definitions, thresholds, enforcement, transition and application remain unknown until primary legislative text is published and validated.
Journey coverage
Review the state before the decision, the controls and information available at that moment, the immediate result and any later account or billing consequence. Journey links below show where this family appears in the published taxonomy; they do not imply that every product or every stage contains the mechanism.
3 related patterns
Account settings determine whether earlier choices remain controllable. Privacy preferences, exports, deletion, support and content controls often span several channels and states. Review therefore needs to test persistence and actual system outcomes, not only whether a settings label or help article exists.
Open the journey guide →3 related patterns
Pricing review starts before checkout. Search cards, campaign landing pages, recommendation logic, comparison tables and membership offers can each shape the price a person understands. Teams should reconstruct the comparable payable amount, the basis of every saving or popularity claim and the information available when a product first becomes a realistic option.
Open the journey guide →2 related patterns
Signup is where access, identity, permissions and first-run choices meet. A useful review follows the user from the promise made before registration through every required field, default, consent request and first-use screen. The question is not whether signup is persuasive, but whether people can understand what is necessary, what is optional and what each control will do before they commit.
Open the journey guide →2 related patterns
Checkout concentrates price, add-ons, urgency, identity and the final payment action. Review should begin with the state carried into the basket and finish only when the order, receipt and account state agree. A control that appears clear in isolation can still be misleading when a fee arrives late, a removed item returns or the final button does more than its label predicts.
Open the journey guide →Pattern directory
Each detail page contains two fictional interface comparisons, practical recognition and exclusion criteria, a fairer alternative, review questions and a legal-status map that keeps editorial taxonomy separate from current law and the announced DFA process.
Content continues automatically or lacks meaningful stopping cues, reducing deliberate control over time and attention. 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.
2 visual examples
See visual examples: Automatic attention captureThe service extracts contact information, sends or prepares unwanted invitations, or ties functionality to recruiting other people. 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.
2 visual examples
See visual examples: Contact harvesting and coerced referralsAccess or progression is conditioned on disclosing personal information that appears unnecessary, excessive or used for an insufficiently explained secondary purpose. 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.
2 visual examples
See visual examples: Forced disclosure or excessive data requestAccess is conditioned on accepting optional or separable data uses, communications or permissions as one bundled choice. 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.
2 visual examples
See visual examples: Forced or bundled consentThe user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. 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.
2 visual examples
See visual examples: Forced registrationDesired functionality is practically conditioned on repetitive engagement or an additional payment not sufficiently clear at acquisition. 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.
2 visual examples
See visual examples: Gamified or paid access coercionEvidence-led workflow
Evidence base