One of the most common patterns we see in troubled software projects is design treated as the last step before development, rather than a discipline that shapes what gets built in the first place.
The cost of that ordering shows up later, when a fully-built feature turns out to solve the wrong problem, or solves the right problem in a way users find confusing. Fixing that after development is expensive; fixing it at the wireframe stage is a redraw.
Effective UX work starts with a genuinely open question — what is the user actually trying to accomplish — rather than assuming the first idea is the right one. Talking to five real users before building anything routinely surfaces assumptions worth revisiting.
It also means treating design as testable, not just reviewable. Internal opinions about whether an interface is "intuitive" are a weak signal; watching someone unfamiliar with the product try to complete a task is a much stronger one.
None of this requires a large research budget. Even a handful of structured conversations with real or representative users, run before development starts, meaningfully changes what gets built — and how much rework happens after launch.
