[ J.Bradley / Systems ]

Julie Bradley, Product Design Lead, Design Systems at Zinnia

Connected by design.

I founded Bloom, Zinnia's white-labeled design system, and still run it on my own: one token set for 7 brands, used by 20 teams.

Explore my work

6 Figma libraries, 54.4k component uses a week. Open to design systems roles.

What I bring to a systems team

  • Token and component architecture

    Foundations, token tiers and composable components built to flex across brands, products and screen sizes without forking.

    Case 01: One token set, seven brands

  • Spec-to-code alignment

    Structured handoff, sprint-level partnership with front-end engineering, and docs that people and AI tools can both read.

    Case 02: Realigning Figma and code

  • Adoption and governance

    New-hire onboarding, on-demand support, and audits that put fixes where components are used most.

    Case 03: Adoption with a team of one

  • Accessibility as a documented standard

    Complex components built on accessible primitives, an accessibility section in every component's docs, and an automated CI check on the way.

    Case 03: From documented to automated

Selected work at Zinnia

Case 01: One token set, seven brands

I designed the token architecture that lets one component library serve every white-labeled client brand, so a new brand is a theme, not a fork.

Scale
7 brand themes (Zinnia and 6 carriers) on one set of variables
New brand cost
Most carriers change fewer than 40 of 731 variables
Most customized
106 of 731 variables, for the heaviest carrier theme
Role
Design systems lead, sole owner of Bloom
Partners
Front-end engineering, product design, PM
Scope
Foundations, tokens, component libraries
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
The Zinnia theme, from its Figma variables. 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. Every component token references another token rather than a raw hex value.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. Names survive rebrands and read the same to designers, engineers and AI tools.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 only base and component tokens. A carrier's palette changes in one place, and no screen hard-codes a brand color. 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.

Outcome

Shipped
A shared visual language, a tiered token architecture, component libraries for desktop and mobile web, and usage guidelines.
Used by
Multiple product teams and business units, across Zinnia, Security Benefit, Everly and four more carrier brands.
What changed
Brand work lives in the variables instead of the components, so teams build a feature once and every client gets a consistent version.
Read the full story: One token set, seven brands

Context

Zinnia's products run under many client brands. Shared product teams build each feature once, and it has to feel native to every client that ships it. The design system sits under every product team and business unit in the company.

Problem

Zinnia grew through acquisitions: SE2, life.io, Breathe Life and Convergent became one company in 2022, and Policygenius joined in 2023. That brought together products from several companies, with no white-labeled design system and no design tokens. Without a shared foundation, every new brand meant overriding styles by hand, and every override became drift that engineering had to maintain.

What I did

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 a tiered token architecture and built the component libraries so that 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 carry a usage note. Type runs on 48 styles, spacing on a 4px scale, and layout on five breakpoints from 360px. Each carrier swaps 14 to 20 core colors and re-points only the base and component tokens its brand needs.

Today the code library ships a default theme plus six carrier themes, switched with one attribute, and adding a carrier is a scripted step.

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.
Back to selected work

Case 02: Realigning Figma and code

I'm bringing Figma and code components back into step after drift built up across repos, and helping build the shared process that keeps them there.

Audit
Every component mapped across Figma, Bloom and Zinnia Live
Token sync
Got the broken Figma-to-code variable sync running again
Governance
Drift fixes shipped as reviewed pull requests
Role
Design systems lead
Partners
A front-end engineer, the Experience Design team
Scope
Handoff workflow, Figma library, documentation
  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
Figma propertyCode propValues
VariantmodePrimary, 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
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, and the Figma MCP server turns a selection into <Button mode="primary" size="small">. Every value in the spec is a token. One name still differs: Figma's Variant is mode in code, the kind of drift the audit exists to catch.

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. The Figma master sets the namesWhen code and Figma disagree, code is renamed to match. Renames break consumers, so the corrected version ships alongside the old one, which is then deprecated. Code Connect records each mapping.Trade-off: renames are a hard sell to engineering, so they're grouped into batched fix tickets instead of one-line releases.
  3. Docs written for machines tooEvery Global Elements component is documented in Figma in the same structure: principles, interaction rules, usage, content, behavior, accessibility and anatomy. People and AI tools can both parse it.Trade-off: stricter doc templates, in exchange for predictable AI output.

Outcome

Shipped
A structured Jira workflow for system work, design in sprint estimation, a dedicated cross-functional channel, and self-serve Figma and documentation resources.
Used by
Front-end engineering and designers across Zinnia's product teams.
What changed
Feasibility is settled before build instead of after, and each realigned component now has one name, one spec and one Code Connect link from Figma to code.
Read the full story: Realigning Figma and code

Context

Every Zinnia component lives twice: in the Figma library designers use, and in the code library front-end engineers ship. Multiple product teams depend on both describing exactly the same thing. Zinnia is insurance technology, so most of the UI is forms, transaction flows, tables and side sheets, built from a small set of components used everywhere. On the code side, Bloom is a React library of 47 components with generated CSS tokens and per-carrier themes.

Problem

Without a shared process, drift creeps in. The Zinnia Live platform was built before Bloom existed. In its main app, roughly three in four local components that match something Bloom already ships were rebuilt from scratch instead of using Bloom. They include some of its most-used pieces, such as side sheets, selects and labels.

The names drifted too. In the last audit we renamed two core field components in Figma to match industry conventions: key-value-pair and input-field-general. Code still calls them FieldData and FieldDataActive, and every team is now deprecating the old names in favor of versions that match Figma. With no shared governance across repos, and teams from several merged companies building in different ways, each copy had moved further from Figma in naming, variants and formatting.

What I did

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. I also own the Figma library and its documentation, written so AI design-to-code tools can produce on-system output.

To fix 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, and we work through it by usage: side sheet, select, card and checkbox first. Using Claude, the Figma MCP server and engineering's own coding guidelines, I submit pull requests through their review process that fix visual drift, add documentation and link each component to Figma with Code Connect.

The variables had drifted too. 34 component tokens still point straight at core colors, because they were set up before the base token layer existed. Re-pointing them caused breaking changes through Supernova, and once Supernova was gone there was no working sync, so the aliases stayed frozen. I restored the Figma variable sync to the repo, so they can finally 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 being aligned, migrated or deprecated sprint by sprint. The larger aim, shared with the Experience Design team of product managers, engineers and designers, 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
A Figma API sync replaced Supernova; when it stopped working, I got it running again. For now it 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.
Back to selected work

Case 03: Adoption with a team of one

With no dedicated systems team, I brought Bloom to 20 teams by making it the easiest path and spending scarce hours where usage is highest.

Onboarding
A Bloom workshop for every new hire
Reach
20 teams across 6 libraries
Adoption
54.4k component uses in one week
Role
Design systems and design ops lead
Partners
Designers, engineers, product managers
Scope
Adoption, governance, WCAG 2.1
  1. OnboardWorkshops set shared practices
  2. SupportOn-demand guidance as teams integrate
  3. MeasureUsage analytics and team feedback
  4. EvolveAudits reshape components and docs
LibraryComponentsTeamsUses, one week
Bloom Foundations6222015.5k
Bloom Global Elements1171736.2k
Zinnia Live72132.6k
Zinnia Live one-offs261181
Consumer product library44936
Consumer product one-offs550
Figma analytics, week ending Sep 27, 2026. Foundations feeds every other library, so its 20 teams are the system's total reach; its 622 components are mostly content and carrier icons. One-off libraries hold product-specific components that aren't meant for wide reuse.

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 reach depends on people asking.
  2. Clear on-system vs bespoke rulesA pattern that recurs across products becomes a system candidate. One-offs stay local. If a one-off needs to be modular for prototyping, or might be reused later, it becomes a “snowflake” component in its product's one-off library.Trade-off: some teams wait longer for a shared version.
  3. Spend scarce hours where usage is highestBloom has no dedicated product manager, and its one engineer also carries product work. So the audit ranks fixes by how widely each component is used, and limited time goes where drift costs most.Trade-off: few new components ship; fixing what teams already use comes first.

Outcome

Shipped
Onboarding workshops, self-serve documentation, on-demand support and a continuous audit practice.
Used by
Designers, engineers and PMs across product teams and business units.
What changed
New hires start on Bloom from day one, fixes go where usage is highest, and accessibility is moving from a documented standard to an automated check.
Read the full story: Adoption with a team of one

Context

Zinnia has many product teams and business units, and one person responsible for the design system. Bloom runs without a dedicated product manager, and the engineer I partner with splits time between product work and Bloom. Every hour spent on one team's question is an hour not spent on the system itself.

Problem

A system nobody uses is just a library. With tight resourcing, teams had to choose the system on their own, and leadership needed evidence that it was worth the investment.

What I did

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

Accessibility starts in the foundations. Complex components build on accessible primitives, and every component's Figma documentation has its own accessibility section. The next step is enforcement: the Storybook cleanup adds an automated accessibility check to CI, first as a warning and then as a gate that fails the build.

Back to selected work

Experience

  1. Jul 2025 – present

    Product Design Lead, Design Systems

    Zinnia (formerly SE2)

    • Own strategy, architecture and governance of Bloom, Zinnia's global design system, as its sole owner: visual foundations, tokens, components and documentation.
    • Serve as the primary contact for design system adoption across product teams, giving direct guidance as teams bring components into their work.
    • Run design-to-code alignment with front-end engineering through Jira tickets, sprint estimation and a dedicated cross-functional channel.
    • Lead documentation, tooling strategy and Figma library architecture; set Bloom's accessibility standard: accessible primitives, per-component accessibility docs and an automated check in progress.
  2. Apr 2022 – Jul 2025

    Senior Product Designer, Design Systems

    Zinnia (formerly SE2)

    • Founded and built Bloom, Zinnia's enterprise design system, from the ground up: visual foundations, token architecture and the first component libraries, for a product UI that had been fragmented.
    • Architected early UI patterns and multi-brand design tokens for consistency across product teams, and set accessibility standards in the foundations.
    • Built the first Figma libraries and documentation practices, which became the base for self-serve adoption across the organization.
    • Led early onboarding and workshops to introduce the system and establish adoption across product teams.
    • Promoted to Product Design Lead, Design Systems, in July 2025 for building and scaling the system.

Earlier systems and accessibility work

  • Basis Technologies · UI Designer (contract, intermittent) · 2021–23Designed the information architecture and page-level UI for a full company rebrand, aligned with the new style guide and WCAG standards.
  • Merkle · Senior UI/UX Designer · 2021–22Designed flows, prototypes, interaction models and functional specs for a national mobile app, grounded in usability research.
  • Family Reach · UI Designer · 2021Expanded the design system with content components and responsive templates, optimized to WCAG.
  • Duval County Public Schools · Designer · 2017–18Ran routine accessibility audits across 120+ school websites and created the district brand style guide.

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