A manifesto for calm design

Is the unicorn really what you want?

When you finish something real, something that took judgement and time, a cartoon unicorn flies across your screen. Sometimes it's a yeti. Sometimes a narwhal or a phoenix. The animation lasts less than a second. You saw it. You smiled, maybe. And then you had to decide, without quite noticing you were deciding, whether that was what you wanted from your work.

The unicorn is a design choice, and it is not an accident. The product team that built it is openly clear about what it does. It taps positive reinforcement. It rewards task completion. It uses a variable-ratio reinforcement schedule, so that you never know whether this completion will trigger a visit. The mechanism is not a metaphor for a slot machine. It is literally the same mechanism, first described by B.F. Skinner in the 1950s, the reason casinos make more money than any other form of entertainment ever invented, and the subject of more published behavioural research than almost any other concept in psychology. This isn't an insult to the designers. Their own product blog describes the feature as a manifestation of the amazing collaboration that happens on their platform, and users on their forum have asked, repeatedly, for more unicorns on every task, not just the lucky ones.

And it works. Of course it works. You complete a task. A unicorn may appear. Your brain registers a small reward. You are, measurably, a little more likely to complete another task, and a little more likely to open the app tomorrow. By every metric the software cares about, this is a success.

But sit with the question for a moment: is the unicorn what you wanted?

This piece is built around that question, and six others like it. The questions add up to a position, which at the end of the piece is stated as a manifesto: a set of tenets for what we're calling calm design, proposed in the hope that other people who build software will find them useful and choose to build under them too.

Did you want your software to be fun, or to get out of the way?

Most of us, if pressed, would say both. We'd like the work to feel good and we'd also like to not be interrupted while we do it. In practice those two goals are harder to hold together than they sound. A unicorn is a tiny interruption. A green checkmark would have been enough. The green checkmark doesn't celebrate you. It just records what happened. The unicorn is the software asking, gently, for a little bit more of your attention than the work required.

Multiply that by every notification, every activity feed, every "you've been productive this week!" email, every AI assistant that pops up with a helpful suggestion. Each one is a small request for attention dressed as a gift. The cumulative weight of all those gifts is the reason so many people end the day feeling like they were busy without being able to point at anything they actually finished.

In 1995, researchers at Xerox PARC saw this coming. Mark Weiser and John Seely Brown published a paper called Designing Calm Technology, in which they argued that as computing became ubiquitous it would have to learn to stay in the periphery of human attention rather than constantly demanding the centre. Their canonical example was a piece of plastic spaghetti, eight feet long, hanging from a motor in the PARC ceiling. They called it the Dangling String. The motor twitched in proportion to network traffic. You never looked at it. You just knew, ambiently, whether the network was busy. It demanded zero attention and informed you completely.

That is what software could have been, and in some quiet corners still is. It is the opposite of the unicorn.

The other way software creeps out of the periphery is through features. Think about a Swiss Army knife. It has a dozen blades. Scissors, a corkscrew, a fish scaler, a magnifying glass, a tiny saw, a leather punch. Most owners use the main blade and maybe the scissors. The corkscrew comes out on holiday. The leather punch has never been touched. And none of these tools, even the ones that do get used, are as good as the dedicated version. The kitchen scissors are sharper, the real corkscrew opens bottles faster, the real saw actually cuts wood. The Swiss Army knife is beloved in principle and compromised in practice.

Productivity software is full of Swiss Army knives. A task manager that is also a chat app that is also a CRM that is also a document editor that is also an AI writing assistant. Every quarter a new blade is added, because the product team has to show progress, and shipping features is the most visible form of progress a product team knows how to produce. Each new blade is announced as an upgrade. Each one quietly adds friction for the blades you actually use: a new menu item, a new tab, a new onboarding tour, a new thing to ignore.

A feature is only worth shipping if it makes the core promise of the software easier to deliver. Features that exist because the roadmap needed filling, or because a competitor had one, or because the team mistook novelty for value, aren't neutral. They're tax. They dilute the tool's purpose, they consume onboarding attention, and over years they accrete into the kind of software that everyone uses less of than they're paying for.

Do you want to use your software more, or less?

This is the question nobody asks in a procurement meeting, because the answer is so obvious it feels stupid to say out loud. You want to use your software less. You want to be in it for as long as the task genuinely requires and then be out of it, back to the thing the software was bought to help with: the client, the matter, the patient, the case, the work.

But almost no software is designed for that. Daily active users is the metric the vendor cares about. Time in app is the metric they optimise. Every design decision flows downstream from the premise that more usage is better usage. The unicorn is the most visible expression of that premise, but it is not the most consequential one. The notification defaults are. The activity feeds are. The friction of leaving. The subtle ways the interface rewards you for coming back.

Jason Fried, the co-founder of 37signals, has been making a version of this argument for two decades. His 2018 book with David Heinemeier Hansson, It Doesn't Have to Be Crazy at Work, is built around one deceptively simple question: can you optimise a company for calm, not chaos? Their answer applies equally well to software. Most tools are optimised for chaos because chaos keeps you coming back. A tool optimised for calm would look, from a growth-metrics perspective, like it was failing, because its users would be in it less, which is exactly what they wanted in the first place.

None of this is malicious. It is simply what happens when product teams who grew up building consumer software get hired to build tools for professionals. They bring their instincts with them. The instincts were tuned on Instagram and TikTok, and the instincts tell them that engagement is the goal.

The software was supposed to be the hallway. Somewhere along the way it started trying to be the room.

Do you want to be the one who remembers?

Think about how a deadline works in most systems. You enter it. The system shows it to you on a list. A day before, it reminds you. An hour before, it reminds you louder. If you miss it, the reminder simply stops. It has done its job, which was to tell you, and you did not respond, which is now your problem.

The software, in this model, is a shelf of reminders. The remembering is still yours.

That's fine for small things. For serious work, for filings, renewals, regulatory windows, moments where a missed day becomes a malpractice claim, it is not fine. You don't want a louder reminder. You want a system that assumes you will occasionally forget, and that has planned for that, and that will catch the miss before it becomes a miss.

Productivity software has almost none of this. A missed deadline is treated as an individual failure to perform, rather than a system failure to protect. The shelf of reminders absolves itself the moment it beeps. You want software that owns the structure so completely that your attention can go to the judgement, and that, when the structure fails, treats the failure as its own.

Do you want to be watched?

Modern productivity software is, without exception, an observation apparatus. It records what you click, how long you look, what you type, how often you return. That data flows upward: to the vendor, to their analytics stack, sometimes to the models they're training, occasionally to whoever buys the vendor next.

Shoshana Zuboff, in The Age of Surveillance Capitalism (2019), named this the extraction of "behavioural surplus": the bits of you that the tool didn't strictly need to do its job, but collected anyway because that data had market value to someone. Her argument was about consumer tech, but the pattern has crossed into B2B more or less unremarked. The productivity tool on your desk is, in most cases, also a surveillance instrument. It just doesn't call itself that in the sales deck.

You might want some of the watching, if it were genuinely in service of you. If the software noticed you were drifting toward burnout and quietly adjusted your load. If it spotted a matter slipping and nudged a colleague who could help. That's a kind of watching that exists for your benefit.

You almost certainly do not want the rest of it. You do not want your client's matters fed into a training corpus. You do not want the vendor to know which screens you linger on and why. For most consumer software the trade is acceptable because the stakes are trivial. For professional services, where the duty of confidentiality is not a preference but a licensing obligation, the trade is not acceptable, and it has mostly been accepted because nobody asked the question.

Do you want AI, or do you want to do less work?

These are not the same thing, despite the marketing.

The mechanism is easy to see once you look for it. AI makes email effortless, so people send more email. It makes summaries trivial, so more meetings get scheduled to be summarised. It gives you a chat interface to manage, so you manage the chat. The shallow work expands to fill the space AI saved. The deep work shrinks.

You probably didn't want an AI assistant. You wanted some of your work to disappear. Those are different product briefs, and they lead to very different software. One gives you a chatbot and expects you to prompt it. The other quietly completes the task and hands you the result.

Amber Case, who formalised calm technology into a set of eight principles in her 2015 O'Reilly book, put it this way: "technology can communicate, but doesn't need to speak." An ambient AI doesn't ask you questions. It watches, scores risk, completes work, and surfaces itself only when what it has to say earns the interruption. A conversational AI, by contrast, is an attention request with a friendly face.

So why does almost every productivity tool ship the conversational kind? The honest answer is that it's easier to pitch. An ambient AI that silently removes work is invisible in a demo. There's nothing to point at. A chatbot at the bottom of the screen, on the other hand, is a screenshot. It's an "AI-native" bullet on the pitch deck. It's what venture capital recognises as progress, because it looks like the other AI products they've already funded.

There is a question worth asking about any AI feature you encounter, and it's uncomfortable: is this here to make my work easier, or is this here so the company that makes my software can say "AI-native" in their next funding round? The answer, more often than anyone in the industry wants to admit, is the second. AI has become the most expensive novelty feature in the history of software. Added because the board asked for it, the analysts expected it, or the term sheet required it. Not because anyone measured whether it made users more productive. When the measurement finally got done (see the Newport study above), the answer turned out to be no.

The tools that feel best to use are the ones built for the people using them. The tools that feel like they're trying to impress someone in the room are usually trying to impress someone who isn't: a buyer two layers removed, an analyst writing a category report, an investor scanning a dashboard for keywords. You can feel it. Users always can.

You wanted some of your work to disappear. You were sold a chatbot and a small increase in how much of the day is spent talking to your tools.

Do you want to be alone with the deadline?

Here is the one that usually goes unsaid. When a deadline is approaching and the system knows you haven't acted, what should happen?

The conventional answer is that the system should shout louder at you. A redder badge. A more aggressive email. A pop-up. A push notification on your phone at seven in the evening.

The better answer, if you stop to think about it, is that the system should quietly involve someone else. Not your manager. That's punishment disguised as escalation. A peer. Someone at your level who can see the approaching miss and offer help before it becomes a miss at all. This is how cockpits work: one pilot flies, one pilot monitors, and the monitoring pilot's job is precisely to catch what the flying pilot is about to miss. Neither is shamed when the catch happens. The catch is the point.

Productivity software almost never works this way. It treats accountability as an individual sport because that was the model inherited from the consumer-app tradition: one user, one account, one feed. But professional work is not a consumer activity. It is a team activity in which the team is held responsible together, and the tool should reflect that reality rather than fight it. You want not to be alone with the deadline. No software that treats accountability as a solo performance can give you that, no matter how many unicorns it produces when you succeed.

Do you want to be sold to, or served?

The last question is the awkward one. Most software that demands your attention does so because the people who built it are paid, directly or indirectly, to extract more of it. Ad-supported products do this openly. Subscription products do it quietly, through retention metrics and upsell funnels that reward the team for keeping you engaged. Enterprise products do it through "seat expansion" strategies that reward growth inside your organisation regardless of whether anyone is using the thing for real work.

Tim Wu, in The Attention Merchants (2016), traced this business model back a hundred and fifty years: from the penny press of the 1830s to the modern social feed, via radio advertising, television, and the supermarket checkout. The pattern is always the same: find a reason to gather human attention, then find someone to sell it to. The last decade of B2B SaaS, quietly, has been an application of that old pattern to a new audience. Professionals who used to be customers of their tools have, without quite noticing, become the product again.

Software cannot be calm if the business model behind it depends on it being noisy. Calm in the UI has to be paid for by calm in the business model too. A product whose growth depends on being indispensable will, sooner or later, reveal that dependence in its design. A product whose growth depends on being trusted will, sooner or later, reveal that too.

The tradition we're standing in

Nothing in this piece is an original idea. It is a synthesis of work done by researchers, designers, engineers, and critics over the last three decades, and it helps to see that tradition laid out in one place, so that no one reading this mistakes the manifesto below for a novel claim rather than a continuation.

• 1990 James Reason, the Swiss cheese model Human error is systemic, not individual. Safety comes from multiple overlapping layers of defence, not from one perfect human.
• 1995 Weiser and Brown, Designing Calm Technology Xerox PARC. "Simplify complexities, not introduce new ones." Technology should live in the periphery of attention and only move to the centre when genuinely needed.
• 2009 Atul Gawande, The Checklist Manifesto A two-minute surgical checklist cut deaths by nearly half. Resilience comes from structure, not heroics.
• 2015 Amber Case, Calm Technology Eight principles for non-intrusive design, including "technology should work even when it fails" and "technology can communicate, but doesn't need to speak."
• 2016 Cal Newport (Deep Work) and Tim Wu (The Attention Merchants) Newport names focus as the scarce resource of the knowledge economy. Wu traces 150 years of attention-as-product, connecting modern SaaS to the penny press.
• 2018 Harris, Raskin, and Fernando, Center for Humane Technology Names the engagement-maximising design pattern as an industrial harm. "The race to the bottom of the brain stem."
• 2018 Fried and Hansson, It Doesn't Have to Be Crazy at Work A company can be optimised for calm, not chaos. Growth-at-all-costs is a choice, not a law of nature.
• 2019 Shoshana Zuboff, The Age of Surveillance Capitalism The extraction of "behavioural surplus" from users as the dominant business logic of the modern internet. Names the economic engine beneath the attention economy.
• 2024–25 The AI productivity paradox Empirical evidence (the 164,000-worker study, Newport's analysis, IBM's generative-AI design principles) that AI tools, when designed as chat interfaces, increase shallow work and crowd out deep work. The attention economy arrives inside the productivity suite.

Calm design, in other words, is not a new idea. It is a thirty-year-old idea that has mostly lost to a noisier one, because the noisier one was easier to monetise. What's new is that the consequences have become impossible to ignore, and that the people building the next generation of professional tools, and the people buying them, have started asking the question at the top of this piece.

The manifesto, consolidated

A manifesto for calm design

We are the people who think software has forgotten what it was for. We are not against delight, or AI, or even the occasional unicorn. We are against the premise that a tool's success is measured by how much of its user's attention it can capture. We think that premise is wrong for consumer software and catastrophic for professional software, and we think it is past time to name the alternative and commit to it in public.

These are the tenets we build under. We invite others who build software to adopt them, extend them, or argue with them, so long as the argument moves the industry somewhere better than where it is now.

1. Calm software is a hallway, not a room.Its job is to let you pass through. Every decoration that delays you is a decoration that costs you something.
2. Every feature must earn its place.Features exist to decrease friction against the core promise. Novelty, competitor-matching, and roadmap-filling are not reasons to ship. The Swiss Army knife has a dozen blades and most of them are worse than the dedicated tool.
3. Daily active minutes is a failure metric.If our users are in the app more than the work requires, we are doing something wrong.
4. The system owns the structure; the human owns the judgement.A missed deadline is a failure of the system before it is a failure of the person.
5. Surveillance is the opposite of calm.Privacy is not a feature. It is a precondition. Client data belongs to clients, not to training corpora.
6. AI should be ambient, not conversational.It should reduce the surface area of attention, not create a new one. Quiet completion beats clever chat.
7. Build for users, not for investors.A feature that exists to impress a boardroom will never quite work in a workflow. If the honest reason for shipping something is a term sheet or a category report, don't ship it.
8. Accountability is a team sport.A peer is the first backstop; a manager is the last. No one should be alone with a deadline that matters.
9. Calm is a business model, not a skin.If the incentives are noisy, the software will be noisy eventually. Calm has to be paid for all the way down.
10. The minimum effective intervention wins.When the system needs to speak, it speaks once, clearly, and then stops. It never cries wolf.
11. We design for the practitioner, not the platform.The person using the software is not a consumer whose attention is the product. They are a professional whose attention is their instrument.
12. If you have to ask whether the unicorn belongs, it doesn't.Calm design is what's left after you remove everything the work didn't need.

We are standing on the shoulders of Weiser and Brown, Case and Gawande, Reason and Newport, Harris and Zuboff, Fried and Hansson, and the many quieter researchers, designers, and practitioners whose work we have not had room to name. What we are trying to do is carry their argument into the part of the industry where the stakes are highest and the noise has been loudest: software for people whose work cannot afford to be interrupted.

If this is the category of software you are trying to buy, or build, or work inside, we're glad you're here. There are more of us than you might think.

Further reading

1. Weiser, M. & Brown, J.S. (1995). Designing Calm Technology. Xerox PARC.
2. Reason, J. (1990). Human Error. Cambridge University Press.
3. Case, A. (2015). Calm Technology: Principles and Patterns for Non-Intrusive Design. O'Reilly.
4. Gawande, A. (2009). The Checklist Manifesto: How to Get Things Right. Metropolitan Books.
5. Newport, C. (2016). Deep Work: Rules for Focused Success in a Distracted World. Grand Central.
6. Wu, T. (2016). The Attention Merchants. Knopf.
7. Harris, T. et al. Center for Humane Technology, humanetech.com.
8. Fried, J. & Hansson, D.H. (2018). It Doesn't Have to Be Crazy at Work. HarperBusiness.
9. Zuboff, S. (2019). The Age of Surveillance Capitalism. PublicAffairs.