Content to Prepare Before a Website Redesign
Before a redesign, gather the content that defines what the site must do: audience tasks, real service boundaries, approved product screenshots, contact routes, and dated case evidence. This guide explains what to collect and how to test it.
Map audience tasks
Start by listing the specific tasks your audience needs to complete. For a service business, these might include checking availability, comparing packages, or requesting a quote. For a product company, tasks could be signing up for a trial, finding documentation, or contacting support. Write each task as a simple verb phrase and note the current page or flow that supports it.
Suppose a regional consultancy wants to redesign its site. They list tasks such as 'book a consultation', 'download a service overview', and 'find office locations'. During discovery, they realize the current site has no clear path to book a consultation; visitors must fill out a generic contact form. This gap becomes a priority for the new structure.
To test whether your task list is complete, ask three people who match your audience profile to name the top three things they would want to do on your site. Compare their answers with your list. If they mention a task you missed, add it. If they struggle to name any, your list may be too abstract or not aligned with real needs.
Define real service boundaries
Clearly state what your service includes and excludes. This prevents mismatched expectations and reduces time spent on unqualified inquiries. For each service, write a one-sentence description, then list what is not included. For example, a web development service might include custom coding but exclude content writing or ongoing SEO campaigns.
Suppose a small agency offers website maintenance. They decide to specify that maintenance covers security updates and backups but not content edits or new feature development. This boundary helps them scope requests and communicate limits upfront.
A practical test: review your service descriptions with a colleague who handles sales or client onboarding. Ask them to identify any recent inquiry that fell outside your stated boundaries. If they can point to several, your boundaries may be too vague or not visible enough on the site.
Collect approved product screenshots
If your site showcases a product or platform, gather screenshots that are current, accurate, and approved for public use. Avoid using outdated interfaces or mockups that do not reflect the actual product. For each screenshot, note the feature it demonstrates and any sensitive data that must be blurred or removed.
Suppose a software company is redesigning its site. They collect screenshots of their dashboard, reporting module, and mobile view. Before publishing, they check with the product team to confirm that no customer data is visible and that the interface matches the latest release.
To verify that your screenshots are ready, open each one and ask: does this show the product as it exists today? Is any confidential information visible? If you answer no to the first or yes to the second, replace or edit the image before handing it to the design team.
Establish contact routes
List every way you want people to contact you: email, phone, contact form, live chat, or social media. For each route, decide where inquiries should go and who is responsible for responding. This prevents messages from being lost during the transition to a new site.
Suppose a nonprofit wants to add a volunteer sign-up form and a general inquiry form. They assign the volunteer form to the volunteer coordinator and the general form to the office manager. They also set up an auto-response to acknowledge receipt and set expectations for a reply.
A simple test: submit a test inquiry through each contact route on your current site. Note how long it takes to receive a response and whether the response addresses your question. If any route fails or takes too long, fix it before the redesign goes live.
Gather dated case evidence
Collect case studies or examples of your work that include dates, client names (with permission), and specific outcomes. Avoid vague claims like 'improved performance' without context. Instead, describe the situation, the action taken, and the result, with a date to show recency.
Suppose a design studio is preparing for a redesign. They gather three case studies from the past two years. Each includes the client's industry, the challenge, the solution, and a measurable result such as 'reduced page load time by half' or 'increased form submissions by a third'. They also note the date of completion.
To check if your case evidence is strong enough, ask a colleague to read one case study and summarize what was done and what changed. If they cannot state the outcome clearly, the case may need more specific details or a clearer structure.
Continue reading
A practical next step
Explore the related Devign work, then discuss your requirements before committing to a project scope.