Eclept

Back

Dark Patterns as a Business Model: The Engineering Ethics of Conversion at Scale

Ivan Lazarević
Ivan Lazarević
July 20, 2026

15 min read

You plan to go to the FIFA World Cup 2026. You sit and choose a city, then start looking for tickets. The website shows you a price, but you have to make an account. While you were doing so, prices jumped by 10%. By the time you came to the checkout page, they jumped another 5%.

 

Then you try to book the airplane tickets. The website shows only 2 spots left on that date, with prices double what they usually are. Then you go to look for accommodation, the platform claims that 57 other people are also looking at that same hotel room. And the prices just get higher. Does this sound familiar?

 

Modern software rarely becomes “manipulative” by accident in the simplistic sense. There is almost never a meeting where a team explicitly decides to deceive users.

Instead, something more subtle happens.

Companies define success in metrics. Engineering builds systems to optimize those metrics. Product iterates on what improves them. Data validates the uplift. And over time, the user experience converges toward whatever configuration best improves short-term outcomes.

 

Dark patterns are what this convergence looks like in the real world.

What are Dark Patterns?

Dark patterns are user experience design techniques intentionally created to influence users into making decisions that benefit the business, often at the expense of the user’s interests, autonomy, or informed consent. Unlike good usability practices, which reduce friction and help users achieve their goals, dark patterns introduce friction selectively. They make desirable business actions easier and undesirable user actions more difficult.

Common examples include:
  • Infinite scroll and autoplay on social media platforms, which encourage users to consume content continuously without natural stopping points.

  • Loot boxes, battle passes, daily rewards and limited-time events in video games, designed to encourage habitual play and make players feel they might miss exclusive rewards.
  • Hidden fees in booking engines and ticketing platforms, where mandatory service charges or processing fees are only revealed at the final stage of checkout.
  • Countdown timers and scarcity messages, such as “Only 2 rooms left” or “15 people are viewing this item,” which create urgency and pressure users into making quicker purchasing decisions.
  • Subscription traps, where signing up for a free trial takes a few clicks, but cancelling requires navigating multiple screens, contacting customer support, or waiting through mandatory retention offers.
  • Asymmetric feedback flows, where leaving a five-star review takes a single tap, while submitting a lower rating requires answering multiple questions or navigating additional screens.
  • Pre-selected add-ons during checkout, such as travel insurance, extended warranties, relying on users overlooking default selections.
  • Confirmshaming, where declining an offer is accompanied by emotionally manipulative language such as “No thanks, I don’t like saving money.”
Individually, these techniques may seem relatively harmless.

Collectively, however, they illustrate how software can be deliberately engineered to steer user behavior toward business objectives rather than empowering users to make informed decisions. As software becomes increasingly data-driven and optimized through experimentation, dark patterns have evolved from isolated UI tricks into systematic business strategies embedded within modern digital products.

Dark Patterns as an Engineering Output of Incentives

It is tempting to think of dark patterns as just UI tricks. 

A hidden button. A confusing checkbox. A guilt-inducing message. 

In modern software organizations, user experience is not a static artifact designed once. Instead, it is continuously recomputed through experimentation systems.

 

A more accurate mental model is: User experience is the result of a data-driven loop operating on business-defined objectives.

 

That loop typically looks like this:

 

    1. Product defines a KPI (e.g., increase conversion by 10%)
    2. Engineering builds instrumentation and experimentation infrastructure
    3. Data teams evaluate A/B tests
    4. Winning variants are rolled out
    5. The system updates itself based on observed uplift

At no point in this loop is “user understanding” a required input. It may be considered qualitatively, but it is rarely a hard constraint.

 

The key insight is uncomfortable but important: Dark patterns persist not because they are persuasive, but because they are measurable.

 

If a design increases conversion and does not violate explicit legal constraints, it is likely to survive, even if it reduces trust or creates long-term dissatisfaction.

The Business Case for Dark Patterns

To understand why dark patterns persist, it is necessary to acknowledge that they often work, at least in the narrow sense that matters to dashboards.

 

Consider a simple example: adding friction to cancellation. If making cancellation harder reduces churn by even a small percentage, it can significantly increase recurring revenue. From a purely financial perspective, this can look like a clear win. This is not a hypothetical benefit. This is repeatedly validated through experimentation systems in many industries.

 

However, benefits like this are often locally optimal but globally destructive. They improve a single metric in isolation while degrading customer trust, brand reputation, refund rates, regulatory exposure and long-term retention quality.

 

The core issue is not that these techniques work. It is that they work for a narrowly defined definition of success.

The Psychology Behind Predictable Conversion Gains

While not all dark patterns are illegal, they exploit weak principles of human psychology. They have become increasingly sophisticated as companies leverage analytics, A/B testing, personalization and behavioral data to optimize user behavior.

 

Dark patterns are effective because they align with well-documented cognitive biases:

 

  • Loss aversion: people strongly prefer avoiding losses over acquiring gains
  • Default bias: people tend to accept pre-selected options
  • Anchoring: initial numbers heavily influence perception of value
  • FOMO (fear of missing out): urgency increases decision speed
  • Sunk cost fallacy: prior investment increases commitment
  • Choice overload: too many options reduce decision quality
None of these mechanisms are inherently exploitative. They are part of human cognition.

The ethical issue arises when systems are explicitly designed to exploit these biases without informing users or balancing comprehension with persuasion. In such cases, the interface stops being a neutral medium and becomes an active participant in shaping decisions.

Why Engineering Teams Rarely Push Back

A common assumption is that engineers would resist manipulative design if they were aware of it. In practice, resistance is more complicated. And several structural factors reduce pushback:

 

    1. Abstraction of responsibility – engineers often implement requirements rather than define them. If a system is configurable, they may not see the final user-facing combinations.
    2. Metric isolation – engineers are frequently evaluated on delivery, performance, uptime, and feature completion, not ethical outcomes.
    3. A/B normalization – experimentation usually frames all outcomes as neutral data comparisons. If variant B increases conversion, it is considered “better,” regardless of qualitative differences.
    4. Competitive pressure – if competitors use aggressive optimization tactics, internal restraint can feel like self-sabotage.
    5. Organizational distance – by the time a decision reaches implementation, it may have passed through multiple layers of abstraction.
The result is not ignorance but a structural diffusion of accountability.

Is There “Going Too Far”?

The controversy surrounding PayPal’s Honey browser extension provides an interesting case study.

Honey built its reputation as a shopping assistant that automatically searched for coupon codes and helped users save money. However, in late 2024, content creators and affiliate marketers accused the extension of exploiting the affiliate marketing ecosystem in ways that primarily benefited Honey rather than the user. Among the allegations were that Honey would replace affiliate tracking links at checkout (even when it did not find a better coupon) and that it would sometimes prioritize coupon codes provided by partner merchants instead of surfacing the best discounts available. These practices are now the subject of multiple lawsuits, and Honey has disputed many of the allegations.

Whether the courts ultimately determine that Honey’s practices were unlawful is less important for the purposes of this discussion. What makes the controversy relevant is that the software was reportedly behaving exactly as it had been designed. There was no security breach, no implementation bug, and no rogue engineer. The behavior reflected business rules translated into code.

From an engineering perspective, this is where the ethical discussion becomes far more interesting than the legal one. Replacing an affiliate cookie, selecting which coupon to display, or attributing commissions are all technically valid features. Individually, each implementation decision may appear harmless. Collectively, however, they can create a system that users perceive as working in their interest while silently optimizing for entirely different business objectives.

The Honey controversy illustrates an important distinction. Software can be fully functional, technically correct, and legally defensible, yet still violate the expectations and trust of its users.

That is the point where optimization ceases to be merely a business strategy and becomes an engineering ethics question.

The Regulatory Shift

Over the past decade, regulatory bodies have begun to recognize that user interface design can be deceptive even when technically compliant. Regulators such as the European Commission, through frameworks like the Digital Services Act, and agencies such as the Federal Trade Commission, have increased scrutiny of manipulative digital practices. Additionally, privacy frameworks like the General Data Protection Regulation(GDPR) have reshaped consent mechanisms and data transparency requirements.

Importantly, these regulations do not simply target fraud. They increasingly target interface behavior that distorts user choice. This signals a broader shift:

What was once considered growth optimization is becoming compliance risk.
The System You Build Is the Behavior You Get

Dark patterns are often discussed as isolated UI tricks or ethical lapses in design. But in modern software systems, they are better understood as emergent properties of incentive-driven architectures.

 

When organizations optimize aggressively for measurable outcomes without equally rigorous constraints on user autonomy and transparency, the resulting systems will reliably converge toward manipulation. Not because individuals intend it, but because the system rewards it.

 

Engineering teams are not just building interfaces. They are building the infrastructure that determines how decisions are shaped, filtered and presented at scale.

 

And once that is understood, the ethical question becomes unavoidable: If we can precisely optimize user behavior, what responsibility do we have for the form that optimization takes?

 

The answer to that question will define not just UX design, but the next generation of engineering ethics.

Ivan Lazarević

Chief Strategy Officer, Eclept

ECLEPT

Have questions?

Let’s build something great together!

30 min

Meet

“Every successful project starts with the right conversation. We’re here to listen, strategize, and find the best way forward—together.”

Boris Petelj

CTO

boris@eclept.com