Flagship engagement
A request is not access
AstraZeneca
- Contribution
- Product design, interaction systems, and prototype implementation
The content workflow let someone request a missing document and keep moving. How could the next step avoid treating that request as evidence? At AstraZeneca, I designed and built the source-review behavior behind that question, alongside a broader set of supervised AI workflows.
Results
- The business demonstration produced concrete review questions for later prototype work.
- I delivered the working prototype through Git for team integration.
- I used the prototype to onboard additional designers to the journey and its shared patterns.
Evidence limit
This prototype simulated source access, kept state in memory, and did not run a live model. Production release and adoption are unverified.
- Engagement
- August 2025 to August 2026
- Role
- Senior Product Designer & UX Business Analyst, contract
- Case-study focus
- AI assistants, evidence review, and reusable product patterns
- Delivery
- Working prototype and Git handoff
- Audience
- Internal product partners and business stakeholders
Keep the missing source missing
Asking for a document does not make it available
A list of document names was not enough to support a storyline. A content producer needed to know which sources were available, which were missing, and whether the product had retrieved anything. Recording a request for a document did not answer those questions.
I built a recovery path that let people record and retry a missing-source request. The source stayed unavailable until the product could show access. Moving to the next step did not turn the request into evidence.
Carry the source status through the task
I kept source status in the shared journey state. If a document was unavailable, later steps still treated it as unavailable.
Contribution
The source states, recovery behavior, and interface copy followed the same rule. Because the prototype simulated source access, its wording and behavior had to make that distinction clear.
Routing a gap to an expert changed who needed to act, but did not resolve the missing evidence. The prototype kept that gap in its unresolved count. The number of items needing the producer's attention could fall while the number of unresolved gaps stayed the same.
Fix the input before polishing the output
I sent an updated mockup that left out the upload step. It was ready to suggest content before establishing what the person had supplied. I corrected the sequence so manual source input and review came before storyline and slide generation.
In the planning and knowledge prototypes, people could inspect source passages, filter by document, and check details such as ownership and freshness. That gave them a way to examine what an answer was based on, even when the answer itself looked convincing.
Find the source behind the task
Keep review ahead of generation
Give AI a job people can supervise
Several workflows, one shared workspace
At AstraZeneca, I worked on assistant interfaces, planning and knowledge tools, operational workflows, and reusable design materials. Finding a document, preparing a briefing, reviewing a risk, and managing an event each needed a different flow. I wanted sources, progress, and review to behave consistently without forcing every task into the same interface.
Within the AI workbench, the different experiences existed as full prototypes at different points. Medical-content creation and review were part of that evolving workspace, with capabilities and integrations that varied by version.
Working prototypes gave people a way to try the proposed flow and question it. I used those reviews to turn broad requests into decisions about navigation, states, and what belonged in the next version.
Contribution
I combined product design with hands-on prototyping. For the source-review workflow, I owned the interface, shared journey state, recovery behavior, and implementation. I used AI-assisted development during the build.
A shared starting point
Different ways into an assistant task
Help people find the right material
The content work also addressed discovery. A resource-portal concept organized training, updates, and reference material around the information people needed to find. A scientific-content search concept used filters and structured cards to present statements with their metadata and citations.
These concepts dealt with different kinds of reading. Someone looking for a resource needed clear navigation and recognizable categories. Someone assessing a scientific statement needed its source context close enough to examine. Both informed the broader story of making information easier to find and inspect.
Make the plan visible before the work starts
People could choose a task, select sources, and review a proposed plan before starting. They could then follow the steps and inspect the result. Chat provided a starting point, with the work continuing through a visible sequence.
I authored requirements for an earlier assistant concept and explored task-based interaction in a shared workspace and a compact interface built around keyboard use. I also built the unified assistant's Figma-to-React shell, while engineering teammates handled backend integration.
In the unified-assistant review, the team asked me to narrow the interface to capabilities the existing backend could support. Attachment and knowledge-search controls were to stay out until they were available. The chat area also needed to remain stable for integration while navigation evolved around it. This was the agreed direction for that version, with backend integration owned by engineering teammates.
The flow changed through team review. In one planning prototype, I proposed five steps. The team chose a colleague's simpler two-step model, keeping an edit path related to my opening screen. My contribution was part of that revision, not sole authorship of the final flow.
Plan the search before running it
A search-prototype review changed the emphasis from an exploratory chart to helping people find the right material. The team called for clearer category filters and a smaller pilot based on file and folder descriptions. I was asked to refine the interface and help define that approach. Those decisions narrowed the proposed experience; they did not establish a completed search integration.
Start with the questions
Review the direction before the result
The plan appeared before execution, with source selection and progress visible along the way. People could see how the product intended to approach their request before they received a finished answer.
Put judgment into the workflow
What the business review brought out
I demonstrated the early content-review flow to business stakeholders. They wanted to know how a reviewer would distinguish sourced material from generated material, how citations and confidence should work, and how much control they would have over slide layout.
Their questions showed how closely the review depended on the interface. Source handling, output structure, and editing controls determined what someone could understand and challenge before using a result.
In a separate medical-content evaluation discussion, I narrowed the proposed comparison to a single paragraph, its source material, and examples of good and bad prompts. That gave reviewers a specific starting point for comparing the existing process with the prototype. It was an evaluation plan, not a completed result.
In one review prototype, export stayed disabled until an explicit approval decision. A request for changes kept it disabled. The source list and reviewer decisions were simulated prototype state, so this demonstrated the proposed interaction rather than a connected approval service.
Turn policy into behavior people can use
I authored the risk-workflow requirements and supported user acceptance testing, issue triage, stakeholder review, and later-phase scoping. The initial requirements excluded AI and chatbots. I helped turn feedback into rules for roles, approvals, reporting, audit comments, and historical records that the implementation team could work from.
The broader risk-intake prototype work separated a risk's description from its impact, likelihood, owner, and proposed mitigation. Terminology requests had distinct draft, pending-review, approved, and rejected states. Each made the person's responsibility visible in the flow.
Event prototypes covered organizer and attendee tasks. Organizers edited sessions and previewed the event. Attendees explored the schedule and saved interests. Shared interface patterns supported both, but each needed its own controls.
Different tasks need different controls
Attendee and governance explorations
Name the state and the action
A source request, a risk assessment, and a review decision mean different things. I used explicit states and controls to make those differences visible, so people could tell what had happened and what still needed their attention.
Build the patterns and the handoff
Give recurring questions a reusable answer
I presented an early assistant-persona framework, then received feedback that the business profiles overlapped. Extracting information, summarizing it, drafting a narrative, and editing an output were tasks a person could move between. The next iteration was to organize the patterns around those task triggers and connect them to actual projects, while keeping source previews and citations central to evidence-focused work.
The AI interaction-standards work paired written guidance with a reference prototype. It covered input behavior, response states, trust cues, and disclosures. Teams could discuss the behavior in a working interface as well as in a document.
The design-system material translated brand guidance into styling tokens, reusable components, and templates for interfaces and presentations. It documented substitutions and local choices. It was a reference for prototype work, with common foundations that left room for different workflows.
Assistant navigation, source panels, task progress, and review controls recurred across the work. I used the source-review prototype to onboard additional designers, walking through the behavior and shared patterns alongside the screens.
The design-system repository included a generator that read shared color values and produced the TypeScript map used by document-export code. This gave the interface and export paths a shared input instead of relying on separately maintained color lists. The archive establishes implementation work, not organization-wide adoption.
Make shared terminology searchable
Resolve what each version actually contains
Late in the source-review work, "complete" meant different things in different versions. One could have an upload interface while file processing was still unfinished. My working prototype included review steps and source attribution that were absent from the version shown to business stakeholders.
When a product partner reported those features missing, I explained that I had built and shared them. We traced the mismatch to version integration and separated the completed interface work from the connections still to be built. I delivered the working prototype through Git for team integration.
Hand off the behavior with the screens
The handoff needed to explain the flow, its states, and what was implemented. It also needed to identify which interactions worked, which inputs were simulated, and which services still needed connecting. Screens alone could not tell the delivery team all of that.
Lessons from the work
Source access is a state, not a reassuring message
The missing-document flow made the distinction concrete. A request could be recorded successfully while the source remained unavailable. The same status needed to reach source review, storyline preparation, and later steps. Otherwise, a helpful-looking recovery action could hide the evidence gap.
Put review where it can change the next step
Leaving out the upload step made the mockup ready to suggest content before establishing its inputs. Restoring source input and review changed the sequence. A checkpoint is useful when someone can correct the material or direction before the product builds on it.
A simpler team decision can improve the design
The team chose a colleague's two-step planning flow over my five-step proposal and retained an edit path. That decision reminded me to separate the behavior worth preserving from the structure I first proposed. My contribution continued through the revision.
A handoff has to identify the working version
The source-review controls I had built were missing from the version shown to stakeholders. Explaining the design was not enough; we had to identify the version, its implemented behavior, and its remaining connections. Future handoffs should make those differences explicit alongside the screens and code.
Review the artifact that leaves the product
The accessibility handoff separated the authoring interface from the generated presentation. Keyboard access and focus behavior in the interface were one concern; the exported slides needed their own checks. I would carry that distinction into the acceptance criteria for any product that generates a document. These were documented requirements, not a claim that every output passed them.
Engagement timeline
Selected milestones from the project record. Dates describe documented activity; proposed delivery dates and inferred dates are omitted.
August 2025 to August 2026
12 August 2025 · Risk-workflow project notes begin
The earliest dated project-note marker in the supplied record concerns the risk workflow. It is not a verified employment start date.
14 November 2025 · Risk-workflow requirements
I authored the requirements document. Review and approval fields are blank in the surviving copy.
18–22 December 2025 · Event experience and handoff
I reviewed event UX, refined schedule, preference, and navigation behavior, and prepared the Figma and prototype export handoff. The later delivery target remains unverified.
6–19 January 2026 · Assistant patterns and requirements
The work covered persona- and task-based assistant patterns, citations, previews, and reasoning visibility. I authored assistant requirements covering task cards, pre-call information, and modes. These records describe guidance and prototype scope.
18–19 February 2026 · Risk-workflow acceptance testing
I documented testing decisions, actions, terminology, and requirements clarifications with the team. Permission, notification, access, and delivery dependencies remained.
2 March 2026 · Unified assistant shell
I built the Figma-to-React shell while the team narrowed navigation, enterprise search, and answer-level export. Technical teammates owned backend integration.
22 April 2026 · A simpler planning flow
The team selected a technical teammate's two-step flow instead of my five-step proposal, retaining an edit path. The revision reflects shared authorship.
1–7 May 2026 · Focus shifts to the AI workbench
Knowledge, data-query, and analytics examples came together around a shared supervised workflow as the risk-workflow ownership transition began. The review allowed a prototype with incomplete functionality.
9 June 2026 · A bounded content evaluation
I scoped a paragraph-level comparison using source examples and reviewer feedback. This was benchmark setup, with no measured improvement in quality or review time established.
21–31 July 2026 · Slide-building workflow design
Mockup and design tasks used the workbench baseline, source examples, and template constraints. The end-of-month target depended on sources and does not establish accepted delivery.
3–5 August 2026 · Source and storyline review
The work covered a constrained manual-upload proof, evidence and storyline review, and provisional acceptance gates. Local frontend history also records evidence-gap and keyboard-focus changes. These were prototype activities.
25–27 August 2026 · Design coordination and reusable foundations
I discussed source-per-slide information, evidence recovery, and incoming-designer coordination. Local history records review gates and semantic and component token distributions. Integration and formal adoption remained unverified.
31 August 2026 · Local close-out records
Four repositories received local archive snapshots identifying the contract end. These records do not establish completed business acceptance.
Related work
United AirlinesSupporting case study
From thirteen systems to one service task
At IBM iX, I researched how United customer care representatives in Chicago and Houston resolved complaints across thirteen legacy systems. I helped turn that fragmented work into one task-centered dashboard. During the pilot, average throughput rose from two to seven complaint resolutions per hour, and United followed with a rebooking assignment.
- Information architecture
- Interaction design
- Ethnographic research
- Service design
California DHCSSupporting case study
One design system across four DHCS workstreams
MCWeb Portal, OPUS, OLCC, and Provider Portal were moving in parallel while the design team shifted from Adobe XD to Figma. I rebuilt the existing Bootstrap patterns in Figma, checked them with screen readers, and kept review decisions with the screens for weekly cross-team handoffs.
- Design systems
- Accessibility
- Design-tool transition
- Stakeholder coordination