Skip to main content

AstraZenecaPart 4 of 5

Design foundations and the engineering handoff

I built shared design foundations and components so engineers could build their own Workbench screens. Then I handed over the behavior, the version, and the limits of what the prototypes proved.

Contribution
Product design, business analysis, and prototype implementation
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

Build the shared design foundations

Give engineers a reference by the next morning

Engineers needed a component reference by the following morning so they could build their own workflow screens without asking me to adjust each element.

I made a standalone HTML reference that opened directly and printed to PDF. Labels, state variants, and style references sat beside the components, followed by workflow examples. That met the agreed format without adding Storybook or another application route under the deadline.

On July 2, one engineer reported integrating my shared UI package into the budgeting work. Another confirmed receiving the UI-element reference and using it in his own environment. I explained the shared styles and the cards specific to each workflow. Backend connections were separate from this UI integration.

Shared HTML references could lose their linked assets. Teams also worked in different environments and needed components they could reuse in code. I began collecting styles, tokens, components, assets, and guidance into a separate system, and raised the need for engineering support.

Specify component states as well as appearance

The foundations covered color balance, typography, spacing, grids, elevation, iconography, and voice. For dense application screens, I worked through small-text legibility and the treatment of status, hover, and focus.

Fields needed labels, helper text, and validation. Cards needed different levels of emphasis. AI workflows needed states for queued work, progress, failure, sources, and decisions requiring a person. I worked on what those states meant as well as how they looked.

Evidence planning reused the study-governance code's definition of routine steps and human decisions. That gave the two workflows a shared model for those steps.

Foundations, components, and review patterns

View original
Brand foundations sheet with a colour-balance chart, a table of approved contrast pairs, seven icons, voice do-and-don't lists with a sample sentence, three expressive type techniques, three panel-grid examples, and four elevation steps.

Colour balance, contrast pairs, typography, and layout rules turn the public brand guidance into usable reference cards. These cards are reconstructed, not engagement artifacts.

Source: Retrospective design exploration; newly authored portfolio rendering of a design-system reconstruction based on the public AstraZeneca brand guidelines

View original
Component library sheet in three groups: brand primitives (buttons, badges, eyebrow with stat callout, stat spotlight), product utilities (alerts, cards, form fields, status chips, header bar, shimmer, code block), and evidence and agent patterns (citation chip with unsourced badge, confirmation cards, task pills, agent avatars, message bubbles).

The reconstructed library shows brand primitives, product controls, and evidence and agent patterns together. The sample content is illustrative; the export warning is not a claim that the commissioned prototype enforced release controls.

Source: Retrospective design exploration; newly authored portfolio rendering of a design-system reconstruction based on the public AstraZeneca brand guidelines

View original
Component sheet showing inline citation markers, an unsourced-claim badge, four agent avatars, a pending and a cancelled confirmation card, task pills, status chips, a two-message review conversation with accept, change, and escalate actions, two alerts, and classification badges.

Evidence and review components rendered from the reconstructed system's component bundle: citation chips, an unsourced-claim badge, a confirm-before-commit card, task and source states, and review actions. The sample copy is illustrative. The image shows the pattern family described above, not a screen from the product.

Source: Retrospective design exploration; newly authored portfolio rendering of a design-system reconstruction based on the public AstraZeneca brand guidelines

Interaction guidance beside the control

View original
Composer documentation with a labelled evidence-assistant input, visible keyboard focus, Enter and Shift+Enter guidance, a Send button, and descriptions of empty, ready, and pending states.

The composer places its label, keyboard behavior, and state guidance together. The entered prompt is a generic review example. Sending it cleared the local input; no model response or persistent pending state was verified.

Source: Retrospective design exploration; Figma Make documentation specimen, version 29; captured 18 September 2026; header and navigation excluded

View original
Evidence-status specimen distinguishes verified evidence, partial support, contradicting evidence, and unsourced claims with text labels, illustrative counts, and explanations.

Missing evidence, partial support, and a conflicting source call for different review decisions. These specimen labels and counts illustrate that vocabulary; they do not prove automated verification or capabilities of the commissioned content workflow.

Source: Retrospective design exploration; Figma Make documentation specimen, version 29; captured 18 September 2026; header and navigation excluded

The page examples applied the same foundations differently. A corporate page could use expressive typography and large brand panels. A work queue needed room for records, filters, and persistent actions.

Apply the foundations to page layouts

View original
Three page kits: a corporate site with navigation and a Mulberry hero panel beside an imagery panel, a dashboard with KPI cards, a bar chart and an assistant conversation, and a trial-finder portal with a dark sidebar, a stat strip, phase filters and a trial record card.

The corporate site, dashboard and trial-portal kits from the reconstruction, rendered from their page sources. They are representative layouts, not copies of any live site or product; compound names, identifiers, counts and people are invented, and logos are removed.

Source: Retrospective design exploration; newly authored portfolio rendering of a design-system reconstruction based on the public AstraZeneca brand guidelines

Define when a component is ready to share

A component needed an owner, documented states, shared style mappings, accessibility requirements, and verification before it could become a shared control. Product-specific examples could remain references until they met those requirements. The charter named me as the local design-system lead. The broader governance roles were still unstaffed.

The defect record documents keyboard repairs to custom radio controls. Tab entered the group once, arrow keys moved between choices, and Home and End reached the endpoints. The recorded component checks covered those behaviors; one integration received only source inspection because dependencies were missing. Overall accessibility remained unverified.

Check where shared tokens are used

A later documentation prototype applied a generated card-background token from the shared styles. Other parts still used local values. Its code confirmed partial reuse.

The earlier token design named JSON as its source. The later generator read base values from CSS and produced CSS, JSON, and Tailwind outputs. Builders needed guidance for the version they were using.

Shared tokens

View original
Token sheet with ten AstraZeneca colour swatches and hex values, a list of semantic aliases mapped to primitives, a spacing scale, radii, a Roboto Slab and Inter type scale, and four status tones.

A token sheet rendered from a reconstructed design system: core colour primitives, the semantic aliases that map them to interface intent, the type scale, spacing, radii, and status tones. The values follow the public brand guidelines. The sheet does not reproduce the engagement repository.

Source: Retrospective design exploration; newly authored portfolio rendering of a design-system reconstruction based on the public AstraZeneca brand guidelines

One value, from brand to interface

  1. Brand value

    White, #ffffff, supplies the base value.

  2. Semantic role

    semantic.light.color.surface assigns it to a light-theme surface.

  3. Component token

    component.card.light.background references that surface role and generates --component-card-background.

  4. Consuming interface

    The documentation prototype maps the generated variable to --card, then uses bg-card on its journal cards.

Trace the value to a consumer

View originalA white base value becomes a light-theme surface role and a card-background token used by journal cards in a documentation prototype.

A shared surface value reaches journal cards in a documentation prototype. Other interface values remained local. The consumer sketch is explanatory, not an original screenshot.

Source: Newly authored portfolio diagram explaining the existing case-study narrative; retrospective design exploration, not an original engagement artifact

Check the exported presentation

The system included title, section, comparison, process, and content layouts for the presentations produced by the medical-content workflow. Exports needed to retain typography, spacing, color, and sources. The export tooling generated its color map from the shared tokens.

In July, images and the wordmark appeared in the browser preview but disappeared from PowerPoint. The exporter was not drawing them. The issue records the repair and a comparison in PowerPoint that also caught incorrect closing-slide text.

The downloaded file needed its own checks for layout, editability, sources, and accessibility. The archive also contains a brand linter and guidance for coding agents. Their presence does not show that every delivery team used them.

Presentation layouts and export tooling

View original
Contact sheet of twelve slide layouts including a title slide, a Mulberry title slide, a section divider with imagery, a key statement, title-and-content, two- and three-column layouts, a two-thirds split, a lens image, a Mulberry content slide, a four-column process and a three-step cycle, with seven line icons below.

Twelve of the thirty-seven master layouts from the reconstruction, with the seven-icon set at 1.75px stroke. Slide copy is placeholder text and logo placeholders are removed.

Source: Retrospective design exploration; newly authored portfolio rendering of a design-system reconstruction based on the public AstraZeneca brand guidelines

View original
Two slide templates, a title slide with a Mulberry strip and imagery panel and a content slide with numbered citations and a sources box, above a five-step chain from a token file through a generator and TypeScript colour map to the presentation export and a drift check.

Two slide layouts rendered from the reconstructed master templates, with sources listed per slide, above the export chain described in the archived repository: one token file, a generator, a TypeScript colour map for the export code, and a check that fails when the map drifts. The slide text uses neutral layout examples and invented reference labels.

Source: Retrospective design exploration; newly authored portfolio rendering of a design-system reconstruction based on the public AstraZeneca brand guidelines

View original
Four numbered rungs. Rung one, the guidelines PDF, 201 pages covering colour, type, grids and voice, labelled advisory. Rung two, tokens, one CSS source generating DTCG, themes and a Tailwind preset, labelled consumable. Rung three, the linter, nine rules with severities, a disable hatch and a non-zero exit that fails the build, labelled enforced. Rung four, the agent skill, a silent pre-flight and critique mode, labelled in-loop. A strip below reads advisory, consumable, enforced, in-loop.

The same rules at four levels of force, ending with checks that run inside the loop that would otherwise break them. The figure is redrawn in a fictional palette, distinct from the AstraZeneca reconstruction used elsewhere in this chapter. The counts describe archived artifacts; no adoption, saving, or compliance rate is claimed.

Source: Retrospective design exploration; newly authored portfolio figure redrawn from the archived design-system artifacts, rendered with a fictional palette

View original
Three columns beneath a quotation that the downloaded presentation was nowhere near an AstraZeneca slide next to the prototype it came from. Left, what the checks reported, in green ticks: export unit tests passing against a mocked library, a browser preview at full brand fidelity, and an export button that produced a file, closing with the line nothing flagged a problem. Middle, what the file contained, in red crosses: no image drawn anywhere, cover, divider and closing slides falling back to flat colour, no logo on the cover, and a hardcoded closing title, closing with two differences visible at a glance. Right, what actually caught it: building a deck through the real interface and opening the download in PowerPoint, making that an acceptance criterion, and inspecting the package rather than the picture.

Three separate checks reported success while the exported file was still missing its photography and its logo, because each had been run on something other than the file. The unit tests asserted against a mocked export library; they checked the export calls without verifying the file's appearance. The reporter is unnamed and the quotation abridged.

Source: Retrospective design exploration; newly authored portfolio reconstruction of a single documented defect and its recorded resolution, rendered with the reconstructed design-system components

The deck, turned into a filterable library

View original
A toolbox panel with tabs for skills, prompts, templates, and connections. The templates tab shows a search field, category filters counting thirty-nine templates, and branded slide cards each listing its construction, source folder, and a use-template action.

The brand slide deck became a filterable library, with each template naming the parts it is built from and the folder it came from. The same set feeds a person picking a slide and an assistant asked to draft one.

Source: Original Workbench reference; template names and descriptions are the live set, and the thumbnails show the templates' own placeholder copy

Hand off the behavior and its limits

Identify the version being handed over

At the July handoff, the local HTML demo, React application, and backend automation were separate pieces. The team needed to agree which UI version to show alongside the backend demonstration.

Later, stakeholders saw a version missing source-review controls from my shared prototype. We traced the mismatch to version integration. The handoff needed to specify which behaviors worked and which connections were still missing.

The expanded package separated core controls, product-specific examples, slide components, supporting code, and design guidance. It supplied source for integration, not a runnable application. Engineers still needed to set up library tooling, integrate the components, and restore tests tied to the original environment. July's confirmed receipt does not establish receipt or adoption of this later package.

Versions and acceptance checks

View original
A handoff table with eight behaviours as rows and three columns: my working prototype, the version shown to stakeholders, and what is still to connect. Each cell carries a status chip such as works, simulated, missing, not verified or not needed.

The handoff format that separated the interface I had built from the version stakeholders saw and the services still to connect. Rows are illustrative; the mismatch it resolved was about version integration, not missing design work.

Source: Retrospective design exploration; newly authored portfolio reconstruction with invented records, rendered with the reconstructed design-system components

View original
Two acceptance-criteria panels. Left, the authoring interface: keyboard-reachable review actions, visible focus on the citation marker, source status announced as text, and the evidence-gap count in the page title and a live region. Right, the exported presentation: reading order follows the layout, alternative text on every image and chart, contrast on every panel, and sources that survive as text. Each item is marked required.

The accessibility handoff kept two lists: what the authoring interface had to do, and what the exported presentation had to do on its own. Criteria are illustrative; these were documented requirements, not a claim that every output passed them.

Source: Retrospective design exploration; newly authored portfolio reconstruction with invented records, rendered with the reconstructed design-system components

Two gates, stated in the interface

View original
A storyline gate card titled confirm the storyline before build, listing six proposed slides with a layout description each, above approve storyline and build and revise storyline buttons.

The gate names every slide and its layout before anything is generated, and offers only two exits: approve, or send it back.

Source: Original Slide Builder prototype, storyline gate card; invented deck content

View original
A three-column board showing a slide under review with two pending claims, the same slide after a reviewer requests changes on one claim, and the approved slide where both claims carry a citation. The export button is greyed in the first two and active in the third.

Export is tied to claim-level decisions, not to the draft being finished. Only an explicit approval, recorded with who and when, turns the control on.

Source: Reconstructed board built from the prototype with invented claims and sources; reviewer decisions were simulated prototype state, not a connected approval service

The prompts carried the constraints

Several later prototype explorations were built and revised in Figma Make. I treated each request as a small specification: it named the accessibility rule, the design-system token, or the exact control state a change had to respect. The panels below record three of those exchanges, request and response together.

Requests and the changes they report

View original
Conversation panel from a Figma Make editor session. A request to make the sidebar filters collapsible returns a summary listing 44px touch targets from the accessibility guidelines, typography and motion from design-system tokens, and the open and collapsed filter states.

A request to make the search filters collapsible comes back with its own constraint list: 44px touch targets from the accessibility guidelines, typography from the design system's tokens, and motion durations from the same tokens. The summary is the tool's report of its changes, not a verification that every screen complied.

Source: Original Figma Make editor session, iCH Content Engine (Copy) version 166; captured 19 September 2026

View original
Conversation panel from a Figma Make editor session. A request to remove two filters is answered with what was removed and where the remaining filter moved, above an earlier exchange about removing See more buttons.

A correction loop. Two filters were asked for removal, and the reply describes exactly what changed and where the remaining filter moved. The panel records the tool's response; it does not independently verify the resulting interface.

Source: Original Figma Make editor session, iCH Content Engine version 254; captured 19 September 2026; editor excerpt with conversation and partial application preview

View original
Conversation panel from a Figma Make editor session. A completion summary lists design-system standards: CSS variables with no hardcoded values, one typography family, AA color contrast, keyboard navigation with focus indicators, and animations using token durations.

A completion summary from the SharePoint prototype lists the standards it held itself to: CSS variables only, a single typography family, AA contrast, keyboard navigation, and motion from token durations. These are the prototype's own claims about its output, not an audit of the result.

Source: Original Figma Make editor session, Pink Pulse version 54; captured 19 September 2026

Results

  • The design-system work produced shared foundations, components, presentation material, and integration guidance. A documentation prototype used part of the archived token distribution.
  • I supplied material that engineers confirmed receiving and integrating.

Evidence limit

Shared tokens were only partly reused in the code I reviewed. Accessibility conformance remains unverified.

Resume and contact