Most of the products we work on are not discretionary. People open a banking app because a payment failed, a control interface because a run is behaving oddly, a configurator because a specification is due. The interesting design problems are therefore not on the happy path. They are in error states, interruptions, handovers and recovery.

We work from observed behaviour rather than stated preference, which means instrumenting what exists, sitting with the people who use it, and being specific about which small group of intentions accounts for most of the sessions. That distinction drives the architecture: a few things fast and obvious, everything else findable.

We design and build in the same team, on the same cadence, from the first week. A specification handed over a wall arrives at the point where the tradeoffs have already been made in ignorance of what they cost.