Redesign projects attract attention because visual change is easy to see. The most damaging regressions are less obvious: visitors cannot predict a menu label, keyboard focus disappears, a form asks for information too early, mobile content shifts under a thumb, or a persuasive proof point is removed because it looked untidy. Human-centred design starts with users, context, tasks, and evaluation—not with a preference vote. This guide provides a pre-launch review that protects usefulness while still allowing the brand to evolve.

Warning sign one: the brief describes style, not behavior

The project is framed around modernity, freshness, or premium appearance without naming the user decisions and tasks that must improve. A team can deliver every visual request and still make the service harder to understand, compare, trust, or complete. The important distinction for product owners, marketing teams, designers, developers, and executives sponsoring a website or application redesign is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Collect top tasks from analytics, search terms, support contacts, sales questions, and interviews, then rank them by user importance and business consequence. Translate the redesign brief into task outcomes, audience constraints, content requirements, accessibility needs, and measurable guardrails. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Baseline task completion, time, error, confidence, form progression, and qualified conversion for representative journeys.

ISO human-centred design guidance treats understanding context and evaluating designs as lifecycle activities, not a final taste check. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • What task must become easier?
  • Which audience constraint matters?
  • What evidence supports the brief?
  • What must not regress?

Analytics shows behavior at scale but cannot fully explain intent; qualitative research adds explanation but uses smaller samples. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Warning sign two: navigation labels reflect the company

Menus use internal department names, clever campaign language, or service jargon that visitors do not use when describing their need. People then scan repeatedly, open several pages, or abandon because the information scent does not match their goal. The important distinction for product owners, marketing teams, designers, developers, and executives sponsoring a website or application redesign is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Run open card sorting, tree testing, search-log review, and moderated navigation tasks using participants who resemble intended visitors. Prefer clear labels, group related choices, expose high-priority paths, and preserve stable routes during migration. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Track first-click success, path length, backtracking, search use, and task confidence before and after the proposed structure.

A clickable navigation test can expose architecture failure before visual design and content production make it costly to change. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Would a customer use this label?
  • Where does the first click go?
  • Which choices overlap?
  • What old URL needs redirection?

A taxonomy cannot optimize every audience equally; prioritize primary tasks and provide search or contextual routes for secondary needs. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Warning sign three: mobile is a compressed desktop

Desktop layouts are squeezed into narrow screens while sticky elements, large headings, carousels, and dense forms compete for limited space. Mobile use also includes touch, interruption, variable networks, different postures, and accessibility settings—not merely fewer pixels. The important distinction for product owners, marketing teams, designers, developers, and executives sponsoring a website or application redesign is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Test on real devices with zoom, large text, weak connectivity, screen rotation, keyboard entry, and one-handed reach. Prioritize content, use responsive components, provide adequate targets, prevent obscured focus, and reserve space for images and messages. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Compare mobile task completion, input errors, field abandonment, layout shifts, and page experience distributions by template.

WCAG 2.2 and Android design guidance provide testable considerations for target size, focus, orientation, readability, and consistent interaction. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Can the task survive 200% zoom?
  • Is focus ever hidden?
  • Does the keyboard cover an action?
  • What shifts after load?

Device labs sample the market; production monitoring remains necessary for unusual browsers and assistive technologies. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Warning sign four: persuasion replaced decision support

The new page uses larger slogans and shorter copy but removes pricing context, process detail, evidence, limitations, or answers to objections. A visitor may admire the page while remaining unable to decide whether the offer fits their situation. The important distinction for product owners, marketing teams, designers, developers, and executives sponsoring a website or application redesign is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Review sales calls, proposals, support questions, search queries, and competitor claims to identify the uncertainty a qualified buyer must resolve. Structure content around problem recognition, fit, evidence, process, risk, next step, and honest boundaries rather than decorative word count. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Monitor interactions with proof and process content, qualified inquiry rate, inquiry quality, and recurring questions after launch.

Task observation should show that participants can explain the offer, identify fit, and choose the next step without facilitator help. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • What uncertainty blocks action?
  • Which proof is verifiable?
  • Who is not a fit?
  • Is the next step proportional?

Conversion change can reflect campaign mix or market conditions; use segmented comparisons and avoid crediting design alone. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Warning sign five: accessibility waits for final QA

Color, component behavior, headings, labels, keyboard order, error messages, and content alternatives are reviewed only after development is considered complete. Late discovery turns design decisions into rework and encourages teams to treat disabled users as edge cases. The important distinction for product owners, marketing teams, designers, developers, and executives sponsoring a website or application redesign is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Include accessibility acceptance criteria in components, content templates, design review, and usability sessions from the beginning. Test semantics, keyboard operation, visible focus, contrast, reflow, text alternatives, errors, authentication, and assistive-technology paths. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Track issues by component and severity, regression recurrence, task completion with assistive technology, and time to remediation.

WCAG 2.2 provides testable criteria, while conformance still requires a combination of automated and human evaluation. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Does the component expose name and role?
  • Can every action use a keyboard?
  • Is an error understandable?
  • Who tested with assistive technology?

Automated tools find only some barriers, and passing criteria does not guarantee a satisfying experience for every disability. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

Warning sign six: launch has no comparison plan

Teams approve a redesign from stakeholder review, then discover after release that analytics events changed and the old baseline cannot be reconstructed. Without comparable measurement, normal seasonality and campaign changes can be mistaken for a design effect. The important distinction for product owners, marketing teams, designers, developers, and executives sponsoring a website or application redesign is whether the team can connect that observation to a decision, an owner, and a measurable operating result. A polished dashboard is not proof of control; evidence appears when the process produces the same answer under normal pressure, when a handover occurs, and when an exception has to be resolved.

Field perspective. Freeze metric definitions, annotate changes, validate analytics in staging, preserve route mappings, and choose a staged or controlled release where feasible. Define primary outcomes, guardrails, segments, observation period, rollback triggers, and qualitative follow-up before deployment. This is where discovery should move from opinions to artifacts: sample records, screen recordings, error logs, approval histories, user interviews, or timed task observations. The team should record what was observed, what remains an assumption, and what would change the recommendation. That discipline prevents a persuasive anecdote from becoming an expensive architecture decision.

Decision test: Compare task success, qualified conversion, accessibility, performance, error, support demand, and customer quality—not only total sessions.

A versioned release record and matched metric definitions allow the team to learn whether the redesign solved the stated problem. The following review prompts make the issue concrete and keep the workshop focused on behavior rather than feature wish lists:

  • Which metric must improve?
  • Which guardrail cannot decline?
  • Are events comparable?
  • What triggers rollback?

Even controlled releases cannot remove every external influence, especially on low-traffic sites. A sensible rollout therefore starts with a reversible test, a named baseline, and a date for review. If the result does not improve the baseline, the team should be willing to stop, simplify, or choose a different intervention instead of defending sunk cost.

What to do next

Before approving visual direction, ask participants to complete the real tasks that fund the site. Observe the first click, questions, errors, confidence, and accessibility barriers. Preserve evidence that buyers need, even when it creates longer pages. Then launch with comparable metrics and a rollback threshold. The goal is not to defend the old design or resist creativity. It is to ensure the new experience earns its beauty by helping more people understand and complete what matters.