A medical reference platform for hair restoration, designed and prototyped end to end. The hard part wasn't the interface. It was building trust into a field with no authority to borrow it from.
A medical textbook that lives on the web.
Trichopedia is a reference platform for hair loss and hair restoration surgery, written and peer-reviewed by physicians. Think of it as a textbook that lives on the web, stays current, and says on every page who wrote it, who reviewed it, and when.
It carries six kinds of material: evidence-based articles at its core, an atlas of labelled clinical photographs, real patient cases followed from presentation to outcome, lecture and surgery videos, short summaries of newly published research, and a library of citations to the primary literature.
It serves two audiences, weighted equally. Physicians, who both write and read it. And patients, who arrive from a search engine with a specific worry and need to understand what they're reading, and trust it.
02 / THE PROBLEM
A field with no source of truth.
The reason it needs to exist is a trust vacuum. Hair restoration has no single trusted reference and no recognized governing authority. The field's main board isn't recognized by the medical establishment the way other specialties' boards are, and the largest professional society covers only about a third of practising physicians. There is no institution a new platform can borrow credibility from.
Meanwhile the stakes are rising. A newer technique lowered the barrier to entry so far that an estimated thousand procedures a day are performed in Turkey alone, many in clinics with no physician present. Patients researching a surgical decision are left with Google, clinic sites whose before-and-after photos are easily faked, paywalled journal papers written for specialists, and forums where one bad outcome gets written up at length and a million ordinary ones never do.
So the design problem wasn't "make a medical wiki." It was: build a platform that is visibly, structurally trustworthy, when there's no authority to inherit trust from. It has to manufacture its own.
03 / TWO AUDIENCES, SERVED EQUALLY
The platform fails if physicians don't contribute.
Most reference sites optimize for readers. This one has two audiences that had to be weighted equally, and that decision shaped everything.
Physicians are both the writers and the readers. If they don't contribute, there is no platform, which makes the contributor experience a primary design surface, not an afterthought bolted on behind a login. Patients arrive from a search engine with a specific worry and need to understand what they're reading and trust it fast.
Designing for both at once meant the same page had to work as authoritative clinical reference and as something a frightened patient could parse. That tension runs through every template in the platform.
04 → BUILDING TRUST
If you can't borrow trust, you build it into the page.
The platform's entire argument is that it can be trusted. With no institution behind it, that argument had to be made structurally rather than asserted.
Every piece of content, an article, an atlas image, a case, a video, carries the same metadata header: author, version, editors, published date, last updated, last medically reviewed, and a citable identifier. The provenance is on the page, not in an "about" footnote. Articles say plainly when they've gone stale. And when new research has been published since an article's last review, it appears above the article, not below, because a reader about to act on out-of-date information needs the correction first, not eventually.
An early version had drifted into four different provenance treatments across the four content types. I replaced them with one shared component, so the trust apparatus reads identically everywhere. Consistency is itself a credibility signal: a platform that presents its sources differently on every page looks improvised.
05 → RESEARCH
I refused to design against placeholder text.
The engagement began with a structured pre-work exercise and a recorded discovery session, and one request did more for the design than anything else.
Rather than send the client a form to fill in, I designed and deployed a purpose-built web form for him to complete over a week, with autosave, because losing his input was the failure mode that mattered. The central ask was this: pick the condition you explain most often, and write the page you wish existed for it. Don't format it. I wanted to design against real clinical prose, because placeholder text makes every layout look good, while real content is longer, denser, and more awkwardly shaped, and it shows you where the design has to work harder.
That produced templates built against genuine clinical writing from day one. The discovery session then overturned assumptions in the original brief. The belief that physicians look things up quickly between patients, for instance, was simply wrong: between patients is chaos, not study time. So the platform stopped optimizing for speed of lookup and started optimizing for material that survives being found, saved, and returned to later.
06 → DESIGN DECISIONS
Built both, measured, let the evidence decide.
A recurring pattern in this project: when a design question came up, I built the alternatives and measured, rather than defending a preference.
The knowledge-base articles had a sticky contents rail. The client wondered if the page was better without it, so I built a second version, at a second address, with a toggle to flip between them. Measuring revealed something neither of us expected: removing the rail didn't widen the text at all, because the prose was capped at the same measure either way. What changed was position, not readability.
I'd initially reasoned the freed space should be used to center the body, balanced margins look intentional, a gap looks unfinished. Measurement reversed me. Centering pushed the prose 149 pixels inside its own title, aligned with nothing, while the breadcrumb, title, and metadata all began at the same left edge. With the rail present, that indent had a cause. Without it, none. I caught it by asking the question and measuring the answer, not by trusting the aesthetic instinct, which was wrong.
The same discipline settled capitalization (sentence case, applied at display time, because the stored values double as filter keys and capitalizing them would have broken filtering silently), image annotation behavior (enlarge in place rather than trapping the reader in a modal, which also avoided a WCAG 2.2 failure), and more. Decisions traced to measurement, not taste.
07 / HOW THE WORK WAS BUILT
I directed. The AI implemented. I measured everything.
Trichopedia is a working React prototype: 65 screens, a contribution flow that runs end to end, and a knowledge-base article that can be written, submitted, reviewed, and published inside the browser. It's honest about what it is. There's no backend; it's a validated prototype built to prove the design against real content and client review, not a production system.
Effectively all of the code was written by Claude Code, under detailed direction from me. That direction was the design work. A build spec didn't say "make a form"; it specified the deploy target, required autosave because losing the client's input was the failure that mattered, demanded a visible save state so he could trust closing the tab, and named the stakes: this page is a work sample, and a generic template damages the relationship it's meant to serve.
That's the pattern throughout. I set the problem, the constraints, the acceptance criteria, and the judgment calls, then reviewed and redirected the output. Several decisions in this case study were reversed by me after seeing them built. The value isn't in generating code fast. It's in knowing what's wrong when you see it, and having the discipline to measure rather than assume. Describing this as "hand-coded" would be false. Describing it as "AI-generated" would be equally false. The truth is a directed build, and the direction is where twenty years of judgment lives.
08 / REFLECTION
What I'd do differently, and what's still unsolved.
The research rested on a sample of one.
Everything the design assumes about how physicians work rests on a single physician, who is also the client, and therefore the least neutral source available. The project's own requirements flagged this in writing, recommended talking to two or three other physicians, priced it as cheap, and it never happened. I'd fight harder for that next time. A platform whose entire premise is credibility shouldn't be designed against one voice, however expert.
Half the audience was designed at second hand.
Patients are one of the two equal audiences, and not one was spoken to. Their needs were inferred from the client and from research about the field, which is real evidence but not the same as watching a frightened person try to read a clinical page. That's the gap I'd close first.
The sharpest opportunity in the brief is still unsolved.
Patients believe a common medication's side effects are near-universal, when the real rate is one to two percent. Representing prevalence against anecdote, credibly and visually, was one of the clearest chances to outperform every existing source. A panel for it was built and then removed. There's currently no answer to it on the site, and it's the thing I'd most want to revisit.
The method's biggest risk is the method itself.
With effectively all code AI-written and no traditional test framework, verification leaned on browser-driven measurement scripts. Two of those scripts had silent failure modes that let them report success when they hadn't checked properly. In a directed-build workflow, the verification is load-bearing, and verification you can't trust is the single riskiest thing about the approach. Next time, I write the checks that check the checks.