Design Technology · TrialComplete · T-Systems
Constrain the model,
do not trust it
An engine that turns a written brief into a working clinical application screen. The model writes only the page body. Code injects the shell, so output cannot drift off system.
a golden exemplar
compiled into the engine
injected by code
run the tool
At a glance
A UI modernisation meant every workshop needed screens, but prototyping was manual and off the shelf AI produced marketing layouts, not dense clinical applications.
End to end owner. Concept, UX, the knowledge architecture behind the prompts, the front end build, and the rollout to the team.
- The model never writes the app shell. It generates the page body, and code injects navigation and the design system CSS around it.
- A structured brief form instead of a prompt box, because non designers do not know what a good brief contains.
- A clarify gate that asks two or three questions before spending a generation on an ambiguous brief.
Output is on system by construction rather than by instruction. BAs and product owners self serve exploration screens, and the engine was later rebuilt in a second environment from the knowledge packs alone.
Context
A design system nobody could run.
TrialComplete was going through a UI modernisation, and every conversation needed screens. New module concepts, workflow variations, the "what would this look like" question that comes up in every workshop. We had a complete design system with established patterns, and producing a single on system screen still took hours.
The insight was not that we needed a smarter model. It was that we needed to teach a model our design system and our domain, then constrain it until off brand output became structurally impossible.
The Problem
Four ways prototyping was failing us.
Every screen meant hours in Figma or hand written HTML, even though the patterns already existed in the design system. The work was repetitive without being automatable by hand.
Quick mockups drifted off system, and on system screens took too long to justify for a throwaway exploration. There was no cheap way to stay accurate.
BAs and product owners with clear ideas still waited on design capacity. The bottleneck was not thinking. It was production.
Off the shelf generators produced hero sections, gradients, and rounded cards. Nothing like a dense compliant clinical application, and they knew nothing about our components, tokens, or workflows.
The constraints I had to design inside
Model access only through an approved internal gateway, with no data leaving the network. The tool had to support both that gateway and direct API access, switchable by the user.
Recipients included non technical staff on locked down machines. No Node, no build step, no local server.
Subject IDs, visit schedules, lab values, query workflows. Data that looks fake destroys credibility with domain experts on sight.
Architecture
The model never writes the shell.
This is the decision the whole engine rests on. The model generates the page body and the page specific CSS between two markers. Everything else, the sidebar navigation, the top bar, the full design system CSS, the interaction JavaScript, is injected deterministically by code around that output.
Navigation is therefore pixel identical on every generated page, the design system CSS is always complete and current, and an entire category of failure disappears. Not because the prompt asks nicely, but because the model was never given the opportunity.
The knowledge packs
Rather than hoping the model knew good design, I compiled the design system and the clinical domain into explicit instruction packs injected into every generation.
Pack 01
Domain
Subjects, visits, queries, labs, adverse events, randomisation. Makes generated content read like a real clinical application rather than filler.
Pack 02
Design language
The structural recipes. Canonical page patterns, status to chip colour mapping, density and typography rules. Tells the model which classes to use and when.
Pack 03
Class catalogue
The complete inventory of design system classes with usage notes, so the model composes from existing vocabulary instead of inventing styles.
Pack 04
UX and craft
Microcopy rules, content realism rules, and explicit bans on the AI look. No emoji icons, no hero sections, no gradient cards.
Each of the eight supported page types also ships with a hand built exemplar, a correct and complete skeleton of that pattern. The model imitates a proven structure rather than improvising, and that collapsed the variance between generations more than any instruction did.
Tool UX
The generator is a designed product, not a prompt box.
Most of the quality came from what the form collected and what the exemplars showed, not from the model. That is the part people miss about tools like this. Better inputs beat better models.
Structured brief, not a blank prompt
Page name, purpose, layout type as illustrated pattern cards, navigation placement, column and field inputs, and an exact copy field. The form teaches users what a good brief contains.
Multimodal input
Whiteboard photos, legacy screenshots, and spec documents. Images go to the model as visual context, documents are parsed into the brief.
Clarify before generate
For an ambiguous brief the engine asks two or three targeted questions before spending a generation. The same gate a good designer applies.
Staged progress
Generation is not instant, so a staged narrative reports what is happening rather than showing a spinner. Users stay oriented instead of anxious.
Refine in plain language
A refine bar takes ordinary change requests, plus one click chips for common adjustments like a denser table or an added filter panel.
Click to tweak
Click any element inside the generated page and describe a change to just that element. The prototype itself becomes the input surface.
Version history
Every generation and refine is a restorable version with undo and redo, so experimenting carries no risk of losing a good result.
Output that travels
Download as a single self contained HTML file or save to a shared gallery. A stakeholder demo becomes one email attachment.
Distribution as a design decision
The whole tool also ships as a single standalone HTML file with the engine, the knowledge packs, the interface, and the full design system CSS embedded. Unzip, double click, paste a key, generate. No install, no build, no server. That one choice turned adoption from an IT request into a file share, and it did more for uptake than any feature.
Decisions
Six decisions worth defending.
Outcomes
What changed
This is an internal tool, so I did not run controlled measurement against a manual baseline. What follows is what the engine does and how it was adopted, without numbers I cannot stand behind.
On system by construction
Generated shells are design system compliant because the shell is never model authored. Compliance is a property of the architecture rather than a quality to be checked.
Design capacity freed
BAs and product owners self serve exploration screens, which leaves design capacity for validated work rather than throwaway artefacts.
Ideas become screens in the room
Live generation during workshops turns a suggestion into a reviewable screen inside the meeting that raised it.
Adoption without IT
The standalone package rolled out to the product team by file share, with no install and no infrastructure request.
The architecture is reproducible
The engine was rebuilt in a second environment from the knowledge packs and a porting guide, which proves the approach is documented rather than tribal knowledge.
The design system became infrastructure
Encoding the system as machine readable rules turned documentation into something executable, and the same packs onboard humans.
What I Learned
Four things I took from building this.
Design systems are executable
A design system encoded as machine readable rules and exemplars stops being documentation and becomes infrastructure. The same packs that teach a model also onboard a new designer, which was not the goal but turned out to be the more durable result.
Constrain structurally, not rhetorically
Every "the model must never" line in a prompt is a hope. Every deterministic injection is a guarantee. The work is moving guarantees out of the prompt and into code, and that principle transfers to any AI feature in a regulated product.
The tool's UX matters more than the model
Most of the output quality came from what the form collected and what the exemplars showed. Swapping models changed less than improving the brief did.
Distribution is a design decision
The single file build did more for adoption than any feature I designed. If a tool needs an IT request to try, most people never try it.
The useful part was never the generation. It was proving that a design system can be compiled into something a machine executes, and that the guarantees you care about belong in code rather than in a prompt.
All visuals on this page are recreated diagrams, not product screenshots. Architecture is described without proprietary implementation detail.