Healthcare website redesign: what to include in the project brief

A healthcare website redesign brief should explain who the site serves, what those visitors need to do, what the organization needs to improve, and who will own the work after launch. Include the existing content, integrations, migration requirements and approval process before asking a team to recommend a platform or estimate the build.

The brief does not need to specify every page or solve the design in advance. Its job is to expose the decisions that affect scope. A practice adding a location has a different problem from a healthtech company explaining a complex product, even when both describe the project as a website redesign.

At Health Site Works, we recommend starting with the current website and the decisions visitors struggle to make. The visual direction becomes more useful once the team knows what the site must communicate. The following brief structure is our suggested working method, not a claim that every healthcare organization needs the same website.

Start with the decision you want the website to support

Write a short description of why the project exists now. Perhaps prospective customers cannot understand the offer, the marketing team cannot update important pages, or patients keep arriving at an outdated location page. Identify the problem in terms the delivery team can investigate.

Then describe the primary visitor and the next useful action. A healthcare company may need a procurement team to understand its product and request a conversation. A care provider may need someone to find the right service, check the correct location and reach the established appointment system. These journeys can coexist, but the brief should say which matters on each part of the site.

• Understand the offer: explain the service or product in language the intended audience can use.
• Evaluate the organization: make relevant experience, people and evidence easy to find.
• Find the right destination: connect the visitor to the appropriate service, location or team.
• Take the next step: make the intended inquiry or referral path clear.

Use evidence where you have it. Include recurring questions from sales calls, front-desk feedback, confusing search queries or pages that visitors frequently leave. If you have no reliable analytics, say so. A clearly described observation is a better starting point than a conversion-rate target with no established baseline.

Explain the organization without sending a document warehouse

Give the website team a concise account of the organization, its audiences and how the offer is delivered. Include the services or products that belong on the site, the locations that matter, and the distinctions buyers need to understand. Link to supporting material rather than pasting every internal document into the brief.

For a healthcare company, useful context may include how the product is purchased, who evaluates it, which audiences need different explanations and what evidence can be used publicly. For a practice or provider group, explain how service availability varies between locations, who maintains provider information and where appointment requests currently go.

Separate material the team can publish from material supplied only for context. Mark the approved logo files, photography and case-study permissions. If a design example is a concept rather than a live client result, retain that distinction in the brief. Nobody should have to infer permission from the fact that a file was included in a folder.

Inventory the pages and content you already own

Start with a list of existing URLs. Identify important service pages, location pages, product information, resources and downloadable files. For each item, record whether it should be retained, rewritten, consolidated or retired. A simple spreadsheet is enough for the first pass.

Add an owner and a reason to each decision. A page receiving little search traffic may still answer a question used in sales conversations. An older resource may contain a diagram worth preserving even if its surrounding copy is outdated. Traffic is useful evidence, but it should not be the only reason content survives or disappears.

Make the writing responsibility explicit. State which pages already have approved copy, which require editing and which need new material. Distinguish writing from clinical, product or legal review where those reviews apply. If several people must approve a page, name the person who combines their feedback into one instruction.

Include media in the inventory. Product illustrations, location photography, team portraits, PDFs and embedded videos can create substantial work during a rebuild. Record where their originals live and who can confirm that they are current. Avoid assuming that everything visible on the existing site has a usable original or can be reused.

Define the content model before choosing the platform

The brief should describe what the team needs to publish and maintain. List recurring content types such as locations, services, clinicians, products, insights or selected work. Describe the relationships between them. A service available at several locations is a different editing problem from an independent landing page for each office.

Ask a prospective delivery team to show how an editor would perform a normal update. Could that person change a location’s opening information, add an insight or update a product page without rebuilding a layout? Which changes require a designer or developer? Use actual editing tasks from your organization in that discussion.

Webflow’s CMS Collections documentation describes structured collections, fields and items. WordPress documents distinct roles and capabilities, including differences between editing and publishing. These are useful prompts for evaluating a workflow; they do not settle the platform choice on their own.

Our healthcare website platform guide explains how to frame that decision across WordPress, Webflow and Framer. In the brief, describe the requirements first and identify any platform constraint separately. If a platform has already been selected, record why and what the team still needs to verify.

List integrations and the boundary of each one

A line that says “connect the CRM” is rarely enough for a useful estimate. Explain what event starts the connection, what information moves, which system receives it and who handles a failure. For an inquiry form, that might mean a successful submission creates a record in the existing CRM and alerts a designated person.

Distinguish a link to another system from an embedded interface and from a custom integration. Linking to an existing appointment portal can have a different scope from recreating its experience inside the website. A website proposal should make that distinction visible before anyone prices the implementation.

List the information each form actually needs. Marketing inquiries, patient appointment requests and clinical workflows can have different requirements. Ask the organization’s responsible team to define the data-handling boundary and review the chosen services. A public marketing form should not accidentally become the destination for information nobody planned to collect.

Also document analytics, consent choices and campaign attribution. Specify which events matter, such as a successfully saved inquiry, rather than counting a button click as the same outcome. Identify who can access reporting and who will investigate discrepancies. These decisions belong in the project scope before launch.

Make migration and launch responsibilities visible

If URLs will change, include a mapping from old addresses to their intended destinations. Google’s site-move guidance covers preparing that mapping, configuring redirects and monitoring old and new URLs. It also explains that rankings can fluctuate while Google recrawls and reindexes changed pages. A redesign proposal should therefore avoid promising an interruption-free search outcome.

Record who controls the domain, DNS, hosting and existing CMS. Confirm who can grant the access the delivery team needs. Account access often involves a different person from the project sponsor; discovering that distinction just before launch creates unnecessary uncertainty.

Define the release checks in observable terms. Important pages should load at their intended addresses, internal links should reach the right pages, forms should deliver to the agreed destination and content should remain readable on smaller screens. Include an accessibility review appropriate to the agreed scope, with findings and remediation responsibilities documented.

• Content approved: the designated owners have signed off the release copy and assets.
• Journeys tested: the agreed visitor tasks work across the selected devices and interfaces.
• Connections verified: forms, destinations and reporting have been checked end to end.
• Launch monitored: an owner is assigned to review the public site and investigate problems.

Include a practical rollback plan and a contact for the release window. The brief does not need a detailed technical runbook, but it should say who will write one and who can decide to use it. Agree how issues discovered after release will be recorded and prioritized.

Separate delivery responsibilities from ongoing ownership

A website needs owners after the project team finishes the build. Identify who updates content, who reviews changes, who manages access and who handles technical maintenance. Those responsibilities may sit with the internal team, a delivery partner or a combination of both.

Use concrete deliverables when discussing handoff. Ask for the agreed account access, source files, a short editing guide and a walkthrough of routine tasks. For ongoing support, describe the work expected and how requests enter the queue. “Support included” leaves too much open unless both sides know what it covers.

Area	Decision to record
Content	Who writes, reviews and maintains each content type?
Accounts	Who owns access and approves changes to permissions?
Integrations	Who investigates missing or failed submissions?
Maintenance	Who handles the agreed technical upkeep?

Give the proposal a realistic decision framework

State the timing constraints and explain which dates are genuinely fixed. A launch tied to an acquisition announcement has a different constraint from an internal preference to finish before a quarter ends. If content or stakeholder availability is uncertain, record that dependency rather than treating the delivery date as unconditional.

Explain how you will compare proposals. Ask each team to separate confirmed scope, assumptions, optional work and ongoing costs. A lower headline estimate is difficult to assess if migration, content entry or integration testing appears only as an unstated assumption.

You can share a budget range without dictating the exact solution. Ask the team what it recommends within that range and which tradeoffs would change the cost. Health Site Works scopes projects case by case; our proposal and pricing approach explains the factors we consider. A useful brief makes that conversation specific.

Frequently asked questions

Do we need to choose WordPress, Webflow or Framer before writing the brief?

No. Describe the content, editing and integration requirements first. A platform recommendation can be part of the discovery work. If procurement or an existing system requires a platform, make that constraint explicit.

Should the brief include a final sitemap?

Include the existing sitemap and a proposed list of important pages if you have one. Label proposed decisions clearly. The final structure may change when the team reviews audience needs and existing content.

What if our analytics are incomplete?

Describe the gap and provide the evidence you do have, such as inquiry records or recurring visitor questions. Include measurement setup and verification in the project scope before using new numbers to judge the redesign.

How detailed should the design references be?

A few references with specific explanations are usually more useful than a large inspiration folder. Say whether you like the navigation, typography, use of photography or explanation of a complex offer. References should inform an original design for your audience.

If you are preparing a healthcare website project, send us the brief you have so far. We can use it to discuss the audience, platform, scope and delivery responsibilities that need to be resolved.