[ J.Bradley / Systems ]

Julie Bradley, Product Design Lead (Design Systems) at Zinnia

Connected by design.

I founded and lead Bloom, the multi-brand design system that connects design and engineering across seven brands and 20 teams.

Read the case studies

54.4k component inserts across 6 Figma libraries, week ending Sep 27, 2026.Open to design systems roles.

What I bring to a systems team

Selected work at Zinnia

Zinnia builds insurance technology: admin tools such as Zinnia Live, and consumer portals that insurance carriers run under their own brands. Most of the interface is forms, transaction flows, tables and side sheets, and one feature often ships to several brands at once.

As Bloom's dedicated design systems lead, I partner with product teams and front-end engineering to prioritize shared improvements as the system scales. These three cases are three views of that work. Bloom is still growing, so each one ends with what comes next.

731
Figma variables, in 12 collections
117
components in the Global Elements Figma library
47
components in Bloom's React code library
19
components with their own color token group

Case 01: One token set, seven brands

I designed Bloom's three-tier token architecture so one component library can carry seven brands, and a new carrier becomes a theme rather than a fork.

Scale
7 brand themes (Zinnia and 6 carriers) on one variable set
Theme overrides
Most carrier themes change fewer than 40 of 731 variables
Most customized
106 of 731 variables, for the heaviest carrier theme
Role
Founder and design systems lead
Collaborators
Front-end engineering, product designers, product managers
Scope
Foundations, tokens, Figma component libraries

The challenge

Zinnia grew through acquisitions: SE2, life.io, Breathe Life and Convergent became one company in 2022, and Policygenius joined in 2023. Their products arrived with no white-labeled design system and no design tokens, so every new brand meant overriding styles by hand, and every override became drift that engineering had to maintain.

Evidence: the Zinnia theme, from its Figma variables

Three token chains, core to component
CoreBaseComponent
color-900-graysurface-darkerBase · Surfacebutton-primary-default-fillButton · Primary
color-whitetext-lightBase · Textbutton-primary-default-textButton · Primary
color-secondaryselected-fill-altStates · Selectedtoggle-selected-fillToggle
Core raw values, hidden from pickers
TokenValue
color-primary#FF7500
color-primary-lightest#FFEAD9
color-primary-dark#994600
color-secondary#00628B
color-secondary-lightest#D9E7EE
color-accent-one#FFC600
color-900-gray#212121
Base roles that point to core
TokenPoints to
surface-primarycolor-white
surface-darkercolor-900-gray
border-primary-colorcolor-primary
border-secondary-colorcolor-secondary
text-primarycolor-900-grayT
text-lightcolor-whiteT
text-linkcolor-global-linkT
Values and aliases from the Zinnia mode of Bloom's variable export. Swatches show what each base role does: fill, border or text.

Key decisions

  1. Three tiers, one directionCore colors feed base tokens, and base tokens feed component tokens; type, spacing and radius follow the same pattern. No component token holds a raw hex value. The intended path is Core → Base → Component: 96 of 130 component color tokens follow it today, and 34 legacy tokens, set up before the base tier existed, still point straight at core.Trade-off: more tokens to name up front, in exchange for brand changes that live in the variables, not the components.
  2. Name by intent, not appearancebutton-primary-default-fill, not color-900-gray. Intent names survive rebrands and give designers, engineers and AI-assisted tools the same vocabulary.Trade-off: a naming guide alone didn't stop drift without oversight. Renames are breaking changes, so each corrected version ships beside the old one until the old one is deprecated.
  3. Keep the core layer out of reachBrand core colors and raw type and space values are hidden from Figma's pickers, so teams apply base and component tokens, and a carrier's palette changes in one place. Only an extended palette for charts and illustrations stays in reach.Trade-off: when a design needs a shade with no base token, the answer is a new base token rather than a quick pick.

Outcomes to date

Completed
A shared visual language, the tiered token architecture, and Figma component libraries for desktop and mobile web. The code library ships a default theme plus six carrier themes, switched with one attribute, and adding a carrier is a scripted step.
In use
Product teams and business units building for Zinnia, Security Benefit, Everly and four more carrier brands.
Next
Re-point the 34 legacy component tokens to base tokens, now that the Figma variable sync runs again (Case 02).
Explore the architecture and token examples

How the system is built

Bloom began as a component library and grew into the design system for the whole of Zinnia. I built the foundations first: typography, color and iconography as one visual language. On top of that I set up the tiered token architecture, and built the component libraries so components consume base tokens wherever a base role exists. The libraries cover two ranges: Zinnia Live is built for desktop widths from 500px to 1140px and up, and the consumer product supports phones down to 360px.

In numbers: 731 variables in 12 collections, 609 published to teams and 122 hidden primitives. 125 core colors feed 109 base tokens and 130 component tokens across 19 components, and 223 of those 239 color tokens carry a usage note. Type runs on 48 styles, spacing on a 4px scale, and layout on five breakpoints from 360px. Each carrier theme swaps 14 to 20 core colors and re-points only the base and component tokens its brand needs.

One component's tokens: the primary button

Zinnia primary button: the base token each state's fill and text point to
StateFillTextRendered
Defaultsurface-darkertext-light
Hoversurface-primarytext-primary
Pressedsurface-quaternarytext-primary
Selectedsurface-tertiarytext-primary
Each state is a component token, button-primary-{state}-fill and -text, pointing to a base role. The border stays border-darker in every state. The samples are rendered in HTML from Zinnia's token values.

Case 02: Realigning Figma and code

With front-end engineering, I'm bringing Figma and code back into step after drift built up across repos, and helping set the shared process that keeps them aligned.

Audit
Every component mapped across the Figma library, the Bloom repo and Zinnia Live
Token sync
Figma-to-code variable sync running again, Sep 2026
Review
Drift fixes ship as pull requests through engineering's review
Role
Design systems lead
Collaborators
A front-end engineer on Bloom; the Experience Design team of PMs, engineers and designers
Scope
Figma library, Bloom repo, handoff workflow, documentation

The challenge

Every component lives twice: in the Figma library designers use, and in the code engineers ship. Zinnia Live was built before Bloom existed, and in its main app roughly three in four local components that match something Bloom ships were rebuilt instead of reused, including side sheets, selects and labels. With teams from several merged companies building in different ways, and no shared governance across repos, names, variants and formatting drifted away from Figma.

Evidence: Bloom's Button, Figma to code

  1. Icondocument-search, from the Bloom set
  2. LabelButton text, centered
  3. Focus ring
    Size
    281 × 52
    Color
    focus-border #007DBC
    Weight
    stroke-sm 2
    Radius
    button-default-radius 1000
Button: each Figma property and the code prop it maps to
Figma propertyCode propValues
Variantmode Names differPrimary, Secondary, Contrast, Destruction, Tertiary link, Tertiary link contrast
SizesizeSmall, Large
TextchildrenThe button label
Show icon, Icon L, Icon RiconType, iconPositionAn icon from the Bloom set, placed at the start or end
State, Tab focusNoneFigma shows hover, pressed, loading and the focus ring so designers can spec them
The anatomy is redrawn in HTML from the Figma spec's values. The mapping is Bloom's global button as linked in Code Connect (Figma's link from a design component to its code): the Figma component maps to Button.tsx. Not every difference is drift; Text becoming children is how React works. Variant and mode is the kind of difference the audit reviews.

One mismatch, traced

Mismatch
Figma's key-value-pair and input-field-general are FieldData and FieldDataActive in code.
Correction
The last audit renamed the Figma components to shared naming conventions. Code is adding versions that match, and the old names stay until they're deprecated, so nothing breaks for teams using them.
Status
In progress across teams. Key-value pair exists only in Figma so far; it isn't in the Bloom code library yet.

Key decisions

  1. Design joins estimationFeasibility trade-offs get made before a spec is final, not after it's built.Trade-off: more of my time in sprint rituals, less rework later.
  2. Agree on a name once, then record itWhen a Figma property and a code prop differ, the question is whether the difference is intended or drift. For drift, the Figma master name wins: the corrected version ships alongside the old one, which is then deprecated, and Code Connect records the mapping.Trade-off: renames cost engineering time, so they're grouped into batched fix tickets instead of one-line releases.
  3. Docs structured for people and toolsEvery Global Elements component is documented in Figma in the same seven parts: principles, interaction rules, usage, content, behavior, accessibility and anatomy.Trade-off: stricter templates, in exchange for consistent context wherever the docs are read, including AI-assisted implementation.

Outcomes to date

Completed
A structured Jira workflow for system work, design in sprint estimation, a dedicated cross-functional channel, the component audit, and a working Figma variable sync.
In progress
Pull requests that fix visual drift, add documentation and link components with Code Connect, and migrating Zinnia Live's duplicates into Bloom, most used first (Case 03).
Next
Re-point the 34 legacy token aliases, and decide whether the sync runs on every Figma change, on a schedule, or on demand.
Explore the audit and migration workflow

The audit and the workflow

I made design-to-code alignment a standing workflow: system work goes into Jira as structured tickets, I join sprint estimation with front-end engineering, and a dedicated channel handles feasibility questions.

To find the drift, I built an audit in FigJam that maps every component across the Bloom Figma library, the Bloom repo and the Zinnia Live monorepo, with its Code Connect status and the fixes it needs. The engineer I work with moved it into Confluence so both teams can track it. Using Claude, the Figma MCP server and engineering's own coding guidelines, I submit pull requests through engineering's review process that fix visual drift, add documentation and link each component to Figma with Code Connect.

The variables had drifted too. The 34 legacy component tokens were set up before the base tier existed. Re-pointing them caused breaking changes through Supernova, the old export tool, and once it was retired there was no working sync, so the aliases stayed frozen. The sync that replaced it had stopped working; I got it running again, so they can now be corrected.

Designers can already prototype in code with Bloom, but most of the components they need still live in the Zinnia Live monorepo, which is mid-audit: each component is aligned, migrated into Bloom or deprecated, sprint by sprint. The larger aim, shared with the Experience Design team, is one agreed process for how products get built, so design and code stop drifting apart.

How a token change ships

  1. FigmaVariables are the design source of truth
  2. SyncA script reads the variables through Figma's API and writes CSS tokens
  3. Pull requestOpened automatically for review
  4. ChromaticVisual snapshots run on every pull request
  5. ReleaseA merge publishes a new versioned package
For now the sync runs when someone triggers it. Whether it should run on every Figma change or on a schedule is an open decision until Figma and code are fully realigned.

Case 03: Scaling adoption across 20 teams

Twenty teams build with Bloom's Figma libraries. I'm scaling that through onboarding, clear on-system rules and priorities set by usage, while production code catches up through migration.

Figma reach
20 teams use Bloom Foundations
Snapshot
54.4k component inserts across 6 libraries, week ending Sep 27, 2026
Onboarding
A Bloom workshop for every new hire
Role
Design systems lead, also covering design ops
Collaborators
Designers, engineers and product managers across product teams
Scope
Onboarding, governance, usage, accessibility standards

The challenge

Adoption has two layers. In Figma, all 20 teams build on Bloom Foundations. In production code it's uneven: much of Zinnia Live predates Bloom and is migrating sprint by sprint. This year Bloom has no dedicated product manager or formal roadmap, and its engineering partner also carries product work, so every shared improvement has to earn its place.

Evidence: Figma library analytics

  1. OnboardWorkshops set shared practices
  2. SupportOn-demand guidance as teams integrate
  3. MeasureUsage analytics and team feedback
  4. EvolveAudits reshape components and docs
Bloom's Figma libraries, week ending Sep 27, 2026
LibraryComponentsTeamsInserts that week
Bloom Foundations6222015.5k
Bloom Global Elements1171736.2k
Zinnia Live72132.6k
Zinnia Live one-offs261181
Consumer product library44936
Consumer product one-offs550
A one-week snapshot, not a weekly average. Foundations feeds every other library, so its 20 teams are the total reach, not a sum of the rows; its 622 components are mostly content and carrier icons. These numbers describe design-library use. Code adoption is tracked separately, in the migration audit.

Usage setting priorities

The migration audit counts how often Zinnia Live's main app uses each of its local copies of Bloom components. The most-used copies move to Bloom first, so shared fixes reach the widest use soonest:

  1. Side sheet
  2. Select
  3. Card
  4. Checkbox

Key decisions

  1. Onboard every new hire, then support on demandEach new hire gets a Bloom workshop. After that, I support teams as they integrate components and join cross-team alignment calls as they come up.Trade-off: teams run on different rhythms, so a regular workshop series hasn't fit yet, and ongoing support depends on people asking.
  2. Clear on-system and one-off rulesA pattern that recurs across products becomes a system candidate; one-offs stay local. A one-off that needs to be modular for prototyping, or may be reused later, becomes a “snowflake”: a component kept in its product's one-off library.Trade-off: some teams wait longer for a shared version.
  3. Prioritize by usageFixes and migrations are ranked by how widely a component is used, so shared improvements go where drift costs most.Trade-off: few new components ship while existing ones are fixed and migrated.

Outcomes to date

Completed
New-hire workshops, self-serve documentation, a one-off library for each product, and an accessibility section in every Global Elements component's Figma docs.
In progress
Migrating Zinnia Live's duplicates into Bloom, and a Storybook cleanup in which engineering drafts usage pages and design reviews the guidance.
Planned
An automated accessibility check in CI, first as a warning, then as a gate that fails the build.
Explore onboarding and accessibility practices

Onboarding and support

I ran onboarding workshops to set shared practices, then moved to direct, on-demand guidance as teams brought components into their work. Alongside that I built self-serve documentation, and I audit the system using usage analytics and feedback from designers and engineers.

Accessibility: documented, implemented, planned

Documented
Each Global Elements component's Figma docs include an accessibility section, with WCAG 2.1 AA as Bloom's documented standard.
Implemented
Bloom's complex React components build on accessible primitives from Radix UI and React Aria.
Planned
An automated check in CI through the Storybook cleanup. Automated tools catch only part of what WCAG covers, so the check will add to the documented guidance, not replace it.

Experience

  1. Jul 2025 – present

    Product Design Lead (Design Systems)

    Zinnia (formerly SE2)

    • Lead and grow Bloom, a scalable component library used by 20 product teams, the majority of Zinnia's product organization, across 6 Figma libraries and a React library.
    • Own the visual foundations: a three-tier token architecture of 731 Figma variables for color, typography, spacing, radius and breakpoints, with brand modes so a new client brand is a theme, not a fork.
    • Define interaction patterns across components: interactive states, focus and keyboard behavior, form validation, and feedback patterns such as alerts and banners.
    • Created and enforce documentation and governance standards: a per-component doc template, a naming guide, a contribution model that assesses each request for reuse, and design QA before release.
    • Partner with front-end engineering on design-to-code fidelity and a shared component vocabulary, linking Figma to code with Code Connect and shipping component fixes as pull requests.
    • Drive adoption through education, tooling and partnership: new-hire workshops, self-serve Figma resources, AI-ready docs, the token pipeline, and training teams to prototype with the Bloom repo.
    • Made WCAG 2.1 AA the documented standard for every core component, with accessible primitives (Radix UI, React Aria) behind complex components.
    • Scale Bloom with Zinnia's growing product suite: new brands onboard as themes, breakpoint tokens span 360px mobile to wide desktop, and acquired products migrate by usage priority.
    • Building an agentic prototyping workflow on Bloom: prompt-to-prototype already works, and current work makes generated prototypes follow Bloom's tokens, styling and component rules.
  2. Apr 2022 – Jul 2025

    Senior Product Designer (Design Systems)

    Zinnia (formerly SE2)

    • Founded Bloom after four companies merged into Zinnia with no shared design system or tokens: visual foundations, token architecture and the first component libraries.
    • Designed multi-brand tokens so one component library serves client brands across admin (desktop web) and consumer (responsive to 360px) products.
    • Built the first Figma libraries, documentation and onboarding workshops, the base for self-serve adoption.
    • Promoted to Product Design Lead (Design Systems) in July 2025 for building and scaling the system.

Earlier systems and accessibility work

  • Basis Technologies (formerly Centro) · Senior UI Designer (contract, intermittent) · 2021–23Built pattern library building blocks for company-wide use, and redesigned site UI for accessibility and a full company rebrand to WCAG standards.
  • Merkle (dentsu) · Senior UI/UX Designer · 2021–22For the National Car Rental mobile app, facilitated user research and usability testing and created journey maps, prototypes and interaction models; for Vanguard IIG, designed customer dashboard experiences.
  • Family Reach · UI Designer · 2021Expanded the design system with content components and responsive page templates to WCAG standards.
  • Westgate Resorts · Visual Designer · 2019–21Designed responsive landing page UI and campaign style guides, and audited every page and asset for brand consistency and accessibility.

Let's talk systems

I'm looking for a senior design systems role where craft, architecture and engineering partnership all matter. I'm happy to walk through any of this work in more depth.

Why “veenaviera”? It's the name I've designed under since I was young, and the studio name behind my freelance branding work from 2018 to 2023.

Message me on LinkedIn