Live production site · 2025 - 2026
Case study
Chronic Pain Recovery
A production healthcare website that organises pain science, treatment information and consultation routes for patients.
- Information architecture
- Accessible frontend
- SEO and structured data
- Production delivery
Context
Chronic Pain Recovery explains persistent pain, treatment options and how to book a consultation.
The source material is detailed and medically sensitive. The site had to make it easier to scan without simplifying the clinical claims.
Ownership
Design, frontend engineering, and deployment
Next.js · TypeScript
- Structured the information architecture and interface hierarchy.
- Built the responsive Next.js frontend and semantic content system.
- Prepared metadata, structured data, and the production deployment.
Ownership boundaries
This case study covers my design, frontend, search and deployment work. The medical guidance and treatment claims are not mine.
All evidence comes from the client-approved public site. It contains no consultation or patient data.
Constraints
- Headings and consultation links had to stay measured. Urgency would be inappropriate for this subject.
- Long condition names and unfamiliar terms had to remain readable on phones as well as large screens.
- Metadata and structured data had to support search without turning the visible copy into search-first prose.
Decisions
Start with the questions patients ask.
- Approach
- I grouped the content into pain causes, recognisable conditions, treatment paths, practitioner context and consultation routes.
- Trade-off
- This structure creates more pages and editorial upkeep than one brochure page. It also gives conditions, treatments and consultations a clear home.
- Why
- A reader can begin with a symptom or question instead of learning the site’s categories first.
Keep the interface calm.
- Approach
- I used direct headings, short supporting text and consistent consultation links, with no urgency cues or decorative motion.
- Trade-off
- Large type and generous spacing reduce how much fits on screen. That is preferable to crowding sensitive health information.
- Why
- People can scan the service without the interface adding pressure.
Build semantics into the pages.
- Approach
- I defined heading order, image descriptions, page metadata, FAQ schema, responsive images and reusable sections as part of each page.
- Trade-off
- Headings, image descriptions, metadata and FAQ schema take time before launch. Adding them later would duplicate the work.
- Why
- One content structure serves readers, assistive technology and search engines.
Proof
The live site includes pages for conditions, treatments, practitioner information, pain science, self-assessment, journal posts and consultations. Its HTML contains ordered headings, image descriptions, page metadata and FAQ schema. The screenshots below come from the public site.
The page moves from the homepage through patient questions and service information, then stops on the chronic-pain science section. No private client or user information is shown.
Text description
Silent visual walkthrough. It begins on the Chronic Pain Recovery homepage, scrolls through public condition and service sections, and finishes on the section titled ‘What causes chronic pain?’. No speech or audio is present.
Outcomes
- Launched the public site with routes from health information to consultation booking.
- Built reusable sections for treatments, locations, resources, journal posts and contact pages.
- Included ordered headings, image descriptions, search metadata and FAQ schema in the production pages.
Reflection
Direct section titles and predictable consultation links did more work here than decorative features would have.
New search or content work should still be reviewed against the accuracy and tone of the medical material.