October 2026
Loss Aversion Flips the Default, 38% Keep the Risky Toggle
Why flipping a default setting can push 38% of users to keep a risky option enabled, and what loss aversion reveals about design
Imagine you run a small digital agency in Zagreb and you ship a settings panel that lets clients switch a feature on or off. The default is off, the safe choice. Then a colleague suggests flipping the default to on and asking people to opt out. You expect maybe a handful of objections. Instead, 38% of users keep the risky toggle enabled, even after you tell them, in plain language, that it may break their workflow. The number is not arbitrary; it is the kind of result that shows up repeatedly once loss aversion meets a default setting. The question this article asks is simple: why does flipping a default change what people choose, and what should anyone building websites and web products in Croatia do about it?
The short answer is that defaults are not neutral, and loss aversion is the reason. The longer answer runs through behavioral psychology, a handful of well-documented studies, and the practical design decisions that separate a product people trust from one they quietly resent. Croatia is a small, fast-moving digital market where agencies often build the same settings panels, consent dialogs, and onboarding flows for clients across tourism, retail, and public services. Getting the psychology right is not a luxury; it is the difference between a product that respects its users and one that harvests them.
The default is a decision, whether you admit it or not
Every settings panel embeds a recommendation. When a checkbox arrives pre-ticked, the interface is telling the user that the person who built it believes this is the right choice. Most users accept that recommendation without examining it. The classic demonstration is organ donation: countries with opt-out systems report dramatically higher consent rates than opt-in countries, and the gap is far too large to be explained by cultural attitudes alone. The default does the work.
This matters for web development because defaults are cheap to set and expensive to get wrong. A Croatian e-commerce site that pre-selects "subscribe to newsletter" at checkout will collect more addresses than one that leaves the box empty. The conversion difference is real, but so is the erosion of trust when customers notice they were opted in without thinking about it. The European Union's GDPR framework was built partly in response to exactly this pattern, and it requires consent to be freely given, specific, informed, and unambiguous. Pre-ticked boxes no longer count as valid consent in the EU. The regulation exists because the psychology is so reliable that it was being abused at scale.
The deeper point is that a default is a form of choice architecture. Richard Thaler and Cass Sunstein popularized the term, and their central claim is modest: how options are presented changes what people pick, even when the options themselves are identical. You cannot avoid designing a default. You can only decide whether you design it deliberately.
Why "off" feels safe and "on" feels like a gift
There is an asymmetry in how people evaluate the two states. Leaving a feature off preserves the status quo, and the status quo carries no perceived loss. Turning it on introduces the possibility of a loss, and losses loom larger than equivalent gains. This is loss aversion, one of the most replicated findings in behavioral economics, usually traced to Daniel Kahneman and Amos Tversky's work in the late 1970s and 1980s. The rough rule of thumb from their experiments is that losses feel about twice as painful as equivalent gains feel pleasurable.
Now flip the default. If the feature is on by default, the user is already in the "on" state. Turning it off now registers as a loss, because they would be giving up something they already have. The same toggle, the same feature, the same user, and the decision reverses. That is the mechanism behind the 38% figure. The toggle did not become more attractive; the reference point moved.
What the research actually shows about risky defaults
The most-cited real-world example is not a toggle at all. It is a retirement savings plan. In the early 2000s, researchers studied what happened when employers automatically enrolled employees in a savings plan rather than asking them to sign up. Enrollment jumped from roughly half of eligible employees to the high 80s or 90s, depending on the study. The default did not persuade anyone; it simply removed the need to act. Brigitte Madrian and Dennis Shea documented this in a widely cited 2001 paper, and the finding has held up across many subsequent studies.
A more directly relevant example comes from privacy settings. Researchers have repeatedly found that when a social platform or app defaults to sharing more data, a substantial share of users leave it that way, even when they express concern about privacy when asked directly. The gap between stated preference and revealed behavior is the interesting part. People say they care about privacy, and they do, but the cost of changing a default is a small friction, and small frictions beat strong preferences more often than we like to admit.
The 38% figure in the title is best read as a plausible outcome of this dynamic rather than a precise universal constant. In studies of opt-out defaults for behaviors users perceive as slightly risky, retention rates in the 30s to 50s are common. The exact number depends on how risky the feature sounds, how prominent the opt-out is, and how much the user trusts the product. What is stable across studies is the direction: flipping the default moves behavior substantially, and loss aversion is a major reason why.
The trust variable nobody budgets for
There is a catch that most conversion-focused advice ignores. Defaults work best when users believe the default was chosen for their benefit. When they suspect it was chosen for the company's benefit, the same default can backfire. A pre-ticked box that signs someone up for marketing emails is a different psychological object from a pre-ticked box that turns on two-factor authentication. The first reads as a trap; the second reads as a sensible recommendation from someone who knows more about security than the user does.
This is where the Croatian context matters. Domestic users are increasingly literate about consent dialogs, partly because GDPR enforcement has been visible and partly because the cookie banner fatigue is real. A Zagreb-based SaaS product that defaults to aggressive data sharing will be noticed, and the reputational cost in a small market is higher than in a large one. Word travels. The same loss aversion that makes users reluctant to turn a feature off also makes them reluctant to forgive a product that tricked them.
Designing defaults that survive scrutiny
The practical question for anyone building websites and web products is not whether to use defaults, because you will use them regardless. The question is which defaults you can defend in a conversation with the user. A useful test: would you be comfortable if the user saw a screenshot of your settings panel with the defaults highlighted, alongside a sentence explaining why each one is set the way it is? If the answer is no for any toggle, that toggle is doing work you probably do not want it to do.
There is a second test that is more useful for risky features specifically. Ask whether the default protects the user or exposes them. Defaults that reduce harm, like enabling security features, privacy-preserving settings, or backup reminders, are easy to justify. Defaults that increase exposure, like public profiles, data sharing, or auto-posting, need a much stronger case, and often the honest answer is that the case is weak.
When the risky default is genuinely the right call
There are legitimate situations where defaulting to the riskier option is correct. A developer tool that defaults to verbose logging is easier to debug than one that defaults to silence. A project management app that defaults to notifications on will annoy some users but will also prevent the more common failure of missed deadlines. The distinguishing feature is not riskiness per se; it is whether the risk falls on the user in a way they can reverse cheaply and understand clearly.
The design principle is reversibility. A default is far more defensible when the cost of undoing it is one click and the consequence of leaving it is visible. A default that quietly enrolls someone in something they cannot easily leave is a different category of design, and it is the category that regulators, journalists, and increasingly users are watching.
What this means for how you build in Croatia
Croatian web development has a particular texture. Many agencies are small, client relationships are long, and the same team often maintains a site for years. That continuity is an advantage when it comes to defaults, because you can observe the consequences. It is also a temptation, because a client who asks for "more conversions" is easy to satisfy with a pre-ticked box in the short term and hard to satisfy when the complaints arrive six months later.
The forward-looking move is to treat defaults as part of the product's ethical surface, not just its conversion surface. That means documenting why each default is set the way it is, reviewing defaults when the product's audience changes, and being willing to argue with a client who wants an opt-out default for something that should be opt-in. The argument is easier to win when you can point to the research: defaults move behavior, loss aversion makes the effect asymmetric, and users who feel manipulated do not come back.
A concrete example worth copying
Consider a Croatian booking platform for small tourism operators. The obvious default for a new listing is "public," because public listings get bookings. But a listing that goes live before the operator has reviewed it can expose incomplete pricing or unavailable dates, which produces bad first impressions and refund requests. A better pattern is to default to "draft" and require one deliberate action to publish, with a clear checklist. The operator feels in control, the platform avoids embarrassing errors, and the conversion cost is small because the publish action is a single click with a visible payoff.
This is the pattern to internalize: when the risky state is easy to reach and the safe state is easy to leave, the default matters less. When the risky state is hard to reverse, the default matters enormously. The 38% retention figure is a warning about the second case, not the first.
The forward-looking part: build for the second click
The most useful thing you can take from the behavioral research is not a trick for boosting opt-ins. It is a design habit. Assume that a meaningful fraction of your users will accept whatever default you set, and that a meaningful fraction of those will never revisit the decision. Then ask what you want that silent majority to end up with. If the answer is "the thing that benefits them," set the default accordingly and make the opt-out obvious. If the answer is "the thing that benefits us," you have found the toggle that will eventually cost you more than it earns.
Loss aversion explains why the toggle is sticky. It does not tell you which way to point it. That part is a judgment call, and it is the part that separates products people recommend from products people tolerate. In a market as relationship-driven as Croatia's, the second click, the one where a user goes back into settings and changes something, is where trust is either confirmed or quietly withdrawn. Build so that the second click is easy, and the first one will be easier to defend.