In the economy of user effort, be a bargain, not a scam
15 min read
Treat user effort as a currency. To create a product users love, design the tradeoff curve of use case complexity to user effort with the same care you design your pricing scheme.
One of my favorite product design principles is Alan Kay’s “Simple things should be simple, complex things should be possible”.
[1]
I had been saying it almost verbatim long before I encountered Kay’s quote.
Kay’s maxim is deceptively simple, but its implications run deep.
It isn’t just a design ideal — it’s a call to continually balance friction, scope, and tradeoffs in service of the people using our products.
This philosophy played a big part in Prism’s success back in 2012,
helping it become the web’s de facto syntax highlighter for years, with over 2 billion npm downloads.
Highlighting code on a page took including two files.
No markup changes.
Styling used readable CSS class names.
Even adding new languages — the most common “complex” use case — required far less knowledge and effort than alternatives.
At the same time, Prism exposed a deep extensibility model so plugin authors could patch internals and dramatically alter behavior.
These choices are rarely free.
The friendly styling API increased clash risk, and deep extensibility reduced encapsulation.
These were conscious tradeoffs, and they weren’t easy.
Since Alan Kay was a computer scientist, his quote is typically framed as a PL or API design principle,
but that sells it short.
It applies to a much, much broader class of interfaces.
This class hinges on the distribution of use cases.
Products often cut scope by identifying the ~20% of use cases that drive ~80% of usage — aka the Pareto Principle.
Some products, however, have such diverse use cases that Pareto doesn’t meaningfully apply to the product as a whole.
There are common use cases and niche use cases, but no clean 20-80 split.
The long tail of niche use cases is so numerous, it becomes significant in aggregate.
For lack of a better term, I’ll call these long‑tail UIs.
Nearly all creative tools are long-tail UIs.
That’s why it works so well for programming languages and APIs — both are types of creative interfaces.
But so are graphics editors, word processors, spreadsheets, and countless other interfaces that help humans create artifacts — even some you would never describe as creative.
Example: Google Calendar
You wouldn’t describe Google Calendar as a creative tool, but it is a tool that helps humans create artifacts (calendar events).
It is also a long-tail product:
there is a set of common, conceptually simple cases (one-off events at a specific time and date),
and a long tail of complex use cases (recurring events, guests, multiple calendars, timezones, etc.).
Indeed, Kay’s maxim has clearly been used in its design.
The simple case has been so optimized that you can literally add a one hour calendar event with a single click (using a placeholder title).
A different duration can be set after that first click through dragging
[2].
But almost every edge case is also catered to — with additional user effort.
Google Calendar is squarely a long-tail UI.
Google Calendar is also an example of an interface that digitally encodes real-life,
demonstrating that complex use cases are not always power user use cases.
Often, the complexity is driven by life events.
E.g. your taxes may be complex without you being a power user of tax software,
and your family situation may be unusual without you being a power user of every form that asks about it.
The Pareto Principle is still useful for individual features, as they tend to be more narrowly defined.
E.g. there is a set of spreadsheet formulas (actually much smaller than 20%) that drives >80% of formula usage.
While creative tools are the poster child of long-tail UIs,
there are long-tail components in many transactional interfaces such as e-commerce or meal delivery (e.g. result filtering & sorting, product personalization interfaces, etc.).
Filtering UIs are another big category of long-tail UIs, and they involve so many tradeoffs and tough design decisions you could literally write a book about just them.
Airbnb’s filtering UI here is definitely making an effort to make simple things easy with (personalized! 😍) shortcuts and complex things possible via more granular controls.
Picture a plane with two axes: the horizontal axis being the complexity of the desired task (again from the user’s perspective, nothing to do with implementation complexity),
and the vertical axis the cognitive and/or physical effort users need to expend to accomplish their task using a given interface.
Following Kay’s maxim guarantees these two points:
Simple things being easy guarantees a point on the lower left (low use case complexity → low user effort).
Complex things being possible guarantees a point somewhere on the far right.
The lower down, the better — but higher up is acceptable.
Alan Kay's maxim visualized.
But even if we get these two points — what about all the points in between?
There are a ton of different ways to connect them, and they produce vastly different overall user experiences.
How does your interface fare when a use case is only slightly more complex?
Are users yeeted into the deep end of interface complexity (bad), or do they only need to invest a proportional, incremental amount of effort to achieve their goal (good)?
Meet the complexity-to-effort curve, the most important usability metric you’ve never heard of.
For delightful user experiences, making simple things easy and complex things possible is not enough — the transition between the two should also be smooth.
You see, simple use cases are the spherical cows in space of product design.
They work great for prototypes to convince stakeholders, or in marketing demos, but the real world is messy.
Most artifacts that users need to create to achieve their real-life goals rarely fit into your “simple” flows completely, no matter how well you’ve done your homework.
They are mostly simple — with a liiiiitle wart here and there.
For a long-tail interface to serve user needs well in practice,
we also need to design the curve, not just its endpoints.
A model with surprising predictive power is to treat user effort as a currency that users are spending to buy solutions to their problems.
Nobody likes paying it;
in an ideal world software would read our mind and execute perfectly with zero user effort.
Since we don’t live in such a world, users are typically willing to pay more in effort when they feel their use case warrants it.
Just like regular pricing, actual user experience often depends more on the relationship between cost and expectation (budget) than on the absolute cost itself.
If you pay more than you expected, you feel ripped off.
You may still pay it because you need the product in the moment, but you’ll be looking for a better deal in the future.
And if you pay less than you expected, you feel like you got a bargain, with all the delight and loyalty that entails.
Suppose you’re ordering pizza. You want a simple cheese pizza with ham and mushrooms.
You use the online ordering system, and you notice that adding ham to your pizza triples its price.
We’re not talking some kind of fancy ham where the pigs were fed on caviar and bathed in champagne, just a regular run-of-the-mill pizza topping.
You may still order it if you’re starving and no other options are available, but how does it make you feel?
It’s not that different when the currency is user effort.
The all too familiar “But I just wanted to _________, why is it so hard?”.
When a slight increase in complexity results in a significant increase in user effort cost, we have a usability cliff.
Usability cliffs make users feel resentful, just like the customers of our fictitious pizza shop.
A usability cliff is when a small increase in use case complexity requires a large increase in user effort.
Usability cliffs are very common in products that make simple things easy and complex things possible through entirely separate flows with no integration between them:
a super high level one that caters to the most common use case with little or no flexibility,
and a very low-level one that is an escape hatch: it lets users do whatever,
but they have to recreate the solution to the simple use case from scratch before they can tweak it.
Example: The HTML video element
Simple things are certainly easy: all we need to get a video with a nice sleek set of controls that work well on every device is a single attribute: controls.
We just slap it on our <video> element and we’re done with a single line of HTML:
<video src="videos/cat.mp4" controls></video>
➡️
Now suppose use case complexity increases just a little.
Maybe I want to add buttons to jump 10 seconds back or forwards.
Or a language picker for subtitles.
Or just to hide the volume control on a video that has no audio track.
None of these are particularly niche, but the default controls are all-or-nothing: the only way to change them is to reimplement the whole toolbar from scratch, which takes hundreds of lines of code to do well.
Simple things are easy and complex things are possible.
But once use case complexity crosses a certain (low) threshold, user effort abruptly shoots up.
That’s a usability cliff.
Example: Instagram editor
For Instagram’s photo editor, the simple use case is canned filters, whereas the complex ones are those requiring tweaking through individual low-level controls.
However, they are implemented as separate flows: you can tweak the filter’s intensity, but you can’t see or adjust the primitives it’s built from.
You can layer both types of edits on the same image, but they are additive, which doesn’t work well.
Ideally, the two panels would be integrated, so that selecting a filter would adjust the low-level controls accordingly, which would facilitate incremental tweaking
AND would serve as a teaching aid for how filters work.
Example: Filtering in Coda
My favorite end-user facing product that gets this right is Coda,
a cross between a document editor, a spreadsheet, and a database.
All over its UI, it supports entering formulas instead of raw values, which makes complex things possible.
To make simple things easy, it also provides the GUI you’d expect even without a formula language.
But here’s the twist: these presets are generate formulas behind the scenes that users can tweak!
Whenever users need to go a little beyond what the UI provides, they can switch to the formula editor and adjust what was generated
— far easier than writing it from scratch.
Another nice touch: “And” is not just communicating how multiple filters are combined, but is also a control that lets users edit the logic.
Defining high-level abstractions in terms of low-level primitives is a great way to achieve a smooth complexity-to-effort curve,
as it allows you to expose tweaking at various intermediate levels and scopes.
The downside is that it can sometimes constrain the types of high-level solutions that can be implemented.
Whether the tradeoff is worth it depends on the product and use cases.
If you like eating out, this may be a familiar scenario:
— I would like the rib-eye please, medium-rare.
— Thank you sir. How would you like your steak cooked?
Annoying, right?
And yet, this is how many user interfaces work; expecting users to communicate the same intent multiple times in slightly different ways.
If incremental value should require incremental user effort, an obvious corollary is that things that produce no value should not require user effort.
Using the currency model makes this obvious: who likes paying without getting anything in return?
Respect user effort.
Treat it as a scarce resource — just like regular currency — and keep it close to the minimum necessary to declare intent.
Do not require users to do work that confers them no benefit, and could have been handled by the UI.
If it can be derived from other input, it should be derived from other input.
A once ubiquitous example that is thankfully going away, is the credit card form which asks for the type of credit card in a separate dropdown.
Credit card numbers are designed so that the type of credit card can be determined from the first four digits.
There is zero reason to ask for it separately.
Beyond wasting user effort, duplicating input that can be derived introduces an unnecessary error condition that you now need to handle:
what happens when the entered type is not consistent with the entered number?
User actions that meaningfully communicate intent to the interface are signal.
Any other step users need to take to accomplish their goal, is noise.
This includes communicating the same input more than once,
providing input separately that could be derived from other input with complete or high certainty,
transforming input from their mental model to the interface’s mental model,
and any other demand for user effort that does not serve to communicate new information about the user’s goal.
Some noise is unavoidable.
The only way to have 100% signal-to-noise ratio would be if the interface could mind read.
But too much noise increases friction and obfuscates signal.
A short yet demonstrative example is the web platform’s methods for programmatically removing an element from the page.
To signal intent in this case, the user needs to communicate two things:
(a) what they want to do (remove an element), and (b) which element to remove.
Anything beyond that is noise.
The modern element.remove() DOM method has an extremely high signal-to-noise ratio.
It’s hard to imagine a more concise way to signal intent.
However, the older parent.removeChild(child) method that it replaced had much worse ergonomics.
It required two parameters: the element to remove, and its parent.
But the parent is not a separate source of truth — it would always be the child node’s parent!
As a result, its actual usage involved boilerplate, where
developers had to write a much noisier if (element.parentNode) element.parentNode.removeChild(element)[3].
Boilerplate is repetitive code that users need to include without thought, because it does not actually communicate intent.
It’s the software version of red tape: hoops you need to jump through to accomplish your goal, that serve no obvious purpose in furthering said goal except for the fact that they are required.
In this case, the amount of boilerplate may seem small, but when viewed as a percentage of the total amount of code, the difference is staggering.
The exact ratio (81% vs 20% here) varies based on specifics such as variable names,
but when the difference is meaningful, it transcends these types of low-level details.
The difference in signal-to-noise ratio is staggering: 81% vs 20% in this case.
Of course, it was usually encapsulated in utility functions, which provided a similar signal-to-noise ratio as the modern method.
However, user-defined abstractions don’t come for free, there is an effort (and learnability) tax there, too.
Improving signal-to-noise ratio is also why the front-end web industry gravitated towards component architectures: they increase signal-to-noise ratio by encapsulating boilerplate.
As an exercise for the reader, try to calculate the signal-to-noise ratio of a Bootstrap accordion (or any other complex Bootstrap component).
When pointing out friction issues in design reviews,
I have sometimes heard “users have not complained about this”.
This reveals a fundamental misunderstanding about the psychology of user feedback.
Users are much more vocal about things not being possible, than about things being hard.
The reason becomes clear if we look at the neuroscience of each.
Friction is transient in working memory (prefrontal cortex).
After completing a task, details fade.
The negative emotion persists and accumulates, but filing a complaint requires prefrontal engagement that is brief or absent.
Users often can’t articulate why the software feels unpleasant: the specifics vanish; the feeling remains.
Hard limitations, on the other hand, persist as conscious appraisals.
The trigger doesn’t go away, since there is no workaround, so it’s far more likely to surface in explicit user feedback.
Both types of pain points cause negative emotions,
but friction is primarily processed by the limbic system more (emotion),
whereas hard limitations remain in the prefrontal cortex (reasoning).
This also means that when users finally do reach the breaking point and complain about friction, you better listen.
Second, user complaints are filed when there is a mismatch in expectations.
Things are not possible but the user feels they should be, or interactions cost more user effort than the user had budgeted,
e.g. because they know that a competing product offers the same feature for less (work).
Often, users have been conditioned to expect poor user experiences,
either because all options in the category are high friction, or because the user is too novice to know better
[4].
So they begrudgingly pay the price, and don’t think they have the right to complain, because it’s just how things are.
You might ask, “If all competitors are equally high-friction, how does this hurt us?”
An unmet need is a standing invitation to disruption that a competitor can exploit at any time.
Because you’re not only competing within a category; you’re competing with all alternatives — including nonconsumption (see Jobs‑to‑be‑Done).
Even for retention, users can defect to a different category altogether (e.g., building native apps instead of web apps).
Historical examples abound.
When it comes to actual currency, a familiar example is Airbnb: Until it came along, nobody would complain that a hotel of average price is expensive — it was just the price of hotels.
If you couldn’t afford it, you just couldn’t afford to travel, period.
But once Airbnb showed there is a cheaper alternative for hotel prices as a whole, tons of people jumped ship.
It’s no different when the currency is user effort.
Stripe took the payment API market by storm when it demonstrated that payment APIs did not have to be so high friction.
iPhone disrupted the smartphone market when it demonstrated that no, you did not have to be highly technical to use a smartphone.
The list goes on.
Unfortunately, friction is hard to instrument.
With good telemetry you can detect specific issues (e.g., dead clicks), but there is no KPI to measure friction as a whole.
And no, NPS isn’t it — and you’re probably using it wrong anyway.
Instead, the emotional residue from friction quietly drags many metrics down (churn, conversion, task completion), sending teams in circles like blind men touching an elephant.
That’s why dashboards must be paired with product vision and proactive, first‑principles product leadership.
Steve Jobs exemplified this posture: proactively, aggressively eliminating friction presented as “inevitable.”
He challenged unnecessary choices, delays, and jargon, without waiting for KPIs to grant permission.
Do mice really need multiple buttons? Does installing software really need multiple steps? Do smartphones really need a stylus?
Of course, this worked because he had the authority to protect the vision; most orgs need explicit trust to avoid diluting it.
So, if there is no metric for friction, how do you identify it?
Usability testing lets you actually observe firsthand what things are hard instead of having them filtered through users’ memories and expectations.
Design reviews/audits by usability experts is complementary to usability testing, as it often uncovers different issues. Design reviews are also great for maximizing the effectiveness of usability testing by getting the low-hanging fruit issues out of the way before it.
Dogfooding is unparalleled as a discovery tool — nothing else will identify as many issues as using the product yourself, for your own, real needs.
However, it’s important to keep in mind that you’re a huge power user of your own product.
You cannot surface learnability issues (curse of knowledge) and you will surface issues no-one else has.
Dogfooding is a fantastic discovery tool, but you still need user research to actually evaluate and prioritize the issues it surfaces.
Reducing friction rarely comes for free, just because someone had a good idea.
These cases do exist, and they are great, but it usually takes sacrifices.
And without it being an organizational priority, it’s very hard to steer these tradeoffs in that direction.
The most common tradeoff is implementation complexity.
Simplifying user experience is usually a process of driving complexity inwards and encapsulating it in the implementation.
Explicit, low-level interfaces are far easier to implement, which is why there are so many of them.
Especially as deadlines loom, engineers will often push towards externalizing complexity into the user interface, so that they can ship faster.
And if Product leans more data-driven than data-informed, it’s easy to look at customer feedback and conclude that what users need is more features
(it’s not).
Simple to use is often at odds with simple to implement.
The first faucet is a thin abstraction: it exposes the underlying implementation directly, passing the complexity on to users, who now need to do their own translation of temperature and pressure into amounts of hot and cold water.
It prioritizes implementation simplicity at the expense of wasting user effort.
The second design prioritizes user needs and abstracts the underlying implementation to support the user’s mental model.
It provides controls to adjust the water temperature and pressure independently, and internally translates them to the amounts of hot and cold water.
This interface sacrifices some implementation simplicity to minimize user effort.
This is why I’m skeptical of blanket calls for “simplicity.”: they are platitudes.
Everyone agrees that, all else equal, simpler is better.
It’s the tradeoffs between different types of simplicity that are tough.
In some cases, reducing friction even carries tangible financial risks, which makes leadership buy-in crucial.
This kind of tradeoff cannot be made by individual designers — it requires usability as a priority to trickle down from the top of the org chart.
The Oslo airport train ticket machine is the epitome of a high signal-to-noise interface.
You simply swipe your credit card to enter and you swipe your card again as you leave the station at your destination.
That’s it. No choices to make. No buttons to press. No ticket.
You just swipe your card and you get on the train.
Today this may not seem radical, but back in 2003, it was groundbreaking.
To be able to provide such a frictionless user experience, they had to make a financial tradeoff:
it does not ask for a PIN code, which means the company would need to simply absorb the financial losses from fraudulent charges (stolen credit cards, etc.).
When user needs are prioritized at the top, it helps to cement that priority as an organizational design principle to point to when these tradeoffs come along in the day-to-day.
Having a design principle in place will not instantly resolve all conflict, but it helps turn conflict about priorities
into conflict about whether an exception is warranted, or whether the principle is applied correctly, both of which are generally easier to resolve.
Of course, for that to work everyone needs to be on board with the principle.
But here’s the thing with design principles (and most principles in general): they often seem obvious in the abstract, so it’s easy to get alignment in the abstract.
It’s when the abstract becomes concrete that it gets tough.
“User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.”
It’s more nuanced than users over developers; a better framing is consumers over producers.
Developers are just one type of producer.
Consumers are typically more numerous than producers, so this minimizes collective pain.
Producers are typically more advanced, and can handle more complexity than consumers. I’ve heard this principle worded as “Put the pain on those who can bear it”, which emphasizes this aspect.
Producers are typically more invested, and less likely to leave
The web platform has multiple tiers of producers:
Specification writers are at the bottom of the hierarchy, and thus, can handle the most pain (ow! 🥴)
Browser developers (“user agent implementors” in the principle) are consumers when it comes to specifications, but producers when it comes to the web platform
Web developers are consumers when it comes to the web platform, but producers when it comes to their own websites
Even within the same tier there are producer vs consumer dynamics.
When it comes to web development libraries, the web developers who write them are producers and the web developers who use them are consumers.
This distinction also comes up in extensible software, where plugin authors are still consumers when it comes to the software itself,
but producers when it comes to their own plugins.
It also comes up in dual sided marketplace products
(e.g. Airbnb, Uber, etc.),
where buyer needs are generally higher priority than seller needs.
In the economy of user effort, the antithesis of overpriced interfaces that make users feel ripped off
are those where every bit of user effort required feels meaningful and produces tangible value to them.
The interface is on the user’s side, gently helping them along with every step, instead of treating their time and energy as disposable.
The user feels like they’re getting a bargain: they get to spend less than they had budgeted for!
And we all know how motivating a good bargain is.
User effort bargains don’t have to be radical innovations;
don’t underestimate the power of small touches.
A zip code input that auto-fills city and state,
a web component that automatically adapts to its context without additional configuration,
a pasted link that automatically defaults to the website title (or the selected text, if any),
a freeform date that is correctly parsed into structured data,
a login UI that remembers whether you have an account and which service you’ve used to log in before,
an authentication flow that takes you back to the page you were on before.
Sometimes many small things can collectively make a big difference.
In some ways, it’s the polar opposite of death by a thousand paper cuts:
Life by a thousand sprinkles of delight! 😀
In the end, “simple things simple, complex things possible” is table stakes.
The key differentiator is the shape of the curve between those points.
Products win when user effort scales smoothly with use case complexity, cliffs are engineered out, and every interaction declares a meaningful piece of user intent.
That doesn’t just happen by itself.
It involves hard tradeoffs, saying no a lot, and prioritizing user needs at the organizational level.
Treating user effort like real money, forces you to design with restraint.
A rule of thumb is place the pain where it’s best absorbed by prioritizing consumers over producers.
Do this consistently, and the interface feels delightful in a way that sticks.
Delight turns into trust.
Trust into loyalty.
Loyalty into product-market fit.
Yes, typing can be faster than dragging, but minimizing homing between input devices improves efficiency more, see KLM↩︎
Yes, today it would have been element.parentNode?.removeChild(element), which is a little less noisy, but this was before the optional chaining operator. ↩︎
When I was running user studies at MIT, I’ve often had users exclaim “I can’t believe it! I tried to do the obvious simple thing and it actually worked!” ↩︎
