Process
The process is designed to prevent two expensive mistakes: scaling the wrong idea and calling an unverified build finished.
Before design starts
We get the business, audience, evidence, constraints, and decision owner into view. That turns a broad redesign request into a clear reason for the site to change.
Your partBring the honest context: what is working, what is not, and what cannot move.
Before the build scales
The narrative, information architecture, visual direction, and representative mobile behavior are resolved before they multiply across pages.
Your partChoose a direction and respond to the tradeoffs, not isolated decorative details.
Before anyone calls it finished
The implementation is reviewed in the browser across meaningful widths, keyboard paths, motion preferences, performance constraints, metadata, and the hosted candidate.
Your partApprove the exact release, domain action, and rollback—not a vague idea of “the latest.”
A clear boundary
You should always know what is being decided, what evidence supports it, and what happens after approval. That keeps feedback useful and prevents the project from turning into a long chain of disconnected preferences.
