Designing review into AI-drafted slides

A convincing deck still needs a review

Medical teams needed to turn source material into branded training slides. A polished deck was only part of the problem. Reviewers needed to see where a claim came from, correct it and understand whether the draft was ready to share.

I designed the front-end experience and the points where people would review the work. The wider team owned the slide engine and technical integrations. We explored a standalone builder and a proposed slide-making step inside the medical-content workflow.

Where a person has to decide

The business chose protocol-training decks as its first content pilot. I designed the workflow around a training producer bringing a study protocol and older decks, an agent proposing the storyline and a scientific reviewer checking each claim. The intended rule was simple: a person checks the draft before it can leave the workflow.

The specification required the agent to mark generated or unsourced rows. A reviewer would confirm each row, with no confirm-all button, before a named person approved it. Every factual claim needed its own citation. Drafting stayed open; approval and export were gated.

Three proposed review steps

In mid-July I explored how Slide Builder could sit inside the medical-content workflow. The design separated three reviews: structure and instructional format, scientific claims, and conversion to a reusable branded template. These were the proposed review steps, not proof that a connected system completed them.

The same week, the team held its first working session with the training team who would use it. I worked from its transcript. The scientific reviewer carried the most risk, and one protocol training could need input from seven stakeholders.

What the experiment exposed

A small July experiment checked whether an exported slide inherited the PowerPoint template's theme. The main color changed when the theme changed. The same renders exposed font substitution and text-wrapping problems. That supported the next build decision; it did not establish a finished exporter.

By August I was preparing design references, onboarding material and code for the next team. The records still describe handoff in progress. The work here shows my prototype and review decisions, not a production release or completed team adoption.

A new assignment in May

In May 2026 I moved from the risk register to the Global Medical Affairs AI Workbench. The medical organization was running AI projects one at a time, each with its own tools and its own review habits. The program's answer was the Workbench, one workspace for several AI-assisted tasks with one set of review rules.

I worked on it as a UI/UX Business Analyst & AI Engineer. I joined to design the shared interface, and I built its prototypes with AI coding agents. Over the next four months the job grew. By August I also kept the backlog for the first content pilot, checked the plan against the people available to build it, and wrote down the questions Compliance needed to answer.

On 22 June the sponsor said the work was too slow and the interface showed features that did not work yet. The team cut the leadership demo to two use cases. I wrote the rule for how to show them: build through the human approval step, and label analytics, repeat runs and role handoffs as mock-ups. The lineup changed again before July, but the distinction between working and illustrated behavior stayed necessary.

A list anyone could add to

By August the content pilot's feature list held 73 asks. Anyone could add to it, and plenty of people did. Rows had no size and no owner who could say no, and nothing recorded what had been ruled out. Translation, cut from the first iteration, came back on 21 August, and the list couldn't say who had cut it or when.

The same day I restructured the list. 20 items went to Committed, 46 to a parking lot and 7 to Declined. A committed item needed an owner, a date and a reason tied to a source, such as a process step, a rule or a user's own words. I added a size to every committed item. With one part-time backend developer, a list without costs was a wish list.

That day the program's architect also made compliance a day-one requirement. The backlog carried it as one medium-sized item. I broke it into the seven pieces of work it really was, and Committed went from 20 items to 27.

14 to 26 person-weeks against about 2

A September executive demo already had a lineup of nine features. To see whether the team could build it, I sized every committed item and turned each size into a range of person-weeks.

The nine features needed 14 to 26 person-weeks. Supply before the demo was about 2 person-weeks, spread across three part-time people. Only one of them could do backend work, and every one of the nine features needed it. That left about one person-week for the part that mattered.

The sizes were my judgment, so I tested a more optimistic set: small items at 0.25 to 0.5 person-weeks, medium at 1 to 2, and large at 3 to 5. Those reduced size bands put the same nine features at 9.5 to 18 person-weeks, still well above the backend time available. The workbook calls this scenario "halved," but it does not halve every estimate.

Eight questions, each with a default

A session with Compliance was set for 24 August. I didn't want that hour spent on topics, so I wrote eight control questions and four yes-or-no decisions ahead of it.

Each question said why it mattered and what answer would close it. Can the agent write a claim the protocol doesn't support, and what stops it? For any exported deck, can we say who generated it, from which sources, and who approved it?

Each one also carried a default the build would follow if nobody answered. For unsupported claims, the default was to warn and log a reason for any override, then block outright in the next iteration. Any default still standing at the demo would be reported as "decided by default, decider: nobody".

Who accepts the work

The backlog also recorded who would accept each item as done. Of the 27 committed items, 19 named someone, some only provisionally. Eight named nobody, including all seven compliance items.

I logged each gap as a blocker with a single owner, because a blocker with two owners has none.

A slide that claimed too much

In June 2026 I scoped a second use case: an assistant that helps medical writers draft Standard Responses. A Standard Response is a short, balanced answer to a doctor's question about a medicine. The writers already used another AI tool for this.

My first slide for the business leads gave that tool a quality score. On 8 June my manager pointed out that we hadn't run that comparison yet, so we couldn't claim those numbers. I took them out and rebuilt the deck around the writers' problem.

On 9 June I worked with the medical-writing lead to narrow the comparison. Writers often updated a section rather than wrote a whole Standard Response. We needed the exact request and a human reference, potentially just one paragraph. Saving time on an update was harder to isolate, so a new response remained another proposed test case.

Agree the goal in writing

On 6 July the medical-writing lead said the team wasn't agreed on the goal, and asked for one written objective that everyone signs. There wasn't time to run a side-by-side test before the leadership session, so I drafted the objective that day. It called the work a feasibility test, not a decision to replace the current tool, and named two test cases and what "done" meant.

Six use cases looked like six demos

By June new people kept joining, each use case looked like a separate demo, and nobody could explain the whole thing in one breath.

The answer was a Start Here deck of twelve short slides, plain words first, with the real product terms saved for slide 11. It hung the whole program on one question: what kind of work is this? The answer picks one of four routes, and everything else follows from it. The deck mirrored two FigJam maps: a landscape map of the program and an orientation map.

The program's decision records gave that map a useful split. A request to one tool stayed a direct conversation; work that needed several tools gained a supervisor, a visible plan and a place to reconcile their outputs. The heavier view was earned by the task, not shown to everyone by default.

The home screen also had to show work waiting for a person. The team weighed a permanent empty composer, a separate ledger and separate project inboxes. On 21 May it chose one work-in-progress home with an "Awaiting you" queue for approvals, sign-offs, anomalies and access requests. A week later the plain chat box came back. Reviewers, me included, had already said the home looked too busy, and nobody had tried the queue with real users. The queue moved to a later, separate surface. Its logic was written and tested in code, but no screen used it.

A handoff anyone could run

In August the engineer due to receive my handoff left the program. So at the end of August an onboarding deck set out a working session a new facilitator could run without inventing the process. It takes sixty minutes and ends in a short brief.

Every note in the room gets one label: confirmed, assumption, question, decision or blocker. The rule I cared most about sits in the middle. If the evidence or the owner is missing, the note stays a question. Agreeing in the room doesn't turn it into a decision.

Decisions that didn't stay settled

The program kept its design decisions as dated records, and a record could be reversed or re-opened like any other. Four of them show the team changing its mind in writing instead of defending the first answer.