Website Redesign Planning That Solves the Right Problems

Website redesign planning should begin before anyone chooses a template, sketches a hero section, or rewrites a button. A redesign is a business decision about what the website must help people understand and do. Without evidence, a team can spend weeks changing colors while preserving the confusion that made the old site ineffective.

A useful plan combines identifying outdated website components with prioritizing improvements based on user feedback. It also requires planning content changes before development so designers are not arranging placeholders, then evaluating redesign results after launch against a recorded baseline. This sequence protects useful pages, limits avoidable rework, and makes the redesign accountable.

Open an evidence file before discussing the new look

The first output of website redesign planning should be a redesign evidence file. It is not a mood board. It records the current site's business goal, priority audiences, important URLs, conversion actions, recurring user questions, technical constraints, and baseline performance. Strikingly's guide to business website redesign likewise begins with a brief that connects audience, offer, pages, and actions.

Six fields for identifying outdated website components

1. Current component: Name the page, section, content block, or behavior being reviewed.
2. Evidence: Record analytics, user feedback, support questions, search value, or an observed usability problem.
3. Decision: Keep, update, combine, replace, move, or remove the component.
4. Expected effect: State what should become clearer, faster, safer, or easier to complete.
5. Owner: Assign the content, design, development, and approval responsibility.
6. Measure: Choose the prelaunch baseline and the post-launch signal that can test the decision.

Website redesign planning gives identifying outdated website components a decision trail. It also keeps prioritizing improvements based on user feedback from becoming a list of isolated customer requests. Every recommendation needs a reason, owner, and test. If the team cannot describe the expected effect, the change is not ready for the roadmap.

Identifying outdated website components in three layers

Strikingly Website Editor

Identifying outdated website components is broader than spotting old fonts. Review content, interface, and infrastructure separately. The content layer includes obsolete offers, inaccurate staff details, weak proof, repeated pages, and unsupported claims. The interface layer includes confusing menus, inconsistent buttons, cramped mobile sections, and forms that ask for unnecessary information. The infrastructure layer includes broken links, old integrations, slow assets, and tracking gaps.

Use a complete page inventory during website redesign planning. Identifying outdated website components with this inventory means recording each URL's purpose, audience, owner, traffic, conversions, inbound links, and next action. The Strikingly website content audit recommends judging pages by accuracy, relevance, uniqueness, and usability, preventing useful low-traffic pages from being removed merely because they are not popular.

For identifying outdated website components, examine real tasks on desktop and mobile. Try to understand the offer, compare options, find a policy, submit a form, and return to a previous page. Strikingly's guide to adding and managing sections shows that sections can be added, reordered, duplicated, or deleted, but the audit should decide why each action helps before the editor makes it easy.

Prioritizing improvements based on user feedback without taking votes

Strikingly Contact Form for Visitor Feedback

Prioritizing improvements based on user feedback does not mean implementing every suggestion. People describe symptoms from their own context. One person asks for a larger menu because a label was unclear; another asks for details because the service page missed a key condition. Website redesign planning must identify the underlying job before choosing the solution.

Collect feedback from support conversations, sales calls, form responses, reviews, usability sessions, and on-page questions. A focused Strikingly Custom Form can ask what a visitor came to do, whether they completed it, and what blocked them. Prioritizing improvements based on user feedback becomes stronger when comments are paired with behavior rather than treated as votes.

When prioritizing improvements based on user feedback, group evidence by task and severity. A frequent cosmetic preference may be less urgent than an occasional checkout failure. Score each issue by user impact, business impact, confidence, effort, and risk to useful content. This makes prioritizing improvements based on user feedback transparent without pretending a formula can replace judgment.

Prioritizing improvements based on user feedback also means looking for disagreement. If experienced customers want speed while new visitors want explanation, use clearer routes instead of a compromise page that satisfies neither group. Website redesign planning should preserve meaningful audience differences instead of averaging every opinion into one layout.

Planning content changes before development settles the model

CraftBox Template from Strikingly

Planning content changes before development begins with page roles. Define what each page must communicate, what evidence belongs there, and which action should follow. Decide which URLs stay, which pages merge, and which material needs a redirect. The Strikingly article on refreshing website content recommends tracing the value a page already carries before changing its intent, copy, design, and navigation together.

Use real draft copy to test hierarchy. Planning content changes before development reveals whether a proposed two-column section can hold the service explanation, whether a testimonial supports the nearby claim, and whether button text accurately describes the next step. Placeholder text hides these constraints until rework is expensive.

Identifying outdated website components should lead to an explicit content action: keep, revise, merge, redirect, archive, or create. Preserve page titles, metadata, useful internal links, and established URLs unless evidence supports a change. Strikingly's SEO guidance emphasizes descriptive titles, page descriptions, headings, quality content, image descriptions, and analytics. Planning content changes before development must account for each one.

Planning content changes before development also clarifies production. When planning content changes before development, list missing photographs, case results, policy approvals, product details, and translations. Assign owners and deadlines before the build depends on them. Website redesign planning is more reliable when “content ready” means approved, structured material, not a blank project-board field.

Create a release packet with ownership and safeguards

Strikingly Team Feature

A release packet turns decisions into buildable work. Planning content changes before development should produce approved copy, section order, image references, interaction notes, mobile behavior, metadata, redirects, accessibility requirements, analytics events, and acceptance criteria for each priority page. The packet gives the team stable inputs while still allowing better presentation.

Planning content changes before development also defines who needs editing access. Strikingly's guide to site teammates and collaborators explains roles for administrators, editors, bloggers, store managers, and agents, including separate publishing rights. Website redesign planning should identify who can edit, approve, and publish so an unfinished change cannot reach the live site accidentally.

Protect the current site before major work. The Strikingly cloning guide explains how to create an unpublished copy, while the guidance for editing after publishing distinguishes saved preview changes from the live version. Record forms, store data, domains, and integrations that need separate handling because a clone is not automatically a complete operational backup.

Before release, website redesign planning returns to the important audit tasks. Confirm navigation, forms, purchases, downloads, search, policy links, analytics, redirects, and mobile actions. Identifying outdated website components was the diagnostic pass; this acceptance pass proves that the chosen replacements work.

Evaluating redesign results after launch with matched behavior

DesignCraft Template from Strikingly

Evaluating redesign results after launch starts before launch. Record baseline values for changed pages and tasks, including qualified inquiries, purchases, form completion, page progression, mobile exits, support questions, and search entrances. Evaluating redesign results after launch requires protected metrics, not only numbers that make the work look successful.

Use Strikingly built-in analytics for traffic sources and top pages, then connect Google Analytics 4 when more detailed event and path reporting is needed. Evaluating redesign results after launch should compare the same event definitions, device groups, acquisition sources, and time windows whenever possible.

Do not judge too early or wait indefinitely. When evaluating redesign results after launch, check immediately for broken flows, after one or two weeks for direction, and after a full business cycle for outcomes. Evaluating redesign results after launch also requires qualitative evidence: can visitors understand the offer, find information, and complete tasks with less help?

The 30-day redesign decision

• Keep: The change improved the intended task without damaging another important route.
• Adjust: The direction is useful, but evidence reveals a message, placement, or interaction problem.
• Investigate: The result is inconclusive because traffic, tracking, or the comparison window is insufficient.
• Reverse: The change harmed a protected outcome or created a serious usability failure.

When evaluating redesign results after launch, document unexpected effects instead of hiding them inside an average. A cleaner service page may increase inquiries but lower lead fit. A shorter homepage may improve mobile progression while reducing access to a valuable resource. Prioritizing improvements based on user feedback continues after release because new behavior shows what the redesigned experience still misses.

Keep the decision record alive

Website redesign planning succeeds when the team can explain why each major change exists. Identifying outdated website components supplies the diagnosis. Prioritizing improvements based on user feedback separates urgent task failures from preferences. Planning content changes before development gives design and development real material to solve.

Evaluating redesign results after launch closes the record and opens the next improvement cycle. At 90 days, evaluating redesign results after launch should confirm whether early gains survived a full business cycle. Preserve what works and correct what did not. Website redesign planning then becomes disciplined improvement rather than a periodic attempt to make the site look new.