Default Dominance: Most Users Never Change the Setting You Ship
Summary: Defaults decide what most users experience and teach them what to consider normal, so leaving a setting unchanged tells you little about its quality. Choose defaults that minimize harm and preserve future choices; with AI, make consequential assumptions visible and define the agent’s authority before delegating. The 17 guidelines below turn these principles into design decisions.
A default setting exerts a powerful pull on users.
Here’s a number that should make every designer sit up straight. When one large U.S. company switched its 401(k) retirement plan from opt-in to automatic enrollment, participation among new hires rocketed from 37% to 86%, as Brigitte Madrian and Dennis Shea documented in their 2001 Quarterly Journal of Economics study. The financial terms stayed the same; the enrollment procedure changed. Participation more than doubled because the company changed what happened when employees did nothing. That’s an astonishing return on a decision made before anyone fills out a form.
Changing the default setting more than doubled the number of employees who participated in a corporate retirement plan.
This is default dominance: the tendency for the preselected option to become the user’s eventual choice, whether or not it serves his or her needs. The effect reaches far beyond the checkbox. Default dominance is one of the strongest forces in user behavior, and most designers deploy it without thinking about the stakes.
The Choice Made by Not Choosing
Definition: A default is the value, option, or state a system adopts when the user takes no explicit action. Familiar examples include the preticked box, the preselected radio button, the shipping method already highlighted, and the privacy setting your app arrives with, straight out of the box. A smart default goes further: it’s computed from context (locale, location, past behavior, the task at hand) to match what this particular user would most likely pick.
Every choice has an outcome if the user does nothing, even when you haven’t preselected an answer. Inaction has consequences. If your form leaves a field blank, blank is the default. If your dropdown opens on the first item, that item is the default. For users who never open settings, the defaults are the product. Configuration is a feature they’ll never experience. You’re making this decision whether or not you’re paying attention. So pay attention.
Defaults attract user behavior. (GPT Image 2.5)
Used well, defaults are a gift to the user. They cut the number of decisions a person has to make, and decisions are expensive. A well-chosen default lets the user glide through a task, stopping to think only where his or her situation differs from the common case.
Consider the checkout that defaults to the shipping address already on file, the editor that opens in your last-used font, and the signup form that infers your country instead of making you scroll through a 200-item menu starting with Afghanistan. Every field the user needn’t touch is time returned to him or her and one fewer chance for a typo.
Keeping the default saves the user both work and deliberation. That’s a usability boon, provided the design team chose the default value with care.
The name is older than computing and unusually honest. “Default” comes from the Old French defaute, a failure or a lack, the same root that gives us defaulting on a loan: a defaulter fails to appear, to pay, to act. The interface default is precisely the value you receive by failing to act, and since users came to accomplish a task rather than configure your software, the default usually wins.
Etymology: The word “default” comes from Old French and originally meant “a failure to do something.”
The Evidence: Organ Donors, Lost Documents, and a $20 Billion Receipt
Eric Johnson of Columbia University and Daniel Goldstein published “Do Defaults Save Lives?” (PDF) in Science in 2003, comparing organ-donation policies across European countries. Germany’s opt-in system had an effective consent rate of 12%; Austria’s opt-out system exceeded 99%. The contrast is striking, but consent is only one step toward a completed donation.
Mattea Dallacker and co-authors reported in Public Health in 2024 that deceased donation rates didn’t increase after 5 countries switched to opt-out. Families, staffing, and infrastructure still influence whether consent produces a transplant. Follow the outcome beyond the checkbox: registration delivers the intended benefit only when the people and processes that follow can turn consent into a transplant.
This cartoon goes overboard: of course, it should be easy to change a default setting.
Closer to our screens, Jared Spool reported in 2011 on an earlier study of several hundred users’ Microsoft Word settings files: fewer than 5% had changed any setting at all. The version in that study shipped with autosave off, so more than 95% of users faced every program crash without that safety net. When interviewed, they explained that “Microsoft must know what they are doing.”
That sentence should hang framed above every product team’s door. Users treat your defaults as your professional recommendation, delivered with the full authority of your brand. (Microsoft 365 now enables AutoSave by default for eligible cloud documents. Progress.)
Users assume the vendor has chosen wisely. In Spool’s account, a programmer had simply initialized the settings file with zeros, expecting somebody to supply the real defaults later. Nobody did. An implementation shortcut became a recommendation in the user’s mind. Defaults therefore need an owner who answers for their quality: otherwise, whatever was easiest to code becomes the decision millions of people must live with.
The evidence extends far beyond these examples. Jon Jachimowicz and co-authors ran a meta-analysis of 58 default studies covering a combined 73,675 participants and found an average effect size of d = 0.68. By conventional benchmarks, d = 0.5 is a medium effect size, whereas d = 0.8 is large. The effect varied across decisions and settings, so this substantial average gives designers no warrant to assume a universal 95% acceptance rate.
The meta-analysis found stronger effects when defaults conveyed endorsement (the designer recommends this) or endowment (this already belongs to me). Alongside the effort saved, these messages help explain why a small checkmark can carry such weight in the user’s decision.
And if you want the market price of a default, court filings in the U.S. antitrust case against Google revealed that Google paid Apple a staggering $20 billion in 2022 to remain the preselected search engine in Safari. Microsoft offered Apple 90% of Bing’s ad revenue for the same search slot, but Apple turned it down. That price reflects the traffic a preselection can retain, even when changing it is technically possible.
Being the default search engine in Apple’s browser is worth a fortune, but only because most users never bother changing this setting.
A related pattern is Google gullibility, the tendency for users to visit whatever website ranks at the top of Google’s search engine results page (SERP): Cornell eye-tracking studies by Thorsten Joachims and colleagues showed that users kept clicking the first result even after the top two results were secretly swapped (PDF). Rank acts as an implied recommendation. The user still has to click, yet the ranking channels attention toward the answer the system has already elevated.
One underlying force is status quo bias, named by behavioral economists William Samuelson and Richard Zeckhauser in 1988. The design consequence is default gravity: users orbit whatever value ships preselected, and escaping that orbit costs effort, the scarcest resource in any interface. Change requires understanding the setting, predicting the consequences, and accepting responsibility for the outcome. Keeping the default requires nothing.
The Ancestral Origins of Default Acceptance
Why is default gravity this strong? I suspect part of the answer lies in strategies for trusting other people’s knowledge that long predate software.
Start with the economics of attention. Evaluating an unfamiliar option consumes time and effort that users could spend on their actual task. Keeping the given state can be a sensible bargain when the expected improvement is small or hard to judge. Modern users make that bargain when they satisfice instead of optimizing. The crucial cost is discovering whether a change is worth making, which can dwarf the effort of clicking the alternative.
Next, the information economics of the tribe. A forager rarely had the data to evaluate options from first principles. Prevailing practice answered the everyday questions: which plants were safe, which waterhole the predators favored, and which route crossed the river. It encoded generations of trial and error, with the fatal errors subtracted from the population.
Robert Boyd and Peter Richerson’s work on conformist transmission explains why copying the majority can be advantageous when individual learning is costly and the environment is stable. The default was the accumulated wisdom of everyone who had survived long enough to pass it on.
The costs of a mistake were lopsided, too. Trying the unfamiliar mushroom offered a modest upside (a new food source) against a catastrophic downside (death before dinner was over). Sticking with the known berry cost nothing. When losses outweigh gains this heavily, caution makes sense. My inference is that familiar choices offered a useful shortcut when the cost of discovery exceeded the likely benefit. A user staring at an unfamiliar settings panel faces a gentler version of that bargain.
The familiar mushroom offers a known meal; the unfamiliar one requires knowledge the forager may lack. A software user faces the same practical question: is discovering the alternative worth the risk of getting it wrong?
Finally, defaults carried social information. The way things are done is the way the knowledgeable have chosen to do them: the elder, the master toolmaker, the successful hunter. Deferring to the choices of recognized experts (what Joseph Henrich and Francisco Gil-White termed prestige-biased learning) was a shortcut to competence that usually paid off. Spool’s Word users saying “Microsoft must know what they are doing” illustrate the same logic of deference, with a software vendor cast in the role of tribal elder.
These evolutionary accounts offer a useful lens on default acceptance, which still mostly serves users well. The mismatch is between the knowledge users infer and the process that actually produced the setting: a software default may reflect accumulated expertise, a rushed implementation, or a business model. Users extend paleotrust to your settings screen: trust in established practice, now aimed at a checkbox. The interface makes those origins look identical. Your design process must supply the judgment users assume is already there.
Every Default Is a Lesson
Defaults do more than decide outcomes. They teach. For a novice, the default is a free lesson in what a reasonable, mainstream answer looks like: the camera’s auto mode teaches typical settings, the preset privacy level teaches what people normally share, the suggested tip buttons teach the going rate, and the calendar that defaults new meetings to 30 minutes teaches the world that meetings last 30 minutes.
Craig McKenzie and colleagues at UC San Diego demonstrated the mechanism in 4 experiments (PDF): people interpret the default as the recommended course of action and infer the designer’s attitude from the option the designer preselected. Every default is a recommendation, whether you meant it or not.
This teaching power is mostly a gift: a thoughtful default embeds the designer’s expertise (the sane compression level, the right retry count) so the user needn’t acquire it. Expertise does its best work when users can benefit from it immediately.
The designer has anointed the default value as the golden option, and users know it. A good default teaches users which choice is usually reasonable for the task in front of them.
But a lesson can anchor as well as inform. Anchoring is one of the best-replicated findings in behavioral economics (see my article on behavioral economics for UX for the full tour): a number placed in front of a person can tug his or her judgment toward it, even when the number is arbitrary.
Madrian and Shea’s retirement study also shows how a helpful default can leave users saving too little. Automatic enrollment doubled participation, but employees then clustered at the plan’s default contribution rate of 3% and its conservative default fund; the authors found evidence that some employees interpreted these defaults as investment advice. The same lever that rescued participation quietly anchored savings too low. A default anchors from both sides, lifting those who would have done less and lowering those who would have done more.
One way forward was to let the default change over time: Richard Thaler and Shlomo Benartzi’s Save More Tomorrow plan let employees commit in advance to contribution increases tied to future pay raises; participants’ average savings rate climbed from 3.5% to 14% in 40 months. A default can take the form of a schedule the user agreed to in advance.
The paradox of the active user holds that people like to jump right in and start using software without spending time up front on setup tasks such as adjusting settings. Unfortunately, most users also never get around to visiting the settings later, so the original defaults remain in place.
Tipping screens run this experiment on you daily. Kareem Haggag and Giovanni Paci analyzed over 13 million New York City taxi rides and found that the suggested-tip buttons strongly shaped what riders paid: higher suggested amounts raised average tips, but they also pushed more riders to punch in zero. An anchor set too aggressively breeds resentment and backfires.
And the lesson can outlive the setting. A team that builds its workflow around 30-minute meetings acquires calendars, habits, and expectations that make a later switch costly. Default gravity strengthens as habits accumulate. A default chosen to serve the business can likewise become the user’s learned preference, even though its original purpose was to hit a revenue target. Thus, defaults shape future demand as well as satisfy present demand. Audit what users learn and build around the setting, alongside what they select today.
Learned preference: an arbitrary starting point can become the expected way to work.
Best Default = Likeliest Choice + Lowest Regret
So which option should you preselect? The standard advice is to consult behavioral data and preselect the most common choice, known as the mode. That’s a sensible place to start.
The giraffe likes this default choice, but we should look at behavioral data to check how well it works for other users.
But treat that data with suspicion, because your current default contaminates it. Word users running with autosave off weren’t voting for data loss. Your analytics may be recording a pseudopreference: your own default echoing back as apparent demand. For safe, reversible decisions, compare randomly assigned defaults with an active-choice condition and measure task success, recovery work, and later regret. If changing the preselection changes the apparent preference, you’ve measured steering power. Whether that steering helped requires outcome data. Users who override defaults and those who submit support tickets offer useful clues, but neither group represents the silent majority.
Most people never change the default. That tells you what they inherited; discovering what they actually prefer takes more work.
Second, weigh how much each wrong choice costs. Suppose 60% of users want option A and 40% want option B, so defaulting to A is “right” more often. Now estimate the cost of being wrong: if someone who wants B loses an hour of work when stuck with A, while someone who wants A loses 5 seconds when stuck with B, the arithmetic flips, and B is the better default despite being the minority choice. Across 100 users who retain the default, A costs 40 hours; B costs 5 minutes. Optimize for the lowest total regret.
Better still, redesign what happens when the choice is wrong: autosave combined with version history preserves work while allowing unwanted changes to be undone. A good default protects the next choice as well as the current one. This matters most when users will know more later: save a draft before publishing, preserve the original before transforming it, and let experience inform the final commitment. The value of waiting comes from what the user can learn while the decision remains reversible.
Leaving autosave off by default can cost users months of work in a single crash, all because of a setting they never touched.
Third, climb the personalization ladder only as high as your confidence reaches: the user’s explicit standing preference first, then the last choice in the same context, then the value inferred from his or her context (the detected country, the saved address, the current month for a monthly report), then the segment’s favorite, then the population mode. When the signal is weak, step down a rung to a more dependable choice.
And when the user overrides you, remember the scope: “this time” and “from now on” are different instructions. Within that scope, reasserting a rejected guess converts a convenience into a fight, as anyone who has dueled with autocorrect knows.
Two hazards climb the ladder with you. A smarter default is a more plausible one, and plausibility lulls users into accepting it: a tailored guess can discourage the very checking that would reveal its error. And a smart default trained on pseudopreferences (behavior that the old default itself shaped) launders the old default into a supposedly personalized one.
Even if your name isn’t Dick, it’s maddening when a system keeps reinstating the same default setting after the user has overridden it multiple times.
Fourth, when the user’s interests and the business’s interests diverge, let the user’s interests set the default. Betrayed users churn, and a short-term conversion gain can buy you a long-term retention problem. Treat the default as a decision entrusted to you: the user has spent attention elsewhere because he or she expects you to exercise sound judgment. You’re responsible for earning that trust, even when an unchanged setting tells you nothing about whether the user knowingly agreed with your choice.
And whatever the default, make the alternative visible and one click away. Even the best default is wrong sometimes (otherwise, why have the choice in the first place?), and users who need something else should reach their option in one obvious action. Burying that option deep in the settings defeats the purpose. Default gravity already makes every change an uphill climb; a hidden override steepens the slope until users give up.
Your guess should save time when right and cost almost nothing when wrong. Reversibility belongs in the design of the default itself: a one-click switch can’t retrieve data already disclosed or undo a nonrefundable purchase.
Then measure what happens. My rule of thumb: when more than 1/4 of users change a default, investigate. The problem may be the default, the situations in which it applies, or the assumption that one value should serve everybody. A low override rate proves little: users may be satisfied, unaware, or unable to find the control. Measure how much recovery a mistaken preselection requires, and inspect outcomes for users who never touch it. Repeat the audit as tasks change.
Keep separate records of values users actively selected and values they merely inherited; without that distinction, tomorrow’s personalization will treat yesterday’s silence as an instruction. When replacing an old default, preserve explicit choices and distinguish them from inherited settings. Silently replacing both with the new default erases the very preferences you claim to respect.
Choose the strategy that fits the situation:
When No Default Is the Right Default
Sometimes the correct preselection is none at all. Gabriel Carroll and co-authors quantified the alternative in the same retirement context: requiring new hires to make an explicit yes-or-no 401(k) decision, with no default either way, raised initial enrollment by 28 percentage points over standard opt-in. After 3 months, this approach produced a savings distribution that standard opt-in needed 30 months to reach.
Active decisions win when preferences vary widely and the stakes justify the effort. Nobody gets defaulted into a choice that’s wrong for him or her, and requiring an answer still defeats procrastination.
Require an explicit choice in 4 situations. First, require verified input for safety-critical data such as blood type, allergies, or drug dosage. Never invent a plausible value for these fields. Identify verified patient data as such and check it through the appropriate workflow; a generic guess invites rubber-stamping. The most dangerous default is a plausible one.
Second, ask when consent or spending authority hasn’t been established. Preselection can’t supply permission the person never gave.
Third, ask when forced-choice data shows preferences splitting down the middle on a decision that matters. Either preselection would ill-serve half your users while teaching them that it’s the recommended answer.
And fourth, ask when engagement is the point, as with naming a beneficiary or setting a recovery contact. In these cases, the thinking is the task.
Active choice has a cost, though: it taxes every user with a decision, which is exactly what good defaults exist to prevent. So ration it: reserve the interruption for decisions worth a user’s full attention, and let defaults carry the rest. Ask only when the answer can change what the system should do.
Timing matters as much as rationing. A preference question at signup goes to the person least qualified to answer it: someone who hasn’t used the product yet. Ask at the moment the setting first matters, when the user has enough context to make an informed decision.
A related case deserves mention: the confirmation dialog for a destructive action has a default (the button activated by the Enter key), and that default must be the safe option, typically Cancel. Here, safety calls for a deliberate preselection. I discuss the details in my article on the 10 core GUI design elements.
Destructive actions should have a very safe default for the many users who don’t read the confirmation dialog boxes but simply hit Enter.
The Dark Side of the Pedestal
Because defaults are this powerful, they attract abuse. The classic scam is pretickery: the preticked add-on (travel insurance, an extended warranty, a recurring newsletter) quietly checked in the purchase flow to extract money and consent from people who never chose it. They simply didn’t notice, which is exactly what the design counted on.
Regulators noticed instead. The EU’s Consumer Rights Directive banned preticked boxes for extra payments across Europe in 2014, and the Court of Justice of the EU ruled in the 2019 Planet49 case that a preticked box can’t constitute consent to cookies under the GDPR. Across a large chunk of the world, that deceptive little checkmark can also become a legal liability.
Privacy-hostile defaults do damage at an even greater scale. Ship an app with sharing switched on and visibility set to public, and you’ve made a choice for millions who would have chosen differently if asked. In January 2018, a global heatmap published by the fitness app Strava drew attention because it exposed the layouts of military bases through shared activity data: Nathan Ruser, an Australian National University student, spotted them as glowing jogging loops in an otherwise empty desert.
A routine decision to share exercise data had a consequence users could easily miss: aggregated routes revealed sensitive locations. “They can turn it off” is no defense; the whole point of default dominance is that most of them won’t. (Strava did simplify its privacy settings after the story broke. Help arrived after the jogging routes had lit up the map.)
Data shared by default, showing many people running in a supposedly empty area, revealed the location of military bases in the desert.
Then there’s the double-negative checkbox (“Uncheck this box if you do not want to not receive emails”), which weaponizes the default by making the override hard to parse. User-hostile, plain and simple.
Some of the darkest design patterns hide in the wording of an innocent-looking checkbox. Tangled sentences reverse my guidelines for UX writing by combining double negatives with passive constructions until users can barely tell which action they’re authorizing. A checkmark should mean that something will happen (here, that the user will receive emails). A user-friendly default should leave the “receive email” box unchecked.
The fix requires choosing on the user’s behalf without pretending that silence is permission. Default to privacy protection, leave optional charges unselected, and require an affirmative decision before adding obligations. Judge the result by what a fully informed user would want to retain after experiencing the consequences. A higher acceptance rate is easy to manufacture. Designing an outcome users are glad to live with takes better judgment.
AI Answers Are Made of Defaults
A prompt box looks like the opposite of a settings screen: no checkboxes, no dropdowns, nothing preselected. Don’t be fooled. The response that comes back is a stack of defaults from top to bottom: default length, default tone, default structure (those eternal bullet points), default reading level, default language variant, default model, default caution. You specified none of them, so the system chose all of them.
Many of these choices start out of sight, in the system prompt: the vendor’s instructions that help shape the answer before you type your first word.
AI is a magic genie that grants you many more than three wishes. But just as in the stories, anything you leave unsaid in your wish gives the model and its instructions room to decide the details for you.
King Midas should have read the system prompt before asking Dionysus to make everything he touched turn into gold. No more edible food for the king. (Muse Image)
A short prompt leaves much unspecified, and the AI fills the gaps. Ask for “an email to my team about the deadline,” and the model supplies a tone, a length, and a degree of apology. Those are presentation choices. Moving the deadline changes the commitment. Good AI design distinguishes what can reasonably be inferred from what requires the user’s decision, then states consequential assumptions where the user can correct them (“I assumed the deadline stays Friday”).
Many tendencies emerge from training rather than an identifiable checkbox. Their origins may be difficult to trace, but designers can still test their effects, and the vendor remains responsible for the behavior it ships. A fluent explanation generated after the fact can’t replace a record of which settings and instructions the system actually applied.
AI should make its defaults easy to inspect and easy to change. In this case, the young product manager prefers a slightly less corporate tone of voice when emailing his team.
The teaching effect grows with the audience. A default teaches users what a reasonable, mainstream answer looks like, and an AI answer delivers that lesson in full prose to hundreds of millions of people using the same handful of models. The first draft you receive anchors your sense of what a good answer looks like, encouraging you to edit within its frame instead of rethinking the problem. One system prompt nudging answers across an entire user base can turn a house preference into conventional wisdom on a scale no preticked checkbox ever achieved.
A further risk arises when generated text feeds later training. Ilia Shumailov and co-authors demonstrated model collapse under recursive training conditions in Nature in 2024. The UX implication I draw is to protect exploration before a repeated starting point becomes the only answer users consider. So AI designers should treat judgment calls the way good defaults treat split preferences: offer meaningful alternatives, and label opinions as opinions.
Agentic AI Buries the Defaults Inside Skills
With agentic AI, the number of defaults explodes. An agent booking a trip or refactoring a codebase can make hundreds of small decisions per run, supplying whatever you left unspecified: which airline, which test framework, which sources count as trustworthy. That’s the point of delegation.
But an agent also encounters defaults set by other businesses. A hotel’s preticked upgrade expresses the hotel’s preference; it gives the agent no authority to spend your money. The agent should check these defaults against your instructions before allowing a hotel’s sales tactics to become part of your booking. Delegation should give users an advocate at every checkbox.
Increasingly, those defaults live in skills: reusable instruction files that tell an agent how to perform a category of work. A skill supplies defaults wholesale. My own article-production workflow runs on a skill file that encodes dozens of standing decisions (heading style, number formatting, which words are banned). I state them once, and they apply whenever I ask the agent to produce an article. That’s the productivity win.
But a default I wrote months ago can silently govern today’s output long after my needs have changed. Skills therefore need an owner, a version, and a review whenever the task or model changes. Review how the instructions interact, too: “choose the cheapest fare” and “avoid asking questions” may each sound efficient, yet together they can turn an unresolved travel requirement into a booked mistake. Individually sensible defaults can become a collective blunder.
This weakens a saving grace of GUI defaults: visibility. A preselected radio button appears at the moment of decision, close to the alternative. A default buried in a skill file, a system prompt, or training is a deepfault, invisible at the point of use.
The default stack includes trained tendencies, vendor instructions, company configuration, skills, memory, and your request. Higher-priority instructions can constrain what a user’s request changes, so users need to know which preferences they can edit and which rules the system enforces. Otherwise, “just prompt it differently” sends users hunting for an override that may not exist, however many times they rewrite the prompt.
AI default settings lie buried many levels deep, where most users never see them. Many users don’t even know that anything exists below the surface of the prompt box.
This leads to three design requirements. First, make consequential defaults inspectable where they affect the result, with their source and a simple override when one exists. Summarize the few that could change the decision; an inventory of every hidden parameter merely creates another settings screen nobody reads.
Second, establish the agent’s mandate before execution: permitted actions, spending limits, recipients, and conditions that require a new decision. Then let it work within that authority. Asking again at every step defeats delegation and trains users to approve by reflex.
Third, interrupt when the proposed action exceeds the mandate or an unresolved assumption could materially change the result. “Book a refundable room under $250” authorizes a purchase within those limits; a nonrefundable bargain requires a new decision. The need to ask follows from what the user is committing to, however few clicks it takes to get there.
The commercial battle over defaults will intensify, too. Google paid $20 billion in 2022 for one browser default. The EU has already applied the no-default remedy to this kind of placement: the Digital Markets Act requires designated gatekeepers to offer choices for services including browsers and search engines; Apple implements a browser choice screen for eligible EU users. The user chooses once, and that choice becomes the default thereafter. Active choice establishes the mandate, and defaults carry it out.
The defaults inside agents (the default search tool, the default store, the default booking service) decide where transactions land. I predict that the coming decade’s antitrust fights will move from browser defaults to the defaults governing these agents and the purchases they make on our behalf.
17 Design Guidelines for Defaults
Provide a default wherever a safe one exists. Each field the user can skip returns time to him or her and removes one chance for a typo.
Default to the modal user’s best interest. Use independent choice and outcome data, then account for the cost of being wrong.
Make the default safe if never noticed. Design for users who never inspect settings; saving work with recoverable versions is a sound starting point.
When error costs are asymmetric, default to the cheap mistake. Minimize total regret, including recovery work and lost future options. Improve reversibility before settling for a lesser harm.
Require permission before adding obligations. Leave optional charges and consent boxes unselected; default to privacy protection. A remembered payment method doesn’t authorize a new charge.
Require an active choice when a consequential decision has no safe default or users’ preferences differ widely. When a wrong default causes real harm, or no single option fits most people, present the choices with none preselected. Ask when the setting first matters, when experience gives the user enough context to answer.
Never guess safety-critical data. Blood type, allergies, dosages: distinguish verified information from inferred or generic values, and require the appropriate verification before use.
Show the preselection plainly. A visible selected state lets users confirm or reject the choice you made; a buried default can decide for them before they even know there’s a choice.
Write defaults in plain positive language. No double negatives or reverse-logic checkboxes; the current state and its alternative should be clear at a glance.
Preload known data instead of asking. The saved address, the detected country, the last-used option: the user shouldn’t retype what the system knows.
Personalize only with confidence, and remember overrides. Fall back to a safe general default when the evidence is weak. Distinguish “this time” from a standing preference, and respect the scope of the correction.
Make overriding trivial. The minority who need something else should reach it in one obvious step; a great default plus a hidden override is still a trap.
Measure outcomes, and distrust silence. When more than 1/4 of users override a default, investigate what’s driving the changes before passing judgment. Compare safe defaults experimentally and examine recovery costs for users who keep them.
Modify a default as carefully as you set it. Preserve explicit preferences when updating inherited settings. Account for the habits and workflows users built around the old value, and explain consequential changes.
Make AI state the assumptions that could change the result. Distinguish presentation choices from decisions that change commitments, such as moving a deadline. Make these assumptions visible before they shape an action with consequences for the user.
Keep agent and skill defaults inspectable. Show consequential settings, their source, and whether they can be changed. Give skills an owner and version so changes can be traced.
Define the agent’s authority before delegating. Specify allowed actions and limits once; ask again when a consequential action falls outside that mandate or depends on an unresolved assumption.
Conclusion: You Chose for Them
Whether you meant to or not, your default is the decision most of your users will live with, and it’s also the lesson most of them will learn. Few design decisions repay careful judgment on such a scale. Set defaults to serve the person in front of the screen, and you multiply good outcomes at zero marginal cost, the way one company more than doubled retirement-plan participation by changing its enrollment procedure. Set them to serve only yourself, and you’ve built coercion with a smile. The court date may follow later.
AI has multiplied those decisions and buried many inside models, system prompts, and skills. Your job extends well beyond choosing a good starting value: keep the user’s next choice open, distinguish what the AI assumes from what the user has authorized, and measure the consequences of settings that go unchanged. Users should be able to delegate the work without surrendering control over the result. Set your defaults like you mean it.
Default settings may seem a minor matter of where to put an initial checkmark when a dialog box appears. Yet that little checkmark can shape the entire user experience. Make sure it’s for the better. (All images in this article were made with GPT Image 2, unless indicated.)
