AstraZenecaPart 5 of 5

More AI prototypes

Five smaller AI products: a forecasting tool, a brand-planning assistant, one front door for many assistants, a conference app, and two assistants for research governance. I designed the interfaces. Other people owned the models, agents, and data behind them.

Contribution: Product design, business analysis, and prototype implementation

Explore the Lucid forecasting prototype in Figma

Facts

Engagement: August 2025 to August 2026
Contract title: Senior UI/UX Business Analyst
Responsibilities: Requirements, interaction design, frontend prototypes, and shared design patterns
Collaboration: Business owners, medical specialists, product partners, designers, and model and backend engineers

Make the forecasting workflow visible

Show the assumptions behind a change

I designed the forecasting frontend and helped narrow the task to loading a forecast and changing its assumptions. Domain colleagues supplied the model; collaborators handled Python integration. The reviewed walkthrough used mock inputs, with the AI layer inactive.

The assumptions workspace showed each input's value, unit, source, status, and history. A detail panel let someone inspect the assumption's scope and update it.

The configuration preview grouped input methods, curve shapes, and adoption phases. The export dialog offered format, data scope, granularity, scenario, and chart choices. Both used example data; model accuracy and the export service remained unverified.

Inspect assumptions, configuration, and output

Lucid assumptions workspace with parameter values, units, sources, status and history beside a selected peak-share input, an impact preview and geographic scope controls. — The selected assumption stays beside its source and status while the detail panel exposes its scope and update action. Values, history labels and the impact preview are prototype examples, not validated forecast results or evidence of AI activity.
Source: Lucid Figma Make version 147, copied into an editable Figma design and exported 18 September 2026. The supplied source defines the displayed inputs and chart series as local fixtures.

Advanced Configuration dialog with input-method choices, curve shape, adoption phase, an illustrative curve preview and Save Configuration and Cancel actions. — The configuration dialog groups the input method, curve shape and adoption phase around a preview. The curve uses mock series from the prototype; it does not demonstrate model accuracy.
Source: Reusable component extracted from Lucid Figma Make version 147 and exported from the companion Figma design file on 18 September 2026.

Export Forecast dialog with PowerPoint, Excel, PDF and CSV format choices, data scope, granularity, scenarios and optional chart settings. — Export separates file format from the data, scenarios and chart options to include. This component shows the proposed choices; it does not establish a working export service or the quality of a generated file.
Source: Reusable component extracted from Lucid Figma Make version 147 and exported from the companion Figma design file on 18 September 2026.

Run the prototype to check the rest of the workflow

The assumptions screens were only part of what I designed. I ran the exported code bundle locally and captured the screens that carry the rest of the workflow: shaping the patient funnel, testing how much each input moves the answer, and assembling the report a forecast cycle has to produce.

The funnel editor treats the patient flow as nodes I can edit rather than a fixed template. Selecting a pool opens its treatments and progression rates, so the structure and the numbers stay in the same view.

Sensitivity pairs a distribution with a tornado chart, which puts the ranking of inputs next to the spread of results. Reporting starts from named packs tied to a forecast cycle instead of an empty canvas.

Everything in these screens is local sample data defined in the prototype source. No model, simulation, or export service is connected behind them.

Screens captured from the running prototype

Funnel Flow editor on a dark canvas with Entry, first-line, second-line and third-line pools joined by progression and dropout transitions, beside a Node Details panel listing the selected pool's treatments and their shares. — The funnel is editable structure, not a fixed template. Selecting the first-line pool opens its treatments and their shares beside the flow. The pools, transitions and percentages are prototype sample data.
Source: Screenshot of the Lucid Figma Make code bundle running locally, captured 21 September 2026. The supplied source defines the nodes and connections as local fixtures.

Sensitivity Analysis screen with a revenue probability distribution marked at P10, mean and P90, a tornado chart ranking six inputs by dollar impact, an input parameter table and a simulation settings panel. — Which inputs matter and how wide the answer is belong together, so the ranking sits under the distribution and the simulation settings stay visible beside both. The values are prototype examples and no simulation runs behind them.
Source: Screenshot of the Lucid Figma Make code bundle running locally, captured 21 September 2026. The supplied source defines the chart series as local fixtures.

View original

Reporting starts from named packs tied to a forecast cycle rather than an empty canvas, and recent reports keep their draft or final state in view. The brands, figures and report history are prototype examples.

Source: Screenshot of the Lucid Figma Make code bundle running locally, captured 21 September 2026. The supplied source defines the templates, chart series and report history as local fixtures.

Give a planning answer its own shape

Chat was the wrong shape for the answer

Brand planning questions rarely have one-line answers. Someone wants to know where patients leave a treatment funnel, or what a competitor's move means for the plan. A paragraph of prose is a poor way to read either one.

I designed the assistant to answer in the shape the question deserved. A funnel question returns a funnel. A competitive question returns a side-by-side read with the evidence set beside its implication. A request for the plan returns a draft with its completion state marked on it.

Contribution

I designed the interface and built the prototype. Other people owned the agent's retrieval and training. An engineer held the production frontend and implemented approved changes.

Catalogue the answer formats, then rank them

Rather than design one output and stretch it, I catalogued the formats a planning conversation actually needs and numbered them, then ranked them by how much each one mattered. A strategic ambition timeline and a core insights stack came first. A competitor teardown and a competitive landscape table came next. A numbered agenda for multi-topic questions sat near the bottom. Ranking the formats made the build order a decision rather than a guess.

Make it fast for someone who lives in it

The prototype has a command palette, a sidebar that collapses, a shortcut for starting a new conversation, and a shortcuts overlay behind the question-mark key. A knowledge-base view lists what the assistant has indexed. A source panel opens beside an answer so someone can check what it drew on before trusting it.

Scope

This is a prototype. It shows the interface and the intended behavior, not a released application, adoption, or a measured result.

Where a planning session starts

View original

The assistant opens on the questions a planning cycle actually asks, rather than an empty prompt. The sidebar keeps earlier conversations and the count of cards each one produced.

Source: Capture of the original prototype with demonstration data substituted for the real brand, trials, competitor, and colleague name; 21 September 2026

Two questions, two shapes of answer

View original

Asking where patients leave returns the funnel itself. Each stage carries its count and share, and the callout names the largest leakage point instead of leaving the reader to find it.

Source: Capture of the original prototype with demonstration data substituted; 21 September 2026

A SWOT answer in four quadrants, each listing findings above chips naming the source documents behind them, with follow-up questions underneath. — Asking for a strategic read returns four quadrants. Each one names the documents behind it, so the claim and its evidence arrive together. The follow-up questions continue the thread rather than ending it.
Source: Capture of the original prototype with demonstration data substituted; 21 September 2026

Where a planning question starts

View original

The assistant opens on named starting points rather than an empty box, and the sidebar keeps the knowledge base, the patient funnel, and the draft's completion state one click away.

Source: Original prototype; sample threads and indexed-document counts, with brand names redacted

Step one of a five-step planning flow, listing three themes with the count of questions under each, and one theme expanded to show its two questions. — The first step asks for themes and the questions each one has to answer, before any document is retrieved. Naming the questions first is what lets a later step mark a question as a gap rather than answer it thinly.
Source: Original prototype showing step one of five; generated sample themes and questions, with brand names redacted

What the corpus holds, and the structure the team chose instead

A retrieval dashboard with a summary card showing document count, model, last sync, and coverage, two suggested starting points beside it, and a live list of six indexed documents tagged by type. — Before anyone asks a planning question, the screen states what it can see: how many documents are indexed, when they last synced, and which ones. I put the corpus in view so an answer could be judged against its sources.
Source: Original prototype in the Workbench demo environment; indexed documents are generated sample records and several titles are redacted

A side-by-side comparison of a five-step planning flow and the two-step flow chosen instead, with the questions step marked as the edit path kept in both. — The team chose a simpler structure than the one I proposed. The questions step survived as an optional edit before the answer runs, so the part I cared about stayed even though my sequence did not.
Source: Reconstruction drawn for the portfolio from the account of the April 2026 review; records are invented and the figure shows the two structures, not the prototype screens

Put several assistants behind one front door

Every assistant arrived as its own product

Teams across the business unit were building their own assistants. Each one came with its own layout, its own idea of where sources belong, and its own chrome. Anyone who used two of them had to learn two products.

I designed a single shell they could share. A directory where someone browses the available assistants and sees what each one does. A landing page for an assistant that states its capabilities and offers starting prompts before the person commits to a conversation. Then a conversation view that reads the same way whichever assistant they opened.

Say where the knowledge came from, and keep saying it

In this setting provenance is the trust. I put a persistent status bar under the header showing whether the connected document source is reachable, when it last synced, and the knowledge cutoff date. It reads like an instrument panel on purpose, set in a monospace face, because it reports machine state rather than speaking to the reader. A stale source matters when the answer feeds regulated work, and the interface should say so before someone discovers it later.

Make citations clickable and sources selectable

Answers carry numbered citation anchors, and selecting one highlights the matching entry in the source sidebar. A source panel lets someone include or exclude what the assistant draws from before asking. The answer arrives in three phases, a skeleton, then streaming text, then the resolved response with its citations attached, so the wait shows progress instead of a spinner.

Scope

This is a prototype. The retrieval behavior it depicts was not connected to a live service, and no release or measured result is claimed.

One directory for every assistant

An assistant directory in two columns. Each entry has a coloured icon, a name, a handle, a one-line description of what it does, and its creator. — Every assistant is listed the same way, with a handle and a plain description of what it does. Someone who has used one of them already knows how to read the rest.
Source: Capture of the original prototype, with the assistant directory and landing views mounted directly because the export omits several dashboard components; demonstration data substituted; 21 September 2026

The shared home, and a keyboard-first version of it

A workspace home screen with a left navigation rail, four starter cards for a meeting, a file, and two tasks, a knowledge panel of recent documents on the right, and an ask field along the bottom. — One home screen holds the assistants, the tasks, and the knowledge panel together. I wanted a person to see what the system already knows about beside the box they type into, rather than landing on an empty prompt.
Source: Original Workbench demo environment; starter cards, recent items, and knowledge titles are demonstration content, and several document names are redacted

A dark, terminal-styled hub window with a single command bar, a row of eight named agent tabs, and keyboard hints for sending, switching agents, and opening help. — A keyboard-first concept for the same front door. One command bar, with the eight assistants behind it reachable as tabs, so switching agents is a shortcut rather than a navigation task.
Source: Original concept prototype; suggested queries are sample content and product names are redacted

The same door for a reviewer and for a field team

An agent home screen with an ask field marked auto-routing, an attention list of three overdue or unstarted review items each with its own action button, a row of named skills, and two available agents. — Overdue reviews arrive as three named items, each with the one action that moves it on. Two agents sit behind a single ask field, so routing is the system's job rather than something a reviewer has to know.
Source: Original prototype; reviewers are numbered rather than named, records are sample identifiers, and document references are redacted

Rep Co-Pilot demonstration dashboard with reporting tabs, quarterly progress cards, a daily priority list, and a persistent question input with camera, voice, prompt and coaching controls. — A preserved dashboard iteration puts reporting and daily priorities above the shared input. The archived prototype hardcodes the names, appointments, suggested actions, and figures shown here as demonstration records; these are not reported business results or verified activity. This is a different iteration from the separately archived task-switching demo.
Source: Original screenshot supplied by Stephen Bowman; matched to the archived V1 demo source

Make an assistant's configuration visible

Assistant configuration form separating the name and handle from its description and behavioral instructions, with a generic quality-assurance example. — Original prototype fields, recomposed side by side for this case study. The form separates how someone finds an assistant, what it is for, and how it should respond. This companion prototype illustrates configuration; it does not establish that these instructions were enforced by a live model.
Source: Original prototype detail, MED AI LABS version 59; exported from Figma, 18 September 2026

Build an event app around the team you work on

Most of a conference schedule is irrelevant to any one person

An internal oncology conference needed an app for the people attending it. The schedule was large, and most of it did not apply to any individual attendee.

Onboarding asks which team the person works on. That single answer shapes everything afterwards. Sessions relevant to their team come forward, and they can mark interests to assemble their own schedule. A map view handles the part of any conference nobody enjoys, which is finding the room.

Ask one question at onboarding, then actually use the answer

Event apps often collect preferences and then ignore them. I kept onboarding to the single question that changes the rest of the product, and let people revise it later from their account. The schedule, the interest list, and the session detail all read from that one answer. A companion admin dashboard covers the organizers' side of running the event.

Scope

This is a prototype built with sample programme data. No attendance, engagement, or release result is claimed.

The one question, and what it changes

A mobile onboarding sheet titled Customize Your Experience, asking the attendee to select their department to see their specific breakout sessions. — Onboarding asks one question. The wording says what the answer will do, so it reads as a setting rather than a survey.
Source: Capture of the original prototype with demonstration data substituted; 21 September 2026

The mobile event home after onboarding, showing the event banner, dates and location, upcoming sessions, quick actions for venue map, directions, wifi and help desk, and a bottom navigation bar. — After that answer the app is an event companion. Quick actions cover the practical questions, and the bottom bar keeps the schedule, saved sessions, and map one tap apart.
Source: Capture of the original prototype with demonstration data substituted; 21 September 2026

The organisers' side, and what a draft actually is

An event platform admin dashboard with counts for published events, drafts, and registered attendees, and quick actions for departments, session types, and analytics. — The organisers' side of the same prototype. Drafts sit beside published events on the dashboard, because a half-built event is the state an organiser is usually in.
Source: Original prototype; sample event and attendee counts

A diagram in three bands: create, edit, and save a draft; three separate copies named working state, local backup, and saved draft; then load, restore, and validate before publishing. — Saving and publishing had to stay two different things. Naming the three copies separately is what made the recovery behavior decidable.
Source: Retrospective diagram drawn for the portfolio from the supplied event-builder sequence; not an original client screen

Move a research proposal through its governance

The work is routing, chasing, and writing it up

Externally sponsored research proposals move through a review committee on a clock. Someone has to route each new proposal to the right medical lead, keep the pipeline visible, prepare the committee's papers, chase reviewers who have gone quiet, and write up the decision at the end.

I designed two assistants for that work, one for the proposal pipeline and one for the review governance. Both open on concrete starting tasks rather than an empty box. Show what is active and where it stands. Triage a new proposal. Draft the minutes for the next committee meeting. Name the proposals at risk of missing their deadline.

Give every answer its next action

A status answer that ends in a status is only half useful. Each response carries the actions that follow from it, sending the reminder, generating the minutes, exporting the list, so someone can finish the task in the place where they asked the question.

Scope

This is a prototype populated with sample records. It shows the proposed interface and task flow, not a released system or a measured improvement in review time.

Open on what needs attention

A governance home screen listing overdue items, each with its own action button to remind, generate, or chase, above a row of named skills and the two available agents. — The home screen leads with what has gone overdue, and each row carries the action that answers it. The skills below name the routine jobs in the reviewer's own words.
Source: Capture of the original prototype with demonstration data substituted for the investigator, institution, study code, and indication; 21 September 2026

Results

I designed the Lucid forecasting frontend and ran its exported code locally to check the rest of the workflow.
I designed and built a brand-planning assistant prototype whose answers take the shape of the question, such as a funnel or a side-by-side comparison.
I designed a shared assistant shell, a conference app, and two research-governance assistants with visible sources, citations, and next actions.

Evidence limit

These are prototypes with sample data. They do not show a released application, adoption, model accuracy, or a measured result. No model, simulation, or export service is connected behind the Lucid screens.

Resume and contact

Download resume Bowman.stephen92@gmail.com