<- Back to blog
April 28, 20264 min read

Building Interfaces That Leave Evidence

A short field note on designing software that records what happened, what changed, and what deserves attention next.

A good interface does not merely let someone complete a task. It leaves a trace of what changed, why it changed, and where the next useful decision lives.

SignalInputs are visible before action.
StateChanges stay legible after motion ends.
ProofThe system explains what it just did.

Interface Memory

Most product screens are obsessed with the moment of action: click the button, save the form, move the card, ship the change. The better question is what the user can understand after the action is over.

Evidence is the small residue an interface leaves behind. It can be a status line, a timestamp, a diff, a highlighted row, a quiet undo affordance, or a sentence that names the result in human terms.

The interface should not ask people to remember what the interface itself already knows.

Three Kinds Of Proof

When I am designing operational software, I look for three layers of proof. They sound small, but together they turn a screen from a control panel into a reliable collaborator.

01

Before

Show the user what the system believes is true before they commit to changing it.

02

During

Make progress visible without turning waiting into theater.

03

After

Record the outcome in the place where the user will look next.

Designing For Afterwards

The most useful design work often happens one beat after the obvious flowchart ends. What does the page look like when the import succeeded but three rows were skipped? What does the next teammate see tomorrow? What does the user need if they come back from a meeting and have forgotten the context?

These questions lead to calmer software. Less decoration, more continuity. Fewer triumphant modals, more durable state. It is not about making the interface loud; it is about making it accountable.

Field note

If a user has to open a second tab, check a log, or ask a colleague whether something worked, the interface probably failed to leave enough evidence.

A Small Checklist

  • Name the changed object, not just the action.
  • Keep the last important result visible until a newer result replaces it.
  • Put recovery next to confirmation, especially when the action is reversible.
  • Prefer specific empty states over generic success messages.

This is the kind of detail that rarely makes a screenshot more dramatic. But it makes the product feel sturdier in actual use, which is usually the better ambition.

Back to all notes