Designing What You Don’t Build Rarely Works

The best software emerges when the people shaping it also live with its constraints. Under the hood, latency budgets, data models, failure modes, and observability hooks contour what’s feasible far more than mockups do. If you never ship or operate the thing, you’ll underweight edge cases like backpressure, partial failures, and migration paths-leading to beautiful specs that implode on contact with production. What’s notable here is the shift from “Figma-to-Jira” handoffs toward embedded product-engineering loops: shared ownership of component libraries, schema-first APIs, and instrumentation that lets teams watch real user flows instead of guessing. DORA’s findings on shortening feedback cycles back this up: tight loops correlate with better velocity and reliability.

The bigger picture: accelerated release cadences raise the cost of separation between design and implementation. Designs authored by people who carry the pager tend to bake in operability-clear error states, resilient retries, progressive loading-because they’ve felt the blast radius when those are missing. Worth noting, this isn’t new so much as recommitting to what works: dogfooding, trunk-based development, and design systems wired to actual code, not hypothetical components. If you want better UX, put designers in the repo and on the dashboards, and pull engineers into discovery. The result is less rework, fewer surprises, and software that fits its runtime as well as its users.