I have built nine practice and hospital websites, and I manage the Google Business Profiles behind several of them. The pattern is consistent enough to write down: the sites that generate enquiries are rarely the best-looking ones. They are the ones that answer questions quickly on a phone.
- 01
Load fast on a phone
Largest element on screen inside 2.5 seconds over 4G.
- 02
Answer booking questions
Insurance, first-visit cost, wait time, parking.
- 03
Rank in the map pack
Matching NAP, real photos, reviews you asked for.
- 04
Work with assistive tech
WCAG 2.1 AA as the baseline, not an afterthought.
Job one: be fast on a phone, on cellular
Patients search for you in a waiting room, in a car, on a bad connection. A site built around a full-screen video of a smiling receptionist loses them before it renders.
Practical target: the largest element on screen inside 2.5 seconds on a mid-range Android over 4G. See Core Web Vitals for how to measure that honestly.
Job two: answer what patients ask before booking
Not your philosophy of care. The specific, slightly awkward questions:
- Do you take my insurance?
- What does a first visit cost if I am paying myself?
- How long until you can see me?
- Where do I park?
- What actually happens at the first appointment?
Every one of those is a reason somebody closes the tab and calls a competitor. Answering them in plain language is also what gets a page quoted by an AI assistant, so the same specificity serves both audiences.
Job three: show up in the map pack
For most practices the Google Business Profile drives more enquiries than the website does. It needs the same name, address, and phone number as your site, correct hours, real photographs, and reviews you have actually asked for.
The numbers when this is run properly are not subtle. A surgeon's profile I have managed since 2022 sits at 56,026 views and 176 reviews at 4.7 stars. An ENT specialist's profile created from nothing in 2026 reached 40,651 views and now owns its own search term — 1,580 monthly searches for "ent specialist dhaka" land on it. Both figures are read off the owner view, screenshots included.
The website supports it: matching details, LocalBusiness structured data, and a page per location if you have more than one.
Job four: work with assistive technology
This is the job practices have not budgeted for, and it is a legal exposure rather than a nicety. Web accessibility lawsuits run into the thousands each year in the US, and most defendants are small businesses rather than large ones.
The baseline is WCAG 2.1 AA: real text instead of words baked into images, color contrast that passes, every function reachable by keyboard, labelled form fields, captions on video.
Compliance dates are a legal question, not a design one. Confirm the current rule and your own classification with counsel rather than with a designer, including anything you read here.
What I will not do, and why you should ask
I do not claim HIPAA compliance, and I would be careful with anyone who does. A website that collects no patient information has little HIPAA surface. The moment you add an intake form, a portal, or automation touching patient records, you need a vendor who will sign a business associate agreement.
I do not sign BAAs, and the automation tooling I use does not offer them either. So the practical arrangement is this: I build the public site and the local search work, and anything touching patient data stays with a vendor set up for it. A smaller scope, honestly described.
Where the design budget belongs
Photography of the actual practice and the actual people, typography you can read at arm's length, and a booking path that takes two taps. In that order. Stock images of anonymous doctors do measurable harm, because patients are choosing a person.
See healthcare websites for what a build covers, or Google Business Profile ranking for doctors for the map-pack work on its own.
