devotionn Redesign
Use when
Improving an existing UI without intentionally replacing its product behavior.
Procedure
- Inventory current behavior, routes, data, forms, actions, states, analytics hooks, and accessibility contracts.
- Capture the existing rendered surface when possible before modifying it.
- Diagnose problems by category: hierarchy, density, consistency, tokens, components, interaction, accessibility, responsive behavior, content, and visual direction.
- Preserve functional contracts unless the brief explicitly changes them.
- Prefer system-level corrections over isolated cosmetic patches.
- Implement incrementally so regressions can be attributed.
- Compare before/after behavior and render representative states.
- Run available tests and gates.
- Critique the redesigned result independently of whether gates pass.
Failure conditions
A redesign is not successful merely because it looks different. Missing functionality, inaccessible interactions, fabricated data, or removed states are regressions unless explicitly required by the brief.