Challenge
No shared definition of the authoring problem
Different roles described different failures.
Life sciences · AI-assisted design · speculative prototyping
I made the missing work visible before anyone committed to building it.
I used AI to learn an unfamiliar domain, then designed a speculative prototype to expose the real brief: a missing upstream workflow. Research shaped it into a four-pillar MVP; a custom agent harness carried the design intent into code.
- Role
- Lead designer + prototype builder
- Domain
- Life sciences · clinical study authoring
- Stack
- React · TypeScript · Figma Make · VS Code
- AI tools
- Claude · Gemini · GitHub Copilot
- Status
- MVP handed to engineering
Pharma organisation anonymised. Stakeholder quotes paraphrased.
prototype screenshot — dropping in soon
First proof · coded prototype
The artefact that changed the brief.
Stakeholders recognised a missing pre-authoring workflow inside this broader future-state prototype. That recognition became the New Opportunity module.
designed to provoke, not prescribe
The case in five decisions.
20-second read
I designed
A speculative prototype as a boundary object
Broad enough to expose hidden assumptions.
Users revealed
A missing stage before formal SDC authoring
The informal one-pager became a product module.
Team decided
Eight areas would converge into four pillars
Research reduced cognitive and structural load.
Engineering estimated
6–8 weeks of delivery effort avoided
UI build, QA iteration, and clarification.
01 / The brief · I framed
The brief described a symptom. I needed to find the shape of the problem.
Leadership, authors, reviewers, and delivery partners were each right about a different part of the experience. The work was to give those partial truths a shared form before turning any of them into features.
Original brief — paraphrased
“We need to improve the SDC authoring process. It's too slow, too inconsistent, and the quality is not where it needs to be.”
- Who is the primary user — the study lead, the scientific writer, or the reviewer? unclear
- What does “quality” mean — scientific rigor, formatting, governance language? undefined
- Where does the process break — authoring, review, approval, or all three? disputed
- What has already been tried? What failed? unknown
- What does done look like — a tool, a template, or a workflow change? no alignment
The pain was real, but the framing changed depending on who had last touched the work. A workshop could surface opinions; I needed an artefact that made assumptions impossible to hide.
So I chose a prototype early. Not as a solution, but as a way to put a future workflow on the table and watch where people leaned in, corrected it, or said, “that is the work we do before the document starts.”
First, though, I had to learn enough of the domain to make the provocation credible.
02 / Domain immersion · I learned
Before drawing flows, I learned the language people use to make high-stakes decisions.
Clinical authoring has a dense vocabulary, layered governance, and real consequences for imprecise thinking. I used AI to accelerate orientation, then treated stakeholder language as the source of truth. My goal was not to become the subject-matter expert. It was to design with enough fluency to ask useful questions.
Claude
Domain architecture
Built a working mental model of the study lifecycle, stakeholder roles, and governance dependencies.
- Mapped current-state authoring stages
- Identified roles, dependencies, and failure modes
Gemini
Document and content analysis
Synthesised templates, evidence plans, and prior proposals to expose patterns and contradictions.
- Compared field definitions and content formats
- Separated strong evidence signals from weak ones
What I discovered
- insight
- “Poor science” was often a framing problem: teams could not clearly connect a sound study to the evidence gap and strategic priority.
- insight
- The bottleneck was not typing. It was reconstructing context across disconnected documents before scientific thinking could begin.
- insight
- Teams could see what changed, but not why. Decision rationale and provenance disappeared between reviews.
Design hypothesis — informed by research
“The problem is not a bad template. The problem is that institutional knowledge is trapped in scattered artefacts and never surfaced as usable intelligence at the moment a study is being designed.”
This reframe shifted the design brief from document automation toward decision support. The question became: how do we help teams think, not just format?
03 / Prototype to fail early · I designed
I designed a future state people could disagree with.
The early prototype was intentionally generous: connected stages, named agents, source trails, feasibility, review, and parameter consequences. It was not a backlog. It was a conversation instrument. By making the system tangible, I could see which ideas created clarity and which only created surface area.
What I put in — intentionally
- Three connected authoring stages
- Five named agents with inspectable roles
- Parameter consequence modelling
- Source-linked evidence and decision history
- Eight exploratory content areas
What I ignored — also intentionally
- Real integrations or live data
- Production performance and scalability
- Security, permissions, and backend architecture
- Approved implementation stack
- Edge-case fidelity
Stakeholder reaction — first prototype session
“Wait — this view that updates as I change the indication, this is what we try to do manually before we even start writing. We do this on a PowerPoint. We call it our one-pager.”
The temperature in the room changed. Instead of debating a vague request, people started marking up a shared object: where it belonged in the workflow, what evidence it needed, what could be generated, and what still required professional judgment.
That was the design move. The prototype turned institutional friction into decisions I could design for.
Original scope
SDC authoring
Improve the Study Design Concept document. Better templates, better AI assistance during the writing phase.
What the prototype revealed
new module discovered · users revealed
New Opportunity Navigator
A pre-authoring workspace for shaping the opportunity before the formal document is ever opened. This is where strategy, evidence gaps, and feasibility are established. The team named it themselves.
This was the first genuine requirement to emerge from the project. It had not appeared in any brief, any document, or any prior conversation. It came directly from stakeholders recognising their own informal work pattern in the prototype.
04 / Feedback-to-requirement loop · Team decided
I turned reactions into a smaller, more legible authoring model.
Once the work had a shared shape, I moved from provocation to evidence. I recorded sessions, synthesised transcripts with AI, brought patterns back to the team, and redesigned the structure around what authors needed to understand and act on.
How I ran it
- Moderated and recorded sessions across authoring and governance roles
- Used Gemini to cluster patterns, contradictions, and decisions
- Reviewed synthesis with the team before redesigning and retesting
What users revealed
- Eight content areas obscured the author's primary task
- Strategy and scientific context belonged together
- Operations needed to run in parallel with scientific design
What I changed
- Consolidated eight areas into four author pillars
- Added field-level content guidance and required states
- Mapped parameter dependencies for agent reasoning
Before — eight content areas
- Overview
- Strategy
- Scientific Context
- Study Design
- Population
- Methods and Outcomes
- Operations
- Sources
After — four author pillars
- Strategic Context (strategy + context + evidence merged)
- Design (population, methods, outcomes, schedule)
- Operations (decoupled, always editable)
- Source (evidence library + consistency verification)
User feedback: “Strategy and context are the same question for us. Why are they separate tabs?”
Parameter dependency modelling
As the structure settled, I recognised that parameters were not independent. Changing the primary endpoint affected statistical requirements. Updating the indication changed the population criteria. I mapped these cross-field relationships — which became the specification for how AI agents would surface consequences when authors make changes.
If this field changes
Primary Endpoint
→ Statistical power and sample size
→ Schedule of activities cadence
→ Governance narrative must update
If this field changes
Indication
→ Inclusion and exclusion criteria review
→ Comparator arm may change
→ Evidence gap mapping resets
If this field changes
Study Type
→ Methodology constraints
→ Blinding and randomisation options
→ Regulatory pathway review
05 / The agent harness · I systematised
I treated design intent as something the system had to remember.
AI can accelerate craft, but only when it has a reliable point of view to work from. I built a harness of context files and routing rules so each agent inherited the product's language, information architecture, and quality bar instead of inventing a new one per session.
Context harness — project file structure Updated after every significant decision or interview
Routing
AGENTS.md
CLAUDE.md
GEMINI.md
Product context
context.md
soul.md
details.md
discovery.md
Architecture
ia-structure.md
ia-dependencies.md
Implementation
Guidelines.md
design.md
dev-handoff.md
AGENTS.md — the routing layer
Every agent request is classified before any design or code is touched. The routing table maps request types to the minimum set of context documents needed to answer confidently — no over-reading, no out-of-scope context.
| Request type | Read first | Then inspect |
|---|---|---|
| UI build / visual refinement | design.md + Guidelines.md | Target component, theme tokens |
| Feature addition | Guidelines.md | Nearest comparable feature |
| Navigation or placement | ia-structure.md | ia-dependencies.md, router |
| Product behaviour or workflow | context.md | details.md, owning code |
| Data model or API contract | domain.ts | api.ts, consumers |
The harness meant I could hand off a task to any agent — in any session, in any tool — and it would understand the product's design language, IA constraints, and implementation rules without needing to be re-briefed from scratch.
Consistent design language
Design tokens, component patterns, and visual rules live in a single authority file. No agent can introduce arbitrary colours, rounding, or spacing without violating a documented rule the harness immediately flags.
No context amnesia
Every user interview finding, IA decision, and implementation choice has a home in the harness. New sessions or new tools pick up from current state — not from generic AI assumptions about what a “pharma tool” should look like.
Compounds with the project
After every significant user interview or design decision, I update the relevant harness file before the next session. Agent knowledge compounds rather than resets — the system gets more accurate as the project matures.
06 / Developer handoff · I delivered
I handed off the decisions behind the screens, not just the screens themselves.
The prototype was built in VS Code with Figma Make, then organised so developers could follow the product logic without reverse-engineering the design. The handoff included types, data boundaries, representative states, reusable components, and the rules that kept them coherent.
action a
Canonical domain types
All business entities extracted into a single typed contract file. Every interface the UI uses is defined once, in one place, with no duplicates or contradictions across files.
- 16 canonical type sections
- UserProfile, StudyCard, ParameterChange
- DesignState, BudgetState, CommentState
action b
API contract stubs
Every data operation is a named, typed async function with a clear purpose. Backend developers read one file and know every endpoint to build and what shape each response takes.
- studies.list() / getParams() / saveParams()
- comments.list() / add() / resolve()
- Swap stub for real fetch — zero component changes
action c
Dead code removed
31 orphaned component files deleted. All mock data moved to dedicated data files. All dropdown options centralised. No hardcoded content remaining in any component.
- All mock data in /src/data/
- All options in dropdown-options.ts
- UI copy in ui-content.ts
Smart / dumb component split
Every component follows the same pattern from the first day of the project — enforced by harness conventions, not by post-hoc audit. Context providers own domain state. Tab components receive data as props and call setters. They never hold state of their own.
Swapping a UI component is a pure presentation change. Tracing data flow requires reading one file. This is why developers did not need to refactor anything to start integration.
/src/data/*.ts → seed data and mock content
↓
/src/services/api.ts → typed async stubs
↓
Context Providers → domain state owners
↓
Tab Components → presentation only, no domain state
To connect a real backend: update context providers to call api.* functions in useEffect. No component files need to change.
07 / Outcomes · Evidence
A clearer product boundary, and a handoff with less room for guesswork.
-
A product module that did not exist in the brief
The New Opportunity Navigator emerged entirely from the prototype session. It was not in any specification, roadmap, or conversation before the prototype was shown.
user validated
-
Requirements extracted through use, not documentation
The four-pillar workspace, parameter taxonomy, content guidelines, dependency model, and agent roles came from recorded user sessions — not from design assumptions.
user validated
-
Stakeholder alignment through artefact, not argument
Teams that were disputing the brief were collaborating on parameter logic within two sessions. The prototype replaced an abstract disagreement with a concrete, shared reference point.
observed in session
-
Implementation risk reduced before build began
The prototype preserved the decisions, data shapes, and interface states that usually need to be reconstructed from annotations and clarification meetings.
handoff-ready
Engineering estimate, post-handoff
Engineering estimated that the coded handoff avoided approximately 6 to 8 weeks of UI implementation, QA iteration, and design clarification. This is an estimate of delivery effort, not measured product ROI.
What I would do differently
I built a real Gemini API integration earlier in the process specifically to validate that the agent prompts I designed produced governance-ready scientific content. That spike confirmed the approach and shaped the prompt architecture. In the final MVP, agents are intentionally mocked — the spike was a validation exercise, not a shipped feature. I'd document that more explicitly as part of the handoff package rather than carrying it as implicit context.
I'd also surface the parameter dependency map as a shareable specification artefact from the first iteration, not reconstruct it near the end. It was the most technically useful deliverable I produced, and it deserved a clearer home from the start.
The underlying method
Make the invisible work visible. Then make the decisions buildable.
The method travels. Give the project a tangible future state early. Use that artefact to collect sharper evidence. Keep the decisions in context that future collaborators and agents can actually use. Then hand off the structure, not an invitation to interpret it.
AI made this work faster. Design judgment made it worth building.