Software has become very good at getting our attention.
A notification appears. A badge turns red. A counter increases. A vibration tells us something happened. An application asks us to come back. Another asks us to maintain a streak. Another sends an email because we have not opened it recently.
None of these interactions are necessarily bad on their own. The problem begins when they become the default language of software.
Modern products often behave as though attention is the resource they are trying to maximize. More opens. More sessions. More clicks. More notifications. More time spent.
But time spent inside software is not always evidence of value.
Sometimes the best product experience is the opposite. You open something, accomplish what you came to do, and leave. Nothing tries to keep you there. Nothing asks for another action. Nothing competes for the next five minutes of your attention.
The software simply does its job.
That is the idea behind calm technology. And for us, it is becoming an important way to think about how software should behave.
The idea is older than it sounds
The phrase calm technology is strongly associated with Mark Weiser and John Seely Brown, who explored the idea in their work at Xerox PARC.
Their 1996 paper, The Coming Age of Calm Technology, was written during a period when personal computing and the early internet were rapidly changing how people interacted with computers.
Their argument was not that technology should disappear completely. It was more interesting than that.
They imagined a world in which computing would become increasingly embedded in everyday life. Instead of requiring a person to sit down in front of a computer and explicitly enter a digital environment, computing could become part of the environment itself.
This connects to Weiser's earlier idea of ubiquitous computing: technology becoming so integrated into ordinary life that its presence becomes less noticeable.
The important question was therefore not simply what can computers do? It was how should computers fit into human life?
That distinction matters.
A technology can be technically impressive and still make life worse. A product can have hundreds of features and still require too much attention. A system can be powerful while creating unnecessary cognitive work.
Calm technology begins by asking what happens when we design in the opposite direction.
Technology does not always need the center of our attention
One of the most useful ideas in calm technology is the distinction between the center and the periphery of attention.
Human attention is limited. When we are writing, we may be aware of the document in front of us while simultaneously being aware of the sound of rain outside. When we are walking, we may be focused on where we are going while still noticing traffic, temperature, and movement around us.
Our minds constantly move information between the center and the periphery.
Technology can work in a similar way.
Some information deserves our full attention. Other information does not.
A navigation system, for example, may not need to display a giant message every second. A subtle directional cue can sometimes be enough. A battery indicator does not need to interrupt us every few minutes. It can quietly remain available when we need it. A financial application may not need to tell us about every tiny change in our spending immediately — sometimes the right experience is simply to let us look at the information when we choose.
This leads to an important design principle: not every piece of information deserves an interruption.
The problem with attention as a product metric
There is an uncomfortable incentive built into much of modern software.
If a company measures success primarily through engagement, then increasing engagement can become the objective. That sounds reasonable until we ask what engagement actually means.
A user spending thirty minutes in an application could mean:
- the application is genuinely useful;
- the user is exploring something;
- the application is difficult to use;
- the user is distracted;
- the product is repeatedly interrupting them;
- the product has created a habit that has little relationship to actual value.
Time is not the same thing as value.
For some products, reducing the time required to complete a task is a sign of better design. Imagine a banking application where transferring money takes ten minutes. If a redesign reduces that to thirty seconds, the application has become dramatically better. But if the company's primary metric is time spent in app, that improvement could theoretically look like a negative result.
This is one reason product metrics need context. The goal should not always be to maximize interaction. Sometimes the goal is to minimize unnecessary interaction.
Calm does not mean boring
There is a common misunderstanding about calm technology.
Calm does not mean plain, lifeless, slow, or boring. It does not mean lacking in personality, or being visually minimal at all costs.
A calm product can still be beautiful. It can still have animation. It can still feel delightful. It can still communicate personality and emotion.
The difference is that the interface does not constantly demand attention.
A good animation can explain a state transition. A subtle motion can establish hierarchy. A carefully designed sound can communicate completion. A visual change can help someone understand what just happened.
The problem is not motion, color, sound, or animation. The problem is attention without purpose. If an interaction exists only because it increases the chance that someone will keep looking at the screen, we should question it.
Calm software should respect the user's intention
When someone opens a product, they usually have an intention. They want to record something, find something, understand something, communicate something, make a decision, or complete a task.
Good software helps them accomplish that intention. Bad software gradually replaces the user's intention with the product's intention.
You opened the application to check one transaction. Now you are looking at a recommendation. Then a notification. Then a new feature. Then a banner. Then something else. Ten minutes later, you are still inside the application.
The product has successfully captured your attention. But did it successfully serve you?
These are different questions. We think products should be designed around the second one.
Calm technology is especially important for personal software
This becomes even more important when software deals with parts of people's lives that already require attention. Finance is one example. Health is another. Education is another. Productivity is another.
These are not domains where we necessarily want software to constantly demand more interaction.
Consider a personal finance application. The purpose should not be to make someone spend more time looking at charts. The purpose should be to help them understand their financial situation and make better decisions.
If the application can communicate the important information in thirty seconds, that is potentially a better experience than forcing someone to spend fifteen minutes exploring dashboards.
The product becomes useful partly because it knows when to stop talking.
Designing for the periphery
The idea of peripheral information becomes especially interesting when we design modern interfaces.
Not everything should be presented with the same visual weight.
Consider a financial dashboard:
- The current balance might be central.
- A recent transaction might be secondary.
- A long-term spending trend might sit further in the background.
- An informational note might be available if someone wants to inspect it.
This creates layers of attention.
Instead of treating everything as equally important — everything bright, everything urgent, everything demanding attention — we can design in tiers:
- Primary — what matters right now.
- Secondary — what helps explain it.
- Peripheral — what is useful when needed.
Good visual hierarchy is therefore not just an aesthetic technique. It is an attention-management system.
Notifications should earn their existence
One of the easiest ways to make software less calm is to add notifications indiscriminately. Notifications are powerful because they cross the boundary between an application and the rest of someone's life. That means they should have a high bar.
Before sending a notification, we should be able to answer:
- Why does the user need to know this now?
- What can they do with this information?
- Is the information time-sensitive?
- Would delaying it materially reduce its usefulness?
- Could the information simply wait until the user opens the product?
If the answer to these questions is unclear, the notification probably does not need to exist.
This does not mean notifications are bad. A security alert can be important. A payment failure can be important. A time-sensitive event can be important.
The principle is simply: interruption should be proportional to importance.
Do not manufacture urgency
Some products create urgency because urgency improves engagement. A red badge. A countdown. A disappearing reward. A streak. A reminder that something is waiting for you.
Sometimes these mechanisms are appropriate. But they can also create a strange relationship between the user and the product.
Instead of asking what does the user need?, the product begins asking how can we make the user feel that they need us?
Those are very different philosophies. We want software to earn attention through usefulness rather than manufacture anxiety around losing it.
Calm technology and trust
There is another reason calm interfaces matter. They can make software feel more trustworthy.
A product that constantly interrupts can feel as though it is trying to extract something from the user. A product that communicates clearly, behaves predictably, and gets out of the way can feel different. The user learns: if something really matters, the product will tell me.
That is a powerful relationship.
Predictability reduces cognitive load. If the interface behaves consistently, users do not need to constantly reinterpret it. If notifications are rare but meaningful, users learn to take them seriously. If important information has a stable location, users know where to find it.
Calmness therefore isn't merely visual. It is behavioral.
The engineering side of calmness
Calm technology is not only a design problem. It is also an engineering problem.
A product can have beautiful visual design and still be stressful because of technical behavior. For example:
- slow loading;
- unpredictable errors;
- repeated authentication;
- data loss;
- inconsistent synchronization;
- confusing failure states;
- duplicated actions;
- unreliable notifications.
All of these create cognitive noise.
This is why calmness often comes from invisible engineering work. Caching can make an application feel instantaneous. Good state management can prevent confusing transitions. Reliable synchronization can prevent users from wondering whether their data was saved. Good error handling can turn a technical failure into an understandable message.
The user may never notice these engineering decisions. That is precisely the point.
Calmness is not the absence of feedback
A calm application still needs feedback.
When I tap a button, I should know whether something happened. When I save a transaction, I should know whether it was saved. When data is synchronizing, I should understand its state. When something fails, I should know what happened.
The difference is between useful feedback and attention-seeking feedback.
Useful feedback answers what just happened? Attention-seeking feedback asks how can I get you to interact again?
The former improves usability. The latter can easily become manipulation.
Our principles
For products we build at Sarezo, calm technology translates into a fairly simple set of questions.
Does this interaction need to exist?
Every interaction has a cost. If removing it makes the product easier to understand without reducing its usefulness, remove it.
Does this notification deserve an interruption?
If not, keep the information inside the product.
Is the interface communicating hierarchy?
If everything looks important, nothing looks important.
Are we optimizing for value or engagement?
Engagement can be useful to measure. It should not automatically become the product's purpose.
Can the user leave?
This is perhaps the simplest test. A good product should allow someone to accomplish what they came to do and leave without feeling that they are abandoning something.
The quiet product
The best technology may not always be the technology we notice most. Sometimes it is the technology that quietly removes friction.
The calendar that prevents you from forgetting something. The system that synchronizes your data without making you think about synchronization. The financial application that helps you understand where your money went without turning your finances into a game. The interface that gives you exactly the information you need and no more.
This is not an argument against ambitious software. It is an argument for software that understands its place.
Technology should be powerful enough to help us, but restrained enough not to constantly compete with everything else happening in our lives.
We do not want our products to disappear because they are unimportant. We want them to disappear because they have done their job.
That distinction is the heart of calm technology.