At Brightly, we decided to start advertising our geriatricians for specialist consultations outside our core programmes. Simple enough, until I actually tried to build the page.
There was no "product" to point at. No packaged programme with a name and a price. The specialist themselves was the product, and the reason someone needed them changed depending on who was asking — a family noticing memory changes, someone newly discharged from hospital needing a plan, a routine specialist review nobody else in the system was offering. Three completely different doors into the same room.
I'm a visual thinker, so I knew immediately this wasn't a copy problem I could solve with better sentences. It was a presentation problem. Get the structure and the visual logic wrong, and the page reads as vague — too much waffle, not enough substance, a service that sounds like it could mean anything. Get it right, and it reads as robust and specific, even though the "product" is a person, not a programme.
A concept like this is usually where a front-end contractor gets looped in — even though it's still genuinely unclear whether the idea is going to work. Any custom visual element gets commissioned separately from a designer, which means waiting on someone else's calendar to find out if a rough idea has legs. Slide decks don't solve this either. A slide can describe a layout. It can't tell you whether three different use cases converging on one specialist actually feels coherent once it's real, in a browser, at the size someone will actually read it.
I already understood the real use cases from working alongside the clinical team, so I listed them out in plain language first — not a brief, just the actual scenarios. Only once I had that list did I ask AI to propose a page structure based on it. That order matters. An AI-proposed sitemap from a blank "what sections does a service page need" prompt is generic. An AI-proposed structure built from a list of real, specific scenarios is something you can actually edit into shape. I still adjusted it afterward — knowing what's "too much" for this particular audience is a judgment call, not something to outsource.
My default is handing over live links. Claude scrapes a live site well, and that's usually the fastest way to get something that matches your actual brand, not an approximation of it. The one place this falls down is a page search engines haven't crawled yet — brand-new pages, or anything behind a very fresh deploy. In that situation, save the page as an HTML file and upload the full export instead. Slower, but it gets you the same accuracy.
The core challenge here was showing that one specialist could genuinely serve very different needs, without it reading as a dry bullet list of services. I asked for a "pathways" style element — several distinct entry points, all converging on the same specialist. I specified what it needed to communicate first: breadth without dilution, that this one person is genuinely equipped for different situations. The actual visual style was a secondary question, decided after the concept was right, not before.
Same principle as always: ask for a full styled HTML page, including the custom visual element built inline, not sourced from a stock library or commissioned separately. This is what turns "here's an idea" into "here's the actual pitch."
This is where the real revision happened. The first draft led with the specialist's clinical credentials and qualifications — accurate, professionally reasonable, and completely cold. It read like a CV. It answered "why should I trust this person" before it answered "does this apply to me." I pushed back and asked for the framing to flip: lead with the actual situation someone's in, and let the credentials sit further down as reassurance once they'd already recognised themselves in the page. Same information. Different order. The whole page went from clinical to human in one revision.
I want to be honest about the boundary here, the same way I was about the CMS gap in the last post.
I don't propose that anything built this way becomes the live site. What it becomes is a genuinely useful brief. A front-end contractor — or whoever ends up building the real, production version — gets a working reference for exactly what you want: the structure, the tone, the visual logic, even the interactivity you're imagining. They still need to adapt it to your actual CMS, handle the real responsive breakpoints, wire up whatever your environment requires. That's real, skilled work, and this doesn't replace it.
What it replaces is the version of this process where a contractor is building and guessing at the same time — where half their job is interpreting a vague brief instead of executing a clear one. A rendered prototype means they're building from something real, not from your best attempt at describing it in a meeting.
A front-end contractor engagement for something that was still, genuinely, just a concept. The prototype itself became the pitch. Stakeholders reacted to something they could click through, not a description of something that might exist — and by the time it was time to brief an actual developer, there was nothing left to guess at.
This is one of seven workflows in The Website & Product Content Playbook, my free guide to building, auditing, and fixing website and product copy without a content team.