A pharma brand site has to survive review before it meets users.

Method
What this page shows: decisions and mechanisms
Withheld
Client, product, outcomes and client files
Illustrative
Every figure drawn for this page¹

01 / My role

I own the design system calls and the handoff. Developers own the build.

01
Owned
- Design-system audit and component triage
- Reference file from the client's recent sites
- Type tokens, colour rules, local master components
- WCAG checks
- Handoff file and production test
- Figma coaching for a junior graphic designer
02
Shaped
- The sitemap, with strategy
- Where interaction earns a place
- Page order, with copy
03
Supported
- Review routing, run by the project manager
- QA test runs
- Legal review calls, when invited

02 / The brief

The constraints, not the brief, set the shape of the work.

A pharmaceutical client needed a new brand site. The ask arrived as pages and copy. Four constraints sat around it.

01
Time
The release date ran backwards. About a month before it, my focus had to move from design to handoff.
02
Regulation
Important Safety Information (ISI) is strictly controlled by legal, and every page passes editorial and legal review.
03
Technology
The parent design system was of unknown maturity, the hosting platform might be unfamiliar, and developers were wary of custom work.
04
Organization
Email, healthcare-provider sites, client-facing sites and marketing pages ran as parallel streams, each with its own creatives.

03 / The reframe

The brief counted pages. The review route set the schedule.

The brief listed pages. It did not list how often each page would be seen. After wireframes, the work moves through one loop. I export a PDF and the project manager uploads it. Each discipline marks it up. I apply the change or push back. Editorial checks punctuation, references and approved language, and legal reviews. Then it repeats, many times.

Scope was not the page count. It was the number of times a page had to be defended. That is why I start with the design system audit and the client's existing sites, before I draw a page.

04 / The decisions

Three decisions, each paid for with something else.

01

Spend custom components like a budget, with a reuse case for each

Tension: Developers resist custom work. The brand still needed pieces the parent system might not have.
Options: Design freely and negotiate later. Allow only components that already exist. Audit first, then ask for a few custom ones.
Choice: I read the parent design system file before drawing pages and listed the components I expected to use as they are. Where a need had no match, I composed it from a foundation piece, such as a card, plus smaller parts: list, title, copy, button. Only then did I decide how many custom components I could afford to request. Each request carried a rationale for reuse.
Trade-off: Audit time up front, and more scope when the parent system is thin.
Evidence: 1 · As isAlready in the parent systemUse it unchanged.
2 · ComposedBuilt from foundation piecesA card plus smaller parts: list, title, copy, button.
3 · CustomRequested with a reuse caseOnly as many as developers can absorb.
Every page element goes through the same three questions, in this order. The aim is a short custom list that developers can accept, with a reason attached to each item.Illustrative. Drawn for this page; not a client file.
Consequence: The developer conversation starts from a written list, and early asks leave a record if answers change later.

02

Start from the client's own sites for safety information and navigation

Tension: Safety information is strictly regulated by legal, and the client usually wants the same structure and navigation as its other sites.
Options: Invent a new pattern. Copy the closest sibling site. Audit several recent sites and keep what repeats.
Choice: I ran a heuristic evaluation across the client's most recently deployed sites, against an established set of usability guidelines. I recorded the patterns that repeat, including how ISI sits on the page and how navigation is organized, and kept a reference file of components that work well. New pages start from that file.
Trade-off: Less room for new ideas in the most controlled part of the page.
Evidence: Precedent audit sheet (blank template)
Pattern What I record Default
Safety information Placement, and whether it persists as a docked tray or sits inline Follow the repeating pattern
Prominence How it sits next to benefit content Follow the repeating pattern
Small screens Behaviour across breakpoints, print and scroll states Follow unless the audit finds a failure
Navigation Structure and labels used across sibling sites Follow the repeating pattern
A blank audit sheet for safety information and navigation. Each recent site gets one pass; repeating patterns become the starting point for new pages, and failures become budget items.Illustrative. Drawn for this page; not a client file.
Consequence: Problem areas in recent sites show up before design starts, so effort and budget can follow them.

Pattern	What I record	Default
Safety information	Placement, and whether it persists as a docked tray or sits inline	Follow the repeating pattern
Prominence	How it sits next to benefit content	Follow the repeating pattern
Small screens	Behaviour across breakpoints, print and scroll states	Follow unless the audit finds a failure
Navigation	Structure and labels used across sibling sites	Follow the repeating pattern

03

Get down to what the client is asking for, really

Tension: A client request reaches me through the account team as a solution, not a problem. A typical exchange: add a tab, to shorten the page.
Options: Add the tab. Decline it. Ask what the tab is meant to fix, and offer another way.
Choice: I ask why. The answer is usually a goal, here a shorter page. I explain what a tab does to the reader, offer a different solution to the same goal, and we agree on one. Then I tell the project manager what was decided and why.
Trade-off: More time in the meeting, and a team asked to learn some UX vocabulary.
Evidence: 1. ExportNumber the artboards and export a PDF.
2. UploadThe project manager uploads it for review.
3. Mark-upEach discipline comments on the file.
4. RespondI apply the change or push back.
5. RecordThe decision goes to the project manager.
6. Review, then repeatEditorial, then legal, then the loop runs again.
Decision log entryRequest · Underlying goal · Options considered · What was agreed · Who was told
The review route is a loop, and the decision log is how reasoning survives each pass. Each entry records the request, the underlying goal, the options and what was agreed.Illustrative. Drawn for this page; not a client file.
Consequence: The reasoning is documented in the route, where the team can find it later.

05 / The rules

Regulation is a set of mechanisms I design around, not a gate at the end.

Review route: PDF export, mark-up, an editorial pass for punctuation, references and approved language, then legal review.
ISI: Safety information is regulated by legal, so placement and navigation follow the client's existing sites.
Legal calls: When I am invited, I join, ask questions and learn who is in the room. That lets me head off suggestions that would cause problems later.
Accessibility: I check colours, fonts and features against WCAG.² In a regulated setting, it lowers lawsuit risk and widens adoption.
Utility states: Error pages, thank-you modals, expand modals, interstitials and loading states, designed at intake because teams rarely list them.

06 / The handoff

Handoff gets its own month, and it starts with a clean file.

I count back from the release date and reserve about a month, at least, for handoff. Before that, I ask developers about their environment, their component library and which custom components are feasible.

In the handoff file, every element links to a token, layers are named, and the hierarchy mirrors code. I invite the external developers and QA, share the style guide and design system, and email the final link so there is a record.

QA sends questions and behaviour mismatches. I reply with the intended behaviour and tag the right people. In production, I click every button, check that links open in the right window, and test scrolling. Agreed fixes and dropped items go in one email.

07 / The result

I am holding back outcomes until each one has a source.

This page makes no outcome claim. Results from this engagement are not mine to publish until the work is live and cleared by the agency and the client.

Each figure will enter the page only with a source, a definition, a date and a record of who approved it. Until then, what you can check is method: the decisions above, their stated costs, and the mechanisms they work inside.

The engagement is current, so this page will change as it proceeds. In conversation, I can go further into the artifacts and the reasoning, within what the agency and client permit.

Credits and sources

This page shows method and withholds client work.

Credits. I worked with a product lead, a project manager, strategists, copywriters, an account team, an art team, external developers and QA.

Clearance. Tier D, method only. No client name, product, therapy area, review comment or client file appears. The figures are blank templates drawn for this page.