Sub-Study · TrialComplete · T-Systems ICT India · 2025
Agile Workbench:
a review gate, not a magic button
An AI product pipeline for a team working under GxP. It moves a feature from raw brief to requirements, stories, and test cases in one browser tab. No generated text enters the record until a human has accepted it.
gated action surfaces
draft to export
prototype
dependencies
At a glance
Requirements lived in email and Word, stories were hand written into Jira with no traceability, and test cases arrived late with no link back to the requirement that caused them. Under GxP, that gap costs weeks in an audit.
Product lead and prototype author. Strategy, competitive research, all interaction design, and the build itself, working ahead of engineering as the UX reference.
- Split a mislabelled "Enrich" button into two honest actions, because the original did nothing but rephrase and users had noticed.
- Made AI output land as a suggestion beside the source text, never as an overwrite, so every change carries a human signature.
- Gated actions by role across five personas, so the governance model was visible to stakeholders before engineering began.
A validated prototype approved by the product and delivery team, now the UX reference on which the production build is scoped. Not yet in production.
The Problem
A handoff gap that an audit turns expensive.
Clinical trial software teams carry the same wound. Requirements sit in emails and documents, user stories get typed into Jira by hand with nothing linking them back, and QA writes test cases late with no thread to the requirement that produced them. In a regulated environment, rework found during an audit costs weeks rather than days.
Nothing connected a test case to its requirement
The chain from feature to story to test existed in people's heads and in spreadsheets. An auditor asking "why does this test exist" started a manual search.
AI enrichment tools were built for a different job
Adjacent products applied uniform rephrasing to any input. They ignored the section by section structure of a clinical requirement and offered no way to give the model context first.
The tools called it enrichment. It was autocomplete.
A button that promises more than it delivers costs trust once, and you do not get it back cheaply.
The Model
Five stages, five roles, one thread.
A feature moves through five lifecycle stages, and each stage exposes a different action surface depending on who is looking at it. A QA lead cannot approve a requirement. A product owner cannot generate test cases. The role map is a first class view in the navigation rather than a settings page nobody opens.
Role 01
Product Owner
Approves requirements. Owns what gets built.
Role 02
Business Analyst
Authors and enriches. Cannot approve their own work.
Role 03
QA Lead
Generates and owns test coverage.
Role 04
UX Designer
Attaches flows and interaction specs.
Role 05
Developer
Estimates and raises implementation questions.
Key Decisions
Four calls that shaped the product.
Split "Enrich" into Rephrase and Enrich
The original single Enrich button did nothing but light rephrasing, and users had worked that out. A misnamed affordance erodes trust faster than a missing one. I separated it into Rephrase, a one click polish, and Enrich, a conversation that gathers context first. The names now describe what happens.
Why it holds up
Naming an action for what it does rather than what sounds impressive is the most durable decision available in a product under stakeholder scrutiny.
A conversation instead of a form
Competitive analysis across Productboard, Linear, Coda AI, Fibery, and Notion AI showed progressive question by question disclosure when collecting context for a model. I took the same route. The AI opens a modal, asks one targeted question per section type, acknowledges each answer, then generates. Refinement is allowed after the output appears.
Why it holds up
A form says fill this in and submit. A conversation says I am listening. The second gets better answers, especially from people unsure what context a model needs.
A two step review gate on every AI output
Enriched text lands as a suggestion in the right hand panel, shown beside the original source text. The author has to accept it explicitly before it is promoted. The model never overwrites anything. In a regulated clinical context this is not a preference. Any artefact feeding downstream into stories or test cases has to carry a human review signature.
Why it holds up
Clinical audit trails require a human confirmed record of every requirement change. An auto apply pattern would have invalidated the tool for the only audience it was built for.
Role gating as a first class view
Five roles each see a different action surface, and destructive or approval actions are gated per role. The RACI role map sits in the main navigation rather than buried in settings, so the governance model is something stakeholders can see and argue with.
Why it holds up
Role gating in a prototype demonstrates the production governance model before engineering starts. It turns a UX decision into a delivery alignment tool.
What I Built
A working prototype, not a slide deck.
I led strategy, UX, and the build end to end. Working ahead of engineering meant the prototype became the authoritative UX reference for the delivery team, specifying the AI interaction patterns, the role gating logic, and the data model behind traceability rather than only the screens.
Pipeline board
Feature cards across lifecycle columns, with live counts per stage.
Rephrase
One click polish per requirement section, with scroll position preserved on re render.
Enrich
Conversational modal with tailored question sets per section type, and follow up refinement after output.
Review gate
Source and suggestion side by side, with accept and discard. No auto apply anywhere.
Story generation
Stories generated from accepted requirements, with acceptance criteria and estimates.
Test case generation
Linked test cases per story, with a traceability breadcrumb from test back to feature.
Role map
RACI view in the main navigation, with role cards and a responsibility matrix.
Comments
Threaded comments on features and stories, with role tagged attribution.
Design system view
Component showcase with live examples and a token reference.
Four themes
Two tier CSS variable architecture, including a dark mode appropriate for regulated environments.
The whole thing is a single file with no build step and no backend, which meant any stakeholder could open it from any machine and give a real reaction rather than an imagined one.
Where It Stands
Validated, and scoped for build.
The prototype was walked through with the product and delivery team across sprint sessions and approved as the UX reference for the production build. It is not in production yet. What follows is what the prototype established, not what a shipped product has measured.
Traceability
Every generated test case links through its story to the originating requirement, demonstrating the data model a GxP audit trail needs.
Governance
Five role personas with gated actions, agreed with the team before any engineering commitment.
Compliance posture
No AI output reaches a record without a human acceptance, which is the condition for using generation in a regulated pipeline at all.
Alignment
Stakeholders reacted to a working tool rather than a specification, so scope arguments happened before code was written.
Handoff
The theme architecture and component showcase double as the handoff specification for engineering.
Portability
Zero build dependencies meant demos needed no environment, no install, and no IT request.
Reflection
The gate is the product.
It would have been easy to build the version where AI writes the requirement and everyone applauds the speed. That version is unusable in a regulated pipeline, and it fails on the first audit rather than in the first demo.
Name an action for what it does. A misnamed button costs trust once and you do not get it back cheaply.
In a regulated product, the constraint is the feature. Human acceptance is what makes generation usable at all.
A working prototype gets you real objections. A specification gets you polite agreement and late surprises.
Role gating in a prototype is a governance conversation you can have before it becomes expensive.
The interesting work was not making AI write requirements. It was deciding exactly where a human has to put their name on the result, and designing so that moment cannot be skipped.
Diagrams on this page are recreated for portfolio use. The prototype runs on synthetic demo data and no client requirement content is shown.