The App Has Received Your Uncertainty

I keep pressing buttons twice. Not because I am especially impatient, but because many apps make the first press disappear.

I submit a form, upload a file, change a setting, report a problem or send a message. The button changes colour for a fraction of a second. Sometimes the phone vibrates. Sometimes a spinner appears and disappears before I have understood what it was supposed to mean. The interface has confirmed that my finger touched the screen, but it has not confirmed that the action entered the system.

These are not the same thing.

A few days ago, after my Apple Developer account changed from an individual account to a company account, all of my TestFlight apps disappeared. App Store Connect still contained the apps. TestFlight still behaved as if I should have access to them. Somewhere inside Apple's systems there was probably a relationship between the old account, the new organization, the builds, the tester record and my Apple ID. From my side, all of those states collapsed into one blank screen.

The app did not tell me whether access was being migrated, had failed to migrate, had been revoked, was waiting for an invitation or was attached to an identity that no longer existed in the same form. It only showed me the result of a system I could not inspect.

This is what a lot of app feedback looks like now. The interface acknowledges the gesture but hides the process.

When I move a folder into iCloud, the visible action resembles moving an ordinary folder. Underneath, the system may be copying files, calculating changes, uploading them, resolving versions, deciding what remains local and waiting for another device to synchronize. When I upload a build, the system may be validating it, scanning it, processing symbols, checking entitlements and distributing it through several internal services. When I submit a job application, the employer may receive it, filter it, score it, pause the role or never open it. When I report a post, the report may enter a moderation queue, be grouped with other reports, be automatically classified or be closed without a human seeing it.

The app knows at least some of this. I usually know none of it.

We tend to describe feedback as a small design detail. Press a button and show a response. Add a loading state. Display a toast. Disable the button so the user does not press it twice. In design systems, feedback becomes a collection of components: spinner, progress bar, snackbar, badge, alert.

But feedback is not really a component. It is the interface's account of reality.

It tells me what the system believes has happened, what is happening now and what could happen next. A good interface does not only respond to my action. It exposes enough of the state change for me to build a model of the system.

The reason many apps give weak feedback may be that honest feedback is much harder than drawing a spinner. To say that a file is uploading, the product needs a reliable upload state. To show that a request is queued, the backend needs to expose the queue. To explain that processing failed, the system needs an error that means something outside the service that produced it. To tell me when something will finish, the company needs to understand its own process well enough to make a prediction.

The visual layer is often the last and easiest part.

A product team can make the button respond even when the organization behind the button does not have a coherent answer. The frontend knows that it sent a request. The API knows that it accepted the request. Another service knows that the job entered a queue. A third service knows that the job failed. Support may know that this failure is common. Nobody has assembled these fragments into one state the user can see.

The user experiences one action. The company experiences five systems.

This may be why apps so often compress a long chain of materially different states into the word “processing.” Received, waiting, running, delayed, blocked, partially complete and failed are not cosmetic variations. They imply different decisions for the user. I should wait if the system is still working. I should retry if the request never arrived. I should change something if my input was rejected. I should contact someone if the process is blocked. I should stop pressing the button if it has already succeeded.

When all of those states look the same, the user has to invent the missing feedback.

I refresh the page. I close and reopen the app. I check another device. I search Reddit to see whether other people are experiencing the same thing. I press the button again. I wait longer than necessary because I am afraid of interrupting a process that may not exist. Or I interrupt a process that was working because the interface gave me no evidence that it was alive.

The uncertainty does not disappear. It moves from the system into my head.

There is a common idea that interfaces should feel clean. Status text, timestamps, activity histories, progress details, retry controls and technical explanations are seen as clutter. The ideal screenshot contains a large title, one obvious action and enough empty space to make the product feel calm.

But a screenshot is not waiting for an upload to finish.

Removing the representation of complexity does not remove the complexity. It removes the user's ability to locate themselves inside it. The system remains complicated, but now the complication is experienced as doubt.

I think “clean interface” has gradually become confused with “interface that does not admit what is happening.” The app is calm because the user is carrying the anxiety for it.

There is another reason companies may avoid precise feedback. Feedback creates accountability.

Once an app says, “We received your request at 13:42 and it is waiting for manual review,” it has created a record. It has admitted that the request exists, that the company owns a review process and that time is passing. If the app says the review usually takes two days, the user can notice when it takes ten. If it says a payment failed because the bank rejected it, the user can question that explanation. If it says a report was closed because the content did not violate a specific rule, the decision can be compared with the rule.

“Something went wrong” makes almost no commitments.

The most expensive part of feedback is not the progress bar. It is the promise hidden inside it.

This is especially visible in institutional apps. Job portals, healthcare systems, immigration websites, insurance services, banking apps and moderation systems accept actions that can affect someone's life, then often reduce the process to “submitted.” The interface looks simpler than an old paper bureaucracy, but it can be harder to understand. A paper form at least becomes a physical object. It can be stamped, copied, signed, misplaced and found. The digital form disappears into a system whose internal movement is represented by one grey label.

Apps increasingly behave like institutions while still being designed as if they were collections of screens.

They receive documents, make decisions, impose waiting periods, change access, distribute money, judge eligibility and sometimes punish people. Yet the design language remains strangely casual. A rounded button, a friendly illustration and a checkmark are asked to represent an administrative process that may involve several organizations and no clear owner.

The result is not frictionless. It is bureaucracy without visible bureaucracy.

Optimistic UI makes this even stranger. The interface immediately behaves as if an action succeeded because waiting for the server would feel slow. Usually this is useful. A heart fills instantly. A message appears in the conversation. An item disappears from a list. The app feels responsive because it temporarily treats intention as reality.

But when the operation later fails, the interface has to quietly reverse itself. The heart becomes empty again. The message disappears. The setting changes back. If the user does not notice the reversal, the app has produced a false memory of success.

The interface was not showing the system state. It was showing a hopeful prediction.

There is nothing inherently wrong with prediction, but it should remain distinguishable from confirmation. “Sending” is not “sent.” “Saved on this device” is not “synced.” “Request received” is not “request approved.” “Report submitted” is not “content reviewed.” These distinctions matter precisely because the user cannot see the infrastructure directly.

Feedback is how invisible systems become legible.

I do not think every app needs a control room full of logs. More information can also become a way of avoiding explanation. A hundred technical events are not necessarily more useful than one clear sentence. The design problem is not to expose everything the system knows. It is to expose the states that change what the user should believe or do.

Did the app receive the action? Is work continuing after I leave the screen? Has responsibility moved to another person or service? What outcome occurred? Can I recover? When should I become concerned? Where can I later verify what happened?

These questions sound basic, but answering them forces the product to connect the interface to the actual operation behind it. That may be why so many apps stop at the animation. The animation can be designed without redesigning the organization.

I used to think feedback was what happened after an interaction. Now I think feedback is the part of the interaction where the system reveals whether it has entered into a relationship with me.

The button is my side of the relationship. I acted. The feedback is the system's side. It acknowledges not only that I touched the screen, but that something accepted responsibility for what happens next.

Without that, the interaction is incomplete. The app has received my tap, perhaps. What it has really given back is uncertainty.

Connected reading

• When Systems Teach Us Not to Try
• The Most Dangerous Interface Is the One That Says Everything Worked
• A Toggle Is Not an Explanation
• Some Apps Explain Themselves
• The Interface Is Now Part of the Answer

AI authorship note

This essay began with Kris Haamer asking why apps so often fail to give feedback and which familiar apps are especially bad at making their state visible. AI helped develop the argument that feedback creates accountability, connect the examples into a longer essay, draft, edit and implement the publication. Kris supplied the recent TestFlight account-transition experience, chose the Raw Drafts framing and approved the article for publication.