User Satisfaction Depends on Delivered Quality Relative to Expectations

Summary: Users judge your design against the version they imagined before first use. When the experience confirms expectations, they’re satisfied; when it falls short, the same product disappoints. And the bar never stops moving: every improvement you ship becomes the baseline users bring to the next release. Expectations also shape the work people attempt and the effort they devote to checking the result.

Two users try the same AI writing assistant. Albert expects it to produce a polished report from a one-line prompt; Betty expects a rough outline she’ll have to rewrite anyway. The tool delivers a competent first draft. Betty is delighted. Albert cancels. Same product, same output, opposite verdicts. The difference began inside their heads before they typed a word.

The soup delivered. The promise didn’t.

Definition: Expectation Confirmation Theory (ECT) explains satisfaction by comparing what users expected with what they believe the product actually delivered. Confirmation means performance matches expectations and produces satisfaction; positive disconfirmation means performance exceeds expectations (creating delight); negative disconfirmation means performance falls short and produces disappointment. These judgments help explain why objectively good design can still disappoint, while modest products can delight users who expected less.

Users arrive with a blueprint in their heads. The experience feels right when the product matches that mental drawing; a mismatch forces users to revise their understanding, their plans, or their opinion of your company.

Thus, expectations are a design material, every bit as real as pixels and copy. Every ad, app-store screenshot, sales demo, and onboarding tooltip writes a promissory note that the interface must later honor. The accumulated shortfall is your expectation debt: the work your promises led users to count on, but your product fails to deliver. Those unpaid promises soon deliver churn and 1-star reviews.

Write the comparison as arithmetic, and the management problem becomes plain: expectation gap = perceived performance − expected performance. Two terms, two levers. Design and engineering raise the first; marketing, pricing, and release history influence the second. Most companies assign hundreds of people to improve performance and leave expectations to whoever writes the launch post.

But the gap diagnoses whether you kept a promise; it doesn’t establish whether that promise was worth keeping. A product that meets an expectation of misery has delivered misery on schedule. Measure the gap alongside satisfaction and task success.

The gap between perceived and expected performance helps explain satisfaction. The subtraction serves as a design mnemonic; a complete measurement model requires more.

If a hotel room description clearly discloses that the room has no view, guests who book it know what they’re getting. A blank wall then fulfills the promise.

From Flu Shots to Online Banking

Marketing professor Richard L. Oliver of Washington University in St. Louis formalized the model in 1980 in the Journal of Marketing Research, testing it in a two-stage field study of a flu inoculation program. (An unglamorous test bed, but instructive: the theory applies beyond software.) Expectations and their confirmation or disconfirmation helped explain satisfaction and subsequent attitudes and intentions.

Oliver drew on Harry Helson’s adaptation-level theory: people judge a stimulus against a reference level, and expectations supply one in advance. Crucially, he measured expectations before use. Asking afterward invites users to reconstruct yesterday’s forecast in light of today’s result, quietly erasing the surprise you meant to measure.

The same experience can create opposite feelings, depending on expectations.

Anol Bhattacherjee adapted the model in MIS Quarterly in 2001 to explain why people intend to keep using software. His survey of online banking users identified both satisfaction and perceived usefulness as drivers of the intention to continue using the service. That second driver matters: a tool can earn a pleased shrug and still accomplish too little to deserve another session. Winning the download is one battle. Becoming worth returning to is the war.

If you keep meeting users’ expectations, update after update, you’ll likely keep those customers and get rich.

In the 46 years since Oliver’s paper, ECT has become a workhorse model of satisfaction research across products, services, and software. (Academics being academics, they built rival refinements on top, but the basic comparison has proved embarrassingly durable for a theory you can summarize in one line.) Its enduring contribution is the reference point: quality arrives in a mind already prepared to judge it.

For UX, that explains why identical experiences produce opposite verdicts, and why an unchanged product can receive lower scores as users’ expectations rise. One gap separates users; the other separates successive encounters with the same product.

The 6 Suppliers of User Expectations

Users gather expectations from almost everywhere except your product. Before they ever touch your design, these 6 suppliers have already helped draw the blueprint in their heads:

The first supplier is the heavyweight, as I discuss in the next section. But notice the pattern across the other 5: much of the expected-performance term is set by people who never attend a design review. Your pricing team moves expectations every time it changes a digit, because paying adds entitlement to a forecast: subscribers can feel wronged when free users would merely feel disappointed. A $200/month AI subscription thus sets a higher bar than the free tier does, even when the underlying model is identical.

Meanwhile, social feeds have become expectation factories. Nobody posts the 7 failed generations, only the glorious 8th one. A new user’s blueprint is thus assembled from other people’s highlight reels, which showcase the successes and hide the failures. An ordinary first attempt loses to a fantasy your product never promised.

Reviews cut both ways. The angriest 1% of users write the loudest reviews, preloading newcomers with dread that your actual product can beat. That’s an accidental gift: positive disconfirmation you didn’t have to build. (Underpromising via 1-star reviews isn’t a strategy I recommend, but it explains the occasional “better than I expected from the reviews” bump that mediocre products enjoy.)

The third supplier, the user’s own history, deserves more respect than it gets, because a brand is a bundle of remembered expectations with a logo on top. Every session users have had with your product, and with your company’s other products, feeds the blueprint they bring to the next encounter. That’s why a lapse in polish exposes a premium brand to harsher judgment: a keyboard from a luxury marque faces standards that no bargain-bin peripheral will ever have to meet.

Consistency gives users evidence they can plan around. A product line that delights on Monday and fumbles on Thursday teaches users to expect erratic performance. That uncertainty becomes a negative expectation of its own, discouraging users from trying everything else you ship.

Confirmed Expectations Are Free Usability

Users’ minds are filled with expectations shaped by existing designs. Those familiar conventions can land a physical punch when a new design ignores them. (Grok Imagine 2)

Jakob’s Law says users spend most of their time on other sites and apps, so they arrive with conventions preinstalled: the logo links home, the cart icon holds their items, and swiping down refreshes the view. Follow those conventions, and users get confirmation for free, before you’ve done anything clever. Violate them, and you’ve disappointed users before they’ve had a chance to discover your product’s value.

Promises set the blueprint’s height; conventions set its shape. An unfamiliar design can make users struggle before they discover whether it’s any better than the design they already know.

Break a convention, and users stumble before your cleverness gets its turn.

The next-cheapest source of confirmation is making promises you can reliably keep. State a 5-day delivery window and deliver in 3 days, and the customer experiences positive disconfirmation at the doorstep. The promise at checkout first has to be attractive enough to win the order. Reverse the numbers, and a parcel delivered on day 5 becomes a grievance. Thus, quote a credible window with room for ordinary variation. Promises help users make plans, and a deliberately useless estimate can cost the sale before you get to exceed it.

The same logic operates inside interactions, at the scale of seconds. Progress indicators should advance credibly and finish decisively; a bar stranded at 99% teaches users that your numbers are decorative.

As a starting point for time estimates, I’d test the 80th percentile of observed completion times, which should cover about 4 cases in 5 if conditions stay comparable. Then examine the late cases and the decisions users make around the estimate. A background export and a submission with a firm deadline deserve different margins. Calibrate the promise to the consequence of missing it.

Perceived quality also depends on what survives in memory. The peak-end rule describes how an experience’s most intense moment and its ending can disproportionately influence retrospective judgment. Give a successful task a clear, reassuring finish: show what was completed and where the result went. An upsell or rating nag squanders that moment. A pleasing ending earns its place by confirming real completion.

One Broken Promise Can Defeat 9 Kept Promises

Shortfalls and surpluses don’t carry equal weight. Prospect theory, Daniel Kahneman and Amos Tversky’s account of how people weigh gains and losses, established that losses loom about twice as large as equivalent gains. This explains why an expected benefit can feel like something taken away if it isn’t delivered.

The consequence depends on the work the missing capability prevents users from doing, because users build each step of a workflow on the promise that the next step will work. Deliver 9 of 10 promised capabilities but fail at the tenth, exporting the finished report, and the user has an excellent document trapped behind glass. Those 9 successes can’t compensate for the failure that blocks completion. Prioritize expectation debt by the work each broken promise strands. Fix the missing bridge before planting flowers along the road.

A workflow is only as useful as its last required step: producing a great report that the user can’t export is worthless.

Because of loss aversion, anything users feel you’ve taken away from them hurts twice as much as a gift pleases.

Expectations influence more than the final verdict. Baba Shiv and co-authors demonstrated this in 2005 by assigning 125 participants to energy-drink conditions that varied the price and the strength of the suggested benefit, then giving them word puzzles to solve. In the low-expectancy conditions, buyers charged $0.89 solved 7.7 puzzles in 30 minutes, compared with 9.5 among those charged $1.89: a 19% deficit. Here, expectations affected actual task performance.

Marketing researcher Rolph Anderson also showed back in 1973 how expectations influence product evaluations. For UX, the implication reaches beyond persuasion: what users expect can change how they approach the work, helping produce the outcome they later judge.

The bar also has some width. Valarie Zeithaml and co-authors proposed in 1993 that customers hold two levels of expectation: the service they desire and the service they’ll accept, with a zone of tolerance between them. This zone helps distinguish an unmet wish from an unacceptable result. Discover its boundaries for the task that matters: users may forgive an inelegant report while refusing one with missing transactions. A cheerful average across those attributes would conceal the failure that prevents them from using the report.

When something breaks and the company handles the recovery superbly, satisfaction sometimes ends up higher than if nothing had gone wrong. Researchers call this the service recovery paradox. A 2007 meta-analysis by Celso de Matos and co-authors found a positive effect on satisfaction, but no significant effect on repurchase intentions, word of mouth, or corporate image.

The distinction matters: a recovered score doesn’t establish a recovered relationship. Users can appreciate your rescue while deciding to avoid needing another one. Acknowledge the failure, repair the damage, and show how you’ll prevent a recurrence. Judge recovery by subsequent behavior as well as the thank-you.

Feature removal makes the dependency problem particularly visible. Users build routines around available capabilities, so removing a feature can wreck a workflow they’ve spent months organizing. Advance notice helps them prepare, but doesn’t replace the missing function. Simplification remains a virtue, and most products would benefit from fewer features done well.

Before removing a feature, identify the workflows that rely on it, provide a workable migration path, and test whether users can still finish their work. Silent removals convert loyal users into former users with industrial efficiency.

One removed feature outscreams two good deeds in a redesign.

Hype Writes Checks the Interface Must Cash

The classic failure is overpromising, and AI products are today’s worst offenders. Market a chatbot as “ask it anything,” and the first hallucinated citation converts a useful tool into a broken promise. The standard comes from how you frame AI: an assistant is graded against a competent colleague, an oracle against omniscience, and most AI marketing sells oracles. Users can live with a mediocre tool; they’re less forgiving when an absurd promise persuaded them to rely on it. Expectation debt at its finest.

AI compounds the problem through fluency transfer: users assume that a system that writes flawless prose also supplies flawless facts, just as diners assume a restaurant with crisp white tablecloths runs a clean kitchen. The polish of the surface promises quality underneath. Users can’t inspect what’s behind the answer, so they judge what they can see.

Conversational polish can therefore invite more delegation than the system’s reliability warrants. Show what the system checked, what it inferred, and what still requires review when those distinctions affect the user’s next action. A generic disclaimer in the footer can’t compete with an answer that performs certainty.

Claimflation has been running rampant for years.

Claimflation has devalued modern marketing so badly that customers hardly believe any advertising anymore.

Individual overpromises then compound into an industry condition: claimflation. When everything is revolutionary, “revolutionary” comes to mean “shipped on schedule.” Marketers escalate to “magical,” users discount their words even more heavily, and next quarter’s adjectives start from higher ground.

Claimflation is a tragedy of the commons: users’ trust is a shared reserve, and every vendor’s overclaim draws it down a little. Each vendor is tempted to leave replenishment to somebody else. It punishes honest vendors most, because an accurate claim gets the skeptic’s haircut along with all the inflated ones. That makes a promise you can reliably keep a competitive weapon. In a market where words have lost purchasing power, a product that repeatedly delivers more than promised gives customers a currency they can still spend.

Claimflation enlarges the promise without improving the product. All that hype hasn’t added an ounce to the potato.

Claimflation: it takes ever more hype to stand out.

Staged demos run up the same tab: the best of 50 attempts becomes the prospect’s expectation of an ordinary session. But a median session is also a weak standard for work users intend to delegate repeatedly, because roughly half the results fall below the median. For AI, the dependable floor matters: the level of performance users can build a workflow around under stated conditions.

A brilliant answer followed by a blunder that users can’t readily spot can leave them checking everything. That inspection consumes the labor savings that justified delegation in the first place. Show representative results, the conditions for reliable use, and the preparation and review required. Promise useful work you can repeatedly deliver.

A vase displaying the best of 50 roses gives a flattering impression of the bush that grew them. Use that vase as your demo, and users will expect roses of the same quality every time.

Your promise also selects the users who arrive and the tasks they bring. “Finished reports from one sentence” recruits people who want to skip drafting and editing. “Turn your notes into a structured draft” recruits people who have source material and expect to refine the result. The first campaign can therefore manufacture the failures that marketing will later blame on the product. Both campaigns sell the same software, yet they feed it different work.

Judge acquisition by the useful sessions it produces, including the effort users must contribute. A campaign that doubles sign-ups while filling the product with impossible assignments has bought you a larger disappointment factory. The conversion funnel begins the user experience by shaping the tasks users attempt and the failures they eventually encounter.

Getting AI to generate the answer was the quick part. Checking its work can swallow the time you thought you’d saved.

Expectations are instructions in disguise. Albert, expecting a finished report, reserves no time for revision; Betty, expecting a draft, schedules an editing pass. Their different expectations now produce different workflows from the same output.

Set expectations before users commit money, time, or responsibility, while they can still construct a workable plan. A capability note that arrives after delegation merely explains why the plan failed. Empty states, onboarding, and task-specific guidance should tell users what to provide, what they’ll receive, and what remains theirs to check. Have marketing and product teams observe the same first-use sessions, then hold both accountable for the plans their promises lead users to make.

Expectation debt also has a peculiar accounting advantage: the team that borrows often doesn’t pay. Marketing collects credit for conversions, sales collects the commission, and the product and support teams inherit the failed session. Each department can meet its target while the customer loses.

Put the promise and its eventual fulfillment on the same scorecard, with an owner who can change either side. Follow a claim from the advertisement through the first completed task and into repeated use. A sales promise that requires an undisclosed hour of cleanup belongs in that accounting, even if the output looks magnificent in the demo. Otherwise, your organization rewards borrowing and treats repayment as somebody else’s budget overrun.

Claimflation wings carry you beautifully until the first user session, when the paper claims catch fire.

The Expectation Treadmill Never Stops

Suppose you execute all of the above perfectly and deliver more than users expected. Congratulations: their expectations just went up. Every delivery doubles as a promise about the next one, so your last release is your loudest advertisement. Next quarter, the performance that delighted them merely meets expectations. The quarter after, it barely suffices.

This illustrates the shifting reference points associated with hedonic adaptation, whose UX consequences I’ve analyzed in a separate article: the same design can lose its power to impress.

The expectation treadmill keeps rolling: you have to run to stay in place.

A classic 1978 study by Philip Brickman and co-authors compared 22 lottery winners with 22 controls and 29 accident victims. The winners’ present happiness averaged 4.0 on a 0–5 scale, versus 3.8 for controls, a nonsignificant difference. This small, cross-sectional study illustrates how poorly a spectacular gain can translate into a spectacular happiness rating.

For product teams, fading excitement and useful progress deserve separate measurement. Treat fading delight as a planning problem, and measure its pace in your product. Otherwise, “users adapted” becomes a convenient excuse for a regression nobody investigated.

Yesterday’s delight is today’s doorstop.

This is hedonesia, users’ amnesia for how good things used to feel. (From the Greek hēdonē, pleasure, plus amnēsia, forgetting. The pleasure still arrives on schedule; the memory of life without it is gone.)

Hedonesia: users quickly forget how good they’ve got it.

The Kano model maps where the hedonic treadmill carries each feature. In 1984, Noriaki Kano and co-authors distinguished must-be qualities (absence infuriates, presence goes unnoticed) from attractive qualities (presence delights, absence is forgiven), and observed that attractive qualities migrate: yesterday’s delighter becomes today’s performance attribute and tomorrow’s must-be.

Free 2-day shipping delighted in 2005 and is an entitlement now. Spell check, autocomplete, and single sign-on each illustrate the trip from “wow” to a baseline expectation to complaints when the feature is missing. In 2022, an AI that drafted a passable email was sorcery. In 2026, it’s assumed, and the complaint is that the draft needed 2 edits. That’s hedonesia operating at production scale: nobody wakes up grateful for spell check.

Hedonesia: what delighted at first use soon hardens into an expectation.

Hedonesia: AutoCorrect and automatic traffic rerouting once felt like magic. Now, an AI that writes a better email than you do can be met with a snooze.

Two engines power the treadmill. The internal engine is psychological: familiar benefits attract less conscious attention. The external engine is competitive: as Jakob’s Law explains, improvements in familiar products raise expectations for comparable interactions elsewhere.

When one product cuts checkout to 3 clicks, every 5-click checkout in the user’s life starts to feel like a visit to the DMV. Your product category doesn’t fence off your users’ experience. An effortless checkout elsewhere can become the standard brought to your portal.

Evolutionary biologists call this dynamic a Red Queen race, after the chess queen in Through the Looking-Glass (1871) who explains that “it takes all the running you can do, to keep in the same place.” She’s speaking to Alice, as it happens. The Alice who stars in the comic at the end of this article faces much the same problem.

Hedonesia: the wow evaporates fast. As a verse in my song on hedonic adaptation puts it, the thrill you feel today will fade tomorrow.

For AI, both engines run at redline. Current AI is the worst AI you’ll ever use, which is glorious for capability and merciless for satisfaction: each model generation resets the baseline within weeks. My expectation is that capability will keep improving, while each advance gives users another reason to demand more. The gasp at launch becomes the grumble of week 2.

My prediction: longitudinal research will find unusually fast hedonic adaptation in AI products, as novelty fades alongside visible gains in capability. A useful study would measure both reactions over time, separating fading excitement from genuine changes in task success. (Consider that a research request and a ready-made thesis for a smart Ph.D. student.)

The treadmill also moves the work itself. Once an AI tool handles routine emails competently, users hand it a delicate negotiation; once it summarizes a short memo, they try a folder of conflicting reports. Better performance expands the assignment until users encounter a new boundary. Thus, falling satisfaction can reflect rising ambition as well as rising standards, and stable task-success rates can conceal substantial gains if the tasks have grown harder.

Keep a fixed set of representative tasks for comparison across releases, while separately studying the work users now choose to attempt. The first tells you whether capability improved. The second shows where that improvement has carried users, and which new promises the next release must support.

AI is about to lose its novelty and wow factor. Send flowers.

Anyone who has shipped a redesign to applause and watched the applause expire knows the feeling. Yet disappearing delight can accompany growing practical value: users build the capability into routines, save repeated effort, and attempt work they couldn’t previously finish. Delight depreciates; saved work accumulates. Users stop applauding single sign-on; another demand to remember a password quickly reminds them what it was worth.

Fund dependable usefulness before another spectacle, and make dependable service the foundation for any occasional surprises. The Stoic discipline of anticipating adversity has its uses, but users shouldn’t need Seneca’s fortitude to enjoy your software.

Seneca’s De Tranquillitate Animi (On Tranquility of Mind) advises premeditatio malorum, literally the premeditation of adversities, as part of the Stoic discipline of steadiness amid life’s frustrations. Modern software supplies ample practice. (Muse Image)

Enterprise Software Is Graded on a Curve

Different user populations have different expectations. Enterprise users accustomed to miserable systems may initially compare your procurement portal with the previous portal. So competent B2B UX overdelivers at a discount, and the same interface quality that rates “fine” in a consumer product rates “miraculous” behind a corporate login.

(As an aside, this is the kindest available explanation of why enterprise software is so bad: vendors respond rationally to a market where the bar sits on the floor, the buyer isn’t the user, the sales demo sets the buyer’s expectations, and successive systems forced upon employees have beaten their expectations into the ground.)

Enterprise software has traditionally offered such miserable usability that mild torture exceeded expectations and felt almost pleasant.

The buyer–user split imposes two tests on enterprise products. The executive expects a return on the contract; employees need to finish real work with row 40,000 of real data on a Tuesday afternoon. A choreographed demo can satisfy the buyer while concealing the user’s daily burden. Thus, renewed software licenses can coexist with a failed UX: employees may not have permission to leave.

Measure completion time, rework, and help required alongside satisfaction and renewal. A captive audience is excellent at concealing a bad product from a vendor’s dashboard.

Expertise changes the blueprint, too. Novices have fewer precedents and may mistake fluent conversation for unrestricted competence. Experts bring precise expectations and established routines; a small behavior change can impose a large switching cost. Serve both populations with targeted expectation-setting: capability notes for the novice, change logs for the expert.

Satisfaction Scores Reflect the Expectations Users Bring

Expectation-sensitive ratings require careful interpretation. Customer satisfaction (CSAT), Net Promoter Score (NPS), the System Usability Scale (SUS), and app-store stars ask different questions; none directly computes the expectation gap. Read each according to what it measures. These distinctions have 5 consequences:

• Cross-product comparisons need a common frame. A product rated 4.2 stars and a rival rated 4.6 stars may serve different users, tasks, and expectations. Compare like with like before treating the higher rating as evidence of better design.

• Your own trend line needs context. Declining scores can reflect rising expectations, a changed audience, or an actual regression. Track task performance and competitive benchmarks alongside your history. If you explain flat scores as “flat while improving,” investigate that hypothesis before awarding yourselves a consolation prize.

• Cross-country and cross-segment comparisons reflect different habits in rating products. Some cultures and customer segments hand out top marks freely; others treat a perfect score like a marriage proposal. Same design, different arithmetic.

• An improved average can hide departing users. If frustrated customers leave, the remaining respondents may be happier even while the product loses its market. Compare cohorts and investigate departures; a dashboard can look healthier because the people it failed have stopped answering.

Satisfaction averages can rise because unhappy customers disappear.

• Measure the expectation gap alongside outcomes. Ask what users expect before use, then compare their experience afterward. A shortfall in perceived performance despite successful, efficient task completion points toward a promise problem; failed tasks and excessive effort demand product work. Low expectations and few users willing to try the product suggest a positioning problem. The pattern identifies the intervention; no single difference between scores can do the job.

Start this week with 5 users as a qualitative diagnostic. Before first use, ask how well they expect the product to handle their task on a 7-point scale; afterward, collect the matching performance rating and observe whether they succeeded.

Example of how a better-performing feature (here, AI search) can create worse satisfaction than a lower-performing feature (here, export), if users’ prior expectations were much higher for the first feature.

Those gaps show how differently the two features fulfill their promises. They don’t establish which feature delivers more value or deserves investment. Examine individual sessions, task importance, and failure costs before deciding what to fix. The subtraction opens the investigation.

One consolation for bruised product teams: a competitor’s splashy launch can make users tougher graders overnight. Verify that explanation against what actually happened in their sessions.

10 Design Guidelines for Managing Expectations

1.          Measure expectations alongside outcomes. Ask users what they expect before first use and compare those expectations with post-task ratings, task success, and observed effort. Use the gap to diagnose a mismatch, then establish whether delivery, the promise, or both need repair.

2.          Follow interface conventions by default. Users import expectations from the rest of the Web, so standard patterns meet those expectations without asking users to learn a new pattern. Deviate only when testing proves your alternative outperforms the convention.

3.          Promise dependable performance. Test claims against representative sessions and inspect failures as carefully as the median. For delegated work, state the conditions under which users can rely on the result and the review they must still perform. Show the work behind the impressive demo.

The median session is a starting point for examining promises. Reliable delegation also requires knowing what happens below it.

4.          Give verifiable promises room for ordinary variation. Base delivery windows and processing estimates on observed performance, then examine the cases that miss them. Match the margin to the consequence of being late, and end the flow with clear confirmation that the promised work is complete.

5.          Set expectations before commitment. Use empty states, onboarding, and capability notes to explain inputs, outputs, and remaining user work before users delegate or plan around the result. Guidance earns its keep when users can still act on it.

6.          Pay down expectation debt with every release. Prioritize broken promises that block a whole workflow, fix them, and show affected users what now works. Release notes announce repayment; a successful session supplies the receipt.

7.          Protect workflows when removing features. Determine what users built around the capability, provide a workable replacement, and test the migration with affected users. Advance notice gives them preparation time; it doesn’t compensate for work they can no longer finish.

8.          Recover the work and the relationship. Acknowledge the failure, repair the damage, and prevent recurrence. A grateful response to excellent support doesn’t establish renewed confidence in the product. Check whether users resume the work and continue returning.

9.          Budget for useful progress after novelty fades. Track saved effort and successful work as well as satisfaction. Fund continuous refinement and competitive improvements; reserve occasional surprises for products whose dependable basics already earn them a place in users’ working lives.

10.      Benchmark against the experiences users bring with them. Jakob’s Law means familiar patterns elsewhere can set expectations for your product. Review relevant consumer and enterprise experiences regularly, then test which expectations have transferred to your audience.

Conclusion: The Wow Wears Off, but the Work Doesn’t

Remember Albert and Betty from the introduction. Their blueprints explain their opposite verdicts, but they also shape what happens next: Albert planned to submit; Betty planned to edit. Expectations supply a reference point and a plan of action. The product must support both. Teams that improve delivery while allowing promises to outrun it keep manufacturing disappointment, even as their software gets better.

Thinking in terms of debt tells you how to run the shop. Every promise, from the app-store screenshot to the progress bar, borrows against a future session. Repay it with dependable work under conditions users understand. Prioritize the broken promise that strands a workflow over the embellishment that wins a demo. And judge repayment with more than a satisfaction score: users need to finish, save effort, and have a reason to return.

Accept the treadmill without mistaking fading applause for fading value. This year’s delight may become next year’s dependable habit, quietly saving work long after users stop noticing. Budget for that transition: keep the basics reliable, keep promises within demonstrated capability, and keep improving the work users can accomplish. The wow wears off. The value can keep growing.

The wow wears off, but if you work hard enough on UX quality, you can stay ahead of the climbing expectations curve.

Alice and Zimo check their expectations in ink-crosshatch style. (All images in this article made with GPT Image 2, except as indicated.)