Designing the AI Workbench

A different assignment, the AI Workbench

In May, my focus shifted toward the shared AI Workbench as the risk-register ownership transition began. The Workbench brought several AI-assisted tasks into one workspace, including budgeting, study review, and medical writing. Each needed its own way to inspect and act on the result.

Give each task the view it needs

Leadership wanted people to start work with a chat request. Engineers already had budgeting and study-governance prototypes. I asked to see those flows before building the interfaces. In the design sessions, I pushed to show the decisions people still had to make after the request.

I adapted my colleague's budgeting interaction into the Workbench. A request opened proposed spending by month, where someone could compare values and question a line.

The study-governance team started with a morning queue. Opening a study showed its case file and next action, with routine activity separate from decisions requiring confirmation. I built that view from the engineer's existing scenarios and workflow.

For medical writing, the revised prototype replaced a static reader and separate review panel with an editable document. Citation chips and comments sat beside the relevant sentence. A writer could accept a proposed rewrite there. The team deferred a full rich-text editor; its extra formatting and collaboration features were beyond the demonstration's scope.

Chat could start the work, but the table, queue, or document held what the person needed to inspect. I designed that shared experience with colleagues who supplied domain logic and engineering integration.

Cut the steps in evidence planning

The evidence-planning prototype made people score, search, and create in sequence. It felt like a quiz. I asked to cut the steps. The first revision made them available as tabs and checked for duplicates while someone typed.

After the July demo, I revised the flow again using a domain colleague's demonstration to clarify the fields and process. One request produced a draft evidence gap. Before submitting, the person could review it alongside suggested changes and similar records.

The duplicate check moved into that decision. A very close match offered editing the description or using the existing record, with no option to submit the unchanged duplicate.

I built this revision with AI assistance and sample data. It had no live similarity service, and the records contain no measured usability improvement.

Review the sources before drafting slides

An early content flow started making slides before establishing the sources. I moved source input and evidence review ahead of storyline confirmation, so the producer could see missing material before preparing the presentation.

The program lead asked me to coordinate the medical-content use case. I tracked dependencies and timing, helped manage expectations, and worked with colleagues to define the inputs and comparison for the demo. Reviewing the interface alone could not tell us whether the generated content was better.

Keep missing evidence visible after a request

With AI assistance, I built the source-review interface, kept its state shared across steps, and added recovery from a failed request. The local demo deliberately failed the first access request. A retry recorded the request but left the source unavailable.

The gap stayed unresolved in the storyline. Routing it to an expert changed who needed to act, but left it in the unresolved count. Continuing the task did not mark the missing evidence complete.

Requests were simulated and state stayed in memory. Download and release controls displayed alerts.

Revise the requirements with medical specialists

Medical-training specialists reviewed a later prototype and challenged its assumptions. They needed to distinguish supported content from generated interpretation. A protocol was not always available. Priorities discussed in a kickoff might never appear in the uploaded documents.

They also wanted more ways to lay out a scientific story. Translation required someone to validate scientific language across markets, so the team removed it from the proposed first iteration.

That feedback gave me more specific source, context, layout, and scope requirements to work through. The session was a stakeholder walkthrough, not a usability study or scientific validation.

Preserve a reviewer's request for changes

The code in a later Workbench prototype counted a sent-back claim as reviewed while keeping its section blocked from export. The reviewer had made a decision; the content still needed changes. The export hold named the affected sections and linked to the first one needing attention.

Bulk acceptance filled in undecided claims and preserved earlier requests for changes. It could not erase a reviewer's objection.

This version contained local PowerPoint generation code, sample content, and a simulated reviewer. The archived sign-off wireframes belong to a separate version. Later records describe further review and release logic that was not connected to the interface. None of these establishes a connected scientific approval service.

Three gates, three different jobs

A medical training deck passed through three review gates before anyone could export it. A hygiene check for formatting and instructional design. A scientific check for accuracy and on-label claims. A template conversion that turned the approved draft into branded slides.

I interviewed the three people who staffed those gates. They did not want the same things. The scientific reviewer needed to trust that the gate before hers had already caught the mechanical problems, so she was not re-catching them herself. The content orchestrator needed to see every draft in flight at once, not just the finished ones. The hygiene reviewer needed one thing above all: confidence that pressing Export produced a working file rather than a gamble.

The journey bottoms out exactly where it matters most

I mapped her path from the moment a draft arrives to the moment she sees what her sign-off produced. The lowest point is the review itself. It is the step with the highest stakes, the least verifiable signal, and the most external time pressure, all at once.

That is also where I found the problem. At her gate the system ran an accuracy checklist across four dimensions and reported all four as passing. It reported them as passing every time, for every draft, because there was no accuracy model behind it. The hygiene gate before hers did the same thing. Two of the three gates were reporting a result they had not actually produced.

Explain how terms relate

Commercial and medical colleagues needed to look up a term and understand how other teams used it. I built the terminology prototype so they could do that without learning the underlying vocabulary structure.

Search results showed the definition, identifier, source label, and synonyms. The detail view gave each relationship its own place: aliases for the same concept, a hierarchy of broader and narrower concepts, and cross-references to other vocabularies.

The reviewed search-to-detail path used prototype data. Live terminology services and external integrations were outside the original scope.