The UX Decisions That Should Exist Before a Website Build Starts

A design handoff can be visually complete and still be incomplete for the team building the product.

The missing piece is usually UX behavior.

Before implementation starts, the product team should already know how the interface behaves when the user is confused, when data is missing, when an action fails, when the viewport changes, and when two actions compete for attention.

That work is not decoration. It is product architecture.

What should exist before the build starts

A useful UI/UX phase should leave behind more than screens. It should define:

• page intent and user priority
• hierarchy between primary and secondary actions
• loading, empty, error, and success states
• mobile behavior and content collapse rules
• interaction feedback and motion restraint
• forms, friction points, and conversion paths
• content patterns that engineering can reuse

If those decisions are unresolved, frontend implementation becomes a guessing exercise. The team can still ship the page, but the experience starts to drift from the business goal.

This is especially visible in agency and product websites. The visual system can look premium while the actual flow asks users to do too much work.

MDX treats UI/UX design as part of the product system rather than a final visual pass: https://mdx.so/ui-ux

That is the right mental model. Strong UI/UX reduces ambiguity for users and for the team building the experience.