Designing for systems, not screens

An interface is the visible edge of an architecture. It is the part users touch, so it absorbs most of the attention — and most of the blame when a product feels wrong.

But interface problems are usually architecture problems wearing a costume. A confusing screen is often an honest reflection of a data model that never decided what an entity was, or an operating process that has three owners and no decision rule.

So we sequence the work differently. Before any layout, we write down the entities, the states they move through, and who is accountable for each transition. The interface then becomes a rendering of a system that already makes sense.

The payoff is not aesthetic, it is economic. Systems designed this way absorb new requirements instead of fracturing under them.