TL;DR
Choose the next purchase from observed task failures. A dated design may still support examination requests, while inaccurate public information can leave visitors unsure which exam service is available. Compare evidence for navigation, request handling and local information before buying a rebuild. Scope a smaller repair when it can resolve the verified problem, then reconsider the remaining need.
Separate appearance from an interrupted task
A redesign proposal can combine visual refresh, technical repairs, content changes and local visibility work under the same heading. Ask which observed problem each part addresses. A site looking old is a preference observation; a visitor being unable to find the examination request is a task failure with a reproducible path.
Define the business objective precisely. Examination inquiries, frame shopping and existing eyewear service do not use identical journeys. Test the examination path you actually want to improve while preserving the optical paths people already use. Do not count order-status calls as new-patient demand because they entered through the same contact page.
This comparison is an original procurement method. GetPatients has a commercial interest in healthcare visibility services. Apply the evidence standard to its recommendations and to any competing proposal. No design style, agency or package is presumed to be the right answer.
Collect task evidence before the sales meeting
Ask an authorized reviewer unfamiliar with the proposed changes to start at the public information a visitor might encounter. Record the entry surface, task, device, observed barrier and destination. Use public pages and synthetic details; coordinate with scheduling so a rehearsal cannot create unwanted appointments or real outreach.
For the exam journey, can the reviewer identify the office, understand the actual appointment action and reach the correct receiving route? For optical service, can they find the approved contact instructions without accidentally submitting an exam request? Keep observations specific enough that an implementer can reproduce them.
When a task works, record that too. A proposal should explain why replacing a functioning journey is necessary and how the replacement will preserve it. A screenshot of a competitor's site does not establish a defect in yours.
Compare failures with the purchase they justify
| Observed evidence | Candidate work | Acceptance condition | Why a larger purchase may remain unresolved |
|---|---|---|---|
| Wrong office or missing exam information on a controlled profile | Correct verified local business information | Public information and destination agree with operations | Does not establish a website architecture problem |
| Exam button reaches an optical question form | Routing and label repair | Correct examination request reaches scheduling | Does not establish a need to replace the visual system |
| Mobile menu or scheduler interaction repeatedly fails | Technical investigation and repair | Same task works after a documented change | Cause and repair scope still need evidence |
| Shared templates prevent necessary service and clinician distinctions | Template or architecture project | Approved exam, specialty and optical journeys can be represented accurately | May justify broader work if smaller repair is not feasible |
| Site works but owner wants a visual refresh | Separately scoped design work | Agreed presentation criteria and preserved working tasks | Acquisition benefit remains an unverified hypothesis |
Keep uncertainty visible. A failed interaction is a reason to investigate its cause; it does not identify the cause automatically. A correct profile edit is a completed task, not proof of a ranking or booking gain.
Assess local discovery within its actual limits
Google advises keeping Business Profile information complete and accurate. It also says businesses cannot request or pay for a better local ranking. Google's local ranking guidance. A vendor can sell work on information it is authorized to manage; it should distinguish that work from an outcome controlled by the platform.
Check whether public details accurately explain the clinical-and-optical operation, locations and contact paths. Do not assume that retail opening hours demonstrate examination availability. Where a clinical operator and optical operator differ, have the appropriate owners confirm the representation rather than using a generic business category as the whole explanation.
Use the website performance triage when evidence points to loading or interaction problems. Use the service pilot guide to bound a content and discovery task. Neither substitutes for the actual task evidence in this purchase comparison.
Request priced alternatives around the same defect
Ask for the smallest complete repair and the broader proposed project, each with deliverables, implementation owner, dependencies and acceptance evidence. Include migration, staff review, analytics continuity and maintenance costs where applicable. Use written quotes rather than a guessed industry budget.
Have the provider identify which working examination and optical paths the project could affect. Require a preservation and test plan for those tasks. A redesign needs evidence of its own acceptance, rather than credit for unrelated changes in appointment totals.
End with a decision note: verified barrier ___; chosen repair ___; actual quoted commitment ___; preserved tasks ___; unresolved broader need ___; next evidence ___. If the evidence does not establish a task failure, buy a visual refresh only as that stated objective rather than describing its acquisition effect as proven.
Frequently asked questions
Can local information work start before a redesign?
Yes, when verified facts, authorized access and a correct destination are available. Record dependencies that prevent a particular correction rather than treating every task as blocked by the whole rebuild.
When is a larger redesign justified?
When the observed needs and platform constraints support that scope, or when the owner deliberately buys design for an agreed presentation objective. Require acceptance criteria and preservation of useful paths.
Does a successful booking prove the website needs no work?
It proves that tested path worked in those conditions. Continue inspecting relevant tasks and observed defects; do not generalize from a convenient success or failure.