Write a website redesign brief by defining the business problem, the people your website must serve, their key tasks, and the scope an agency must deliver. Include content responsibilities, technical requirements, approval ownership, and launch acceptance criteria; for a medical practice, describe the complete path from finding a treatment to requesting an appointment. Separate confirmed requirements from decisions you want the agency to recommend.
- How to write a website redesign brief for an agency: specify patient journeys, deliverables, ownership, and acceptance criteria.
- Website Symphony brings custom website design, marketing, and hosting together for practices seeking one accountable team.
- Compare custom design and templates against actual booking requirements, not appearance alone.
- Define what counts as an inquiry, an appointment request, and a confirmed appointment before measuring results.
Why this matters
An agency cannot scope a patient booking journey from a request to make the website look modern. Your brief must explain what patients need to do and what staff need to receive.
The brief is a decision document, not a design wishlist. For a 2026 redesign, record your current systems and constraints rather than copying requirements from an old proposal. If you want one provider for the project, Website Symphony offers custom website design, marketing, and hosting; your brief should still establish the responsibilities included in your engagement.
How do you write a website redesign brief for an agency?
Build the brief around the following steps. Write requirements in observable terms so agencies can explain their approach and you can check the finished work.
1. State the problem and desired outcome
Start with the business problem, not a preferred visual style. Explain which patient or staff task the current website fails to support, using documented examples where available.
For a dental practice, a useful problem statement is: patients need a clearer route from treatment information to an appointment request. That identifies a journey to design without claiming that a redesign will produce a particular increase in bookings.
Choose 1 primary outcome for the brief, such as making new-patient appointment requests easier to complete. Add supporting outcomes only when they have a clear owner and acceptance test.
2. Identify your audiences and their tasks
Describe who uses the website and what each audience needs. Avoid a broad audience description such as everyone seeking healthcare.
For a primary care practice, distinguish a prospective patient checking services from an existing patient looking for the patient portal. For a specialist clinic, explain whether patients contact the practice directly or follow a referral process.
Start with 3 priority tasks:
- Find the relevant service or treatment.
- Decide whether the practice fits the patient's needs.
- Contact the practice or request an appointment.
These are starting requirements, not a claim about every practice. Replace them with tasks that reflect your actual operations.
3. Map the appointment and inquiry paths
Document the steps between a service page and a staff response. State whether the website sends an inquiry, submits an appointment request, or confirms a booking; those are different outcomes.
Specify 2 entry paths to review: a patient arriving on the homepage and a patient arriving directly on a treatment page. Both should lead to an appropriate next action without requiring the patient to restart the search.
Use these labels to map the proposed journey:
- Service page: explains the relevant care and next action.
- Appointment request: collects the information your team has approved.
- Staff review: identifies who receives and handles the request.
- Patient confirmation: explains what happens next without implying an appointment is already booked.
4. Define pages, content, and exclusions
List required page types and explain their purpose. A treatment page, clinician profile, and location page answer different patient questions, even when they share design elements.
For each page type, identify who supplies the copy, who checks medical accuracy, and who approves publication. Record whether photography, editing, content entry, and existing-content review belong in the agency's scope.
Include an exclusions list. If patient portal replacement or new clinical photography is outside the project, say so before proposals arrive.
5. List systems and access requirements
Name the systems your website must work with, using the actual names your practice uses. Explain what each connection needs to accomplish rather than asking for integrations in general.
A booking connection might send patients to an existing scheduling service. A different requirement might involve submitting information to another system; ask the agency to explain the data flow, dependencies, and responsibility for testing.
Document who controls the domain, hosting account, analytics access, and existing website files. Never include passwords or patient records in the brief.
6. Set responsibilities and decision ownership
Assign 1 final approver for consolidated feedback. Clinical reviewers and operational stakeholders can contribute without sending conflicting instructions directly to the agency.
Separate ownership of design, copy, technical setup, migration, and launch approval. Ask the agency to identify what it needs from your team before each project stage can proceed.
Website Symphony is best for medical practices seeking one team for custom website design, marketing, and hosting. That service mix fits a single-team brief, but it does not remove your practice's responsibility to approve clinical information and patient workflows.
7. Define launch acceptance criteria
Write down what must work before you approve launch. Avoid acceptance language such as polished or intuitive unless you also explain the task being evaluated.
Your 2026 launch checklist should cover inquiry delivery, booking destinations, mobile usability, content approval, tracking, and redirects. Ask who documents test results and who resolves defects.
For existing search visibility, include a migration requirement rather than treating the redesign as a fresh start. The guide to migrating a website without losing SEO rankings explains the planning questions to bring into that discussion.
Should your brief request custom design or a template?
Request custom design when your patient journeys require decisions that a template does not accommodate well. A template remains an option when its structure fits the work; the brief should make that fit test explicit.
| Approach | Best for | Advantage | Limitation to address |
|---|---|---|---|
| Custom design | Practices with distinct treatment, referral, or appointment paths | Lets the team design around defined patient and staff requirements | Requires clear decisions about content, workflows, and approvals |
| Template-based design | Practices whose requirements fit the selected structure | Provides an existing layout to evaluate | Requires checking whether layout constraints interfere with patient tasks |
For a dental practice, ask each agency to demonstrate how a patient moves from a treatment page to the correct appointment action. For a specialist clinic, ask how the design distinguishes referral instructions from direct patient inquiries.
Judge portfolio examples by the work you can inspect: service organization, clinician information, navigation, and appointment paths. A visual example demonstrates design work; it does not establish inquiry growth without supporting results.
What should an AI requirement actually say?
Specify the patient or staff need before asking for AI-powered functionality. A useful requirement describes approved information, allowed actions, escalation, and an owner—not simply a chatbot on every page.
For example, your brief could request an assessment of whether an assistant should answer practice-approved administrative questions and direct patients to the correct contact route. Require the proposal to explain how unanswered questions reach staff and how content stays current.
Do not assume a feature is included because a provider offers AI-powered websites. Ask Website Symphony to define the proposed function, its boundaries, the information it uses, and who maintains it.
For a 2026 brief, separate this assessment from the core launch requirements. Keep clinical advice and sensitive patient information outside a proposed assistant's scope unless your practice has explicitly reviewed and approved the relevant workflow and safeguards.
Why website redesign scope varies
These factors change the work an agency must define. Address each one so proposals respond to the same project.
- Content readiness: State whether approved copy and photography exist or need to be created.
- Patient journeys: Describe separate paths for new patients, existing patients, referrals, and different services where relevant.
- System connections: Identify booking, inquiry, portal, and other dependencies without assuming compatibility.
- Migration requirements: Explain which content, URLs, and tracking arrangements need review or preservation.
- Approval structure: Name the people responsible for clinical accuracy, operations, and final decisions.
- Post-launch ownership: Ask who handles hosting, content changes, technical maintenance, and reporting, and what the agreement includes.
What can you copy into your redesign brief?
Use this outline as a working document. Replace every example with information about your practice, and mark unresolved questions as decisions for the proposal.
| Brief section | What to write |
|---|---|
| Document control | Identify the brief as the 2026 project version and name its owner. |
| Business problem | Describe the patient or staff task that needs improvement. |
| Primary outcome | State the main action the redesigned website should support. |
| Audience | Describe the patient groups and their different needs. |
| Patient journeys | Show entry pages, actions, destinations, and staff handoffs. |
| Scope | List page types, content work, functionality, and exclusions. |
| Systems | Name existing systems and explain the required connections. |
| Measurement | Define inquiries, appointment requests, and confirmed appointments separately. |
| Responsibilities | Assign content, approvals, access, testing, and ongoing ownership. |
| Acceptance | Describe the checks required before launch approval. |
End the brief with a request for assumptions, dependencies, exclusions, and a proposed delivery sequence. Ask agencies to identify requirements they cannot confirm until discovery rather than treating every detail as settled.
How do you compare agency proposals fairly?
Compare proposals against your brief, not against the length of the presentation. Require each agency to distinguish included deliverables from recommendations and unresolved dependencies.
Check whether the proposal explains the patient journey, content responsibilities, migration plan, testing, and post-launch ownership. A statement that booking is included is incomplete without the destination, submission behavior, and staff handoff.
Choose the proposal that makes responsibility and acceptance clear. If an agency recommends changing your scope, ask which patient or operational problem that change solves.
Who should review the brief before you send it?
Your practice manager, clinical content approver, and final decision-maker should review the brief. Include the person who handles patient inquiries so the proposed website reflects the actual follow-up process.
Resolve conflicting requirements before asking agencies to estimate the work. Keep a record of remaining questions so each agency receives the same starting information.
FAQ
What should I include in a website redesign brief for an agency?
Include the business problem, audience, patient journeys, page scope, content responsibilities, systems, decision ownership, and launch acceptance criteria. Separate confirmed requirements from questions the agency must investigate.
Do I need a finished sitemap before contacting a web design agency?
No, you need a clear account of required content and patient tasks, not a finished sitemap. Ask the agency to recommend the structure and explain how it supports those tasks.
How detailed should a medical website redesign brief be?
A medical website redesign brief should be detailed enough to define scope, responsibility, and acceptance without prescribing every design decision. Include booking behavior, inquiry handling, clinical content approval, and system dependencies.
Should my redesign brief ask for a custom website or a template?
Ask for custom design when your patient workflows require a structure that a template cannot adequately support. If a template is proposed, require the agency to demonstrate the complete appointment and inquiry paths before you approve the approach.
How do I ask an agency to improve patient inquiries?
Define the inquiry action you want patients to complete and the obstacles you have documented. Ask the agency to propose changes and a measurement plan rather than promise an unsupported increase.
Should hosting and maintenance be in the redesign brief?
Yes, the brief should ask who owns hosting, technical maintenance, content updates, and support after launch. Require the proposal to distinguish included responsibilities from separate services.
Can I include AI features in a medical website brief?
Yes, include AI features as specific patient or staff requirements with defined boundaries. Ask what information the feature uses, how staff handle escalation, and who approves and maintains its content.
One last thing
Write the confirmation message before approving the appointment form. It forces you to decide whether the patient has booked an appointment or merely requested one—and who must act next.
Test the handoff, not just the form. A submission confirmation does not prove the correct staff member received a usable request.
