The Interface Has to Tell the Truth

A polished screen proves that someone produced a convincing appearance; you still need evidence that it explains the product honestly. A saved indicator, an empty list and a disabled button each make a claim about what the software knows or permits. Those claims deserve the same scrutiny as the action behind them.

In Programming Isn't Special, Glyph argues that programming belongs among creative practices and that removing everyday work can remove opportunities to develop judgment. He also points to a gap between software's aesthetic experience and its internal state. That gap gives teams a concrete question to investigate when reviewing generated interfaces.

Gunner Technology's position is that interface judgment belongs inside the factory's acceptance process. An agent can assemble the screen and exercise the workflow. People still decide whether the result gives users a clear, useful understanding of what happened. Passing implementation checks alone cannot settle that question.

Specify what the person should understand at each meaningful state of the workflow. State means the condition the product is in: waiting for a response, holding an unsaved change, confirming completion or reporting a failure. For each condition, name what is known, what remains uncertain and what the person can do next.

Take a hypothetical settings form. After someone selects Save, the interface needs to distinguish a request in progress from a confirmed update. If the connection fails before confirmation, decide how the product will explain that uncertainty and preserve the person's input. Give the builder those decisions before it chooses an animation or writes a reassuring message.

This is a specific application of Product Sense Has to Leave Your Head. Record the promise in the task: which event permits a success message, which failure leaves the result unknown and which recovery action is safe. An instruction to make the experience intuitive leaves all those choices unresolved.

Compare the visible message with independently observed system behavior while deliberately delaying or failing the action. In the settings example, hold the response, reject the update and interrupt the connection after the server receives it. Inspect what the screen says in each case and whether the saved value agrees with it.

Have a separate verifier run those conditions against the candidate change. Keep the starting data, the induced failure, the resulting state and the browser evidence together. The builder should not get to replace an awkward failure with a convenient demonstration. A recording of the success path leaves the difficult promise untested.

A screenshot captures appearance at a moment. A browser test can establish whether the message followed the agreed event and whether input survived a failed request. A reviewer then judges whether the explanation is understandable. As with the limits of green tests, choose evidence for each claim instead of asking a passing suite to certify everything.

Check that people using assistive technology can perceive the same meaningful result as people watching the screen. A changing icon may be obvious visually while leaving a screen reader user unaware that anything happened. Review the information delivered through each supported interaction, including keyboard navigation and spoken feedback.

The World Wide Web Consortium's guidance on status messages explains how messages about results, waiting and errors can be exposed to assistive technology without taking focus. It also cautions against excessive announcements. The review needs to establish that the relevant change is available and understandable without making every update an interruption.

Put those expectations into the same workflow specification. Preserve keyboard focus where the task requires it, expose the outcome and make recovery reachable. Automated checks can cover repeatable conditions. Keep a person responsible for judging whether the combined experience is coherent; an accessibility report alone cannot decide that the product explained an uncertain save well.

Give the person approving the change a working flow with its uncomfortable states ready to inspect. Ask them whether they know what happened, whether their work is safe and what they would do next. If the answer requires the builder to explain information the interface hides, send the change back with that specific gap.

Settle recurring decisions before the next build. Keep accepted language, state rules and recovery behavior beside the components that implement them. Our argument in Understanding Cannot Wait for Code Review applies here: decisions made before implementation can shape every generated screen instead of becoming late corrections to each one.

Start with a workflow in a product you own. Make the factory produce evidence for its promises, then approve the experience after seeing what happens when the action stalls or fails. The typing and routine checking belong to the machinery. Deciding whether the result respects the person using it remains your call.