Teaching a web
design system
to speak print.
A shared PDF component library for Operations Center - themed per business unit, rendered via React and Puppeteer, so every team ships reports from one source of truth instead of rebuilding the same header for the fourth time.
MY ROLE
Lead Designer
Design System Designer
TEAM
1 Designer
+ engineering team
TIMELINE
In flight
2025 - Present
SURFACE
3 business units
Ag · C&F · Roadbuilding
THE PROBLEM
Every team was rebuilding reports from scratch.
Without a shared component model, three teams produced three different report styles - same data, same brand, different header on every page.
GOALS & SUCCESS METRIC
What we set out to prove.
FOR THE BUSINESS
Drive adoption of a standardized PDF reporting system across all units.
Eliminate redundant report implementations across engineering and design.
Improve brand consistency and trust through uniform report design.
Lower defect rates related to PDF rendering and layout.
FOR DESIGNERS & DEVELOPERS
A single, trusted source of truth for designers and developers.
Build reports faster with minimal rework.
Reduce decision fatigue through predefined patterns and guidelines.
Reuse components, typography, styles, and layouts tailored for PDFs.
ANATOMY OF A REPORT
Every block is a published componet.
Each report is composed from the same library. Designers drag the components in Figma; engineers import the matching React components from the shared repo. What ships is what was designed.
TECHNOLOGY & WORKFLOW
Process & Workflow
Designers and engineers consume the same components from the same repository so what gets designed in Figma is what ships as a PDF.
DESIGN
Designers drag PDF components from the shared Figma library and publish a spec. The library is the only source of truth.
BUILD
Engineers pull the matching React components from the shared repo, compose the report UI, and render it to HTML with the same CSS the designer reviewed.
RENDER
Headless Chrome (Puppeteer) loads the rendered HTML and generates the final PDF, preserving exact pagination, fonts, and color.
PROJECT HISTORY
How I joined and what I owned
The strongest signal that a system is working is how it survives its first contradictions. Three of the calls that took the longest to make:
PHASE 1
· Bailey led
Discovery & baseline
Audit of existing reports. Initial typography styles, logo, header, footer, and page template established as a baseline.
PHASE 2
· I joined and owned
Header hand-off
I came on as a supporting designer to lead the Header component hand-off. Testing surfaced type-size and spacing gaps between design and dev. After tight design-engineering pairing, we matched the Figma spec with 90% success rate across implementations.
PHASE 1
· I owned
Footer component publishing
Footer published under the ISG Component Library. Figma and repository artifacts kept in sync so every team can pull the same source.
May – Jun
· Current
Typography & artboard lock-in
Locking in typography for PDF reports, validating whether separate type faces are needed, finalizing artboard sizing, and continuing footer testing.
OPEN QUESTIONS
The decisions we argued
These are live trade-offs, how we answer them shapes the system for years.
QUESTION 01
Library Placement & Ownership
Should the PDF Report Library live as a separate, standalone library dedicated to print use-cases? Or should PDF components be integrated into the existing web design system, sharing foundations (tokens, typography, colors) with web components?
Why it matters: Half of past bugs trace back to one-off measurements.
QUESTION 02
Typography system for print
Do we re-use the web type scale, or define a print-specific scale especially to accommodate: Dense, data‑heavy tables & 8pt or smaller text for constrained layouts? Investigating whether separate typefaces are needed for PDF rendering.
Why it matters: The decision impacts readability, as well as how much divergence we allow between print and web and digital experience.
QUESTION 03
Artboard & page-size standard
The current artboard size is not rendering accurately when translated to final PDFs. Nail down the precise artboard size to be used across all reports so designers and developers build against the same canvas from day one.
Why it matters: This affects design fidelity, developer handoff accuracy, and component reuse.
CURRENT EFFORT
What's shipping next.
IN PROGRESS
Nail down typography for PDF reports
Check if separate type faces are needed
Finalize artboard size standard
Continue footer component testing
WHAT THIS UNLOCKS
Faster report delivery across Ag, C&F, and Roadbuilding
One canonical visual language for external-facing PDFs
Fewer cross-team rendering bugs in production
A repeatable handover model for future print artifacts
MY LEARNINGS
What I'm taking from this.
01
Print is a different medium.
Web components don't translate to PDFs without rethinking units, page anatomy, and rendering paths. Treating PDF as a first-class surface, not a web export was the unlock.
02
Parity is earned, not assumed.
Reaching 90% Figma↔dev match required line-by-line testing and embedded design-engineering pairing. The library only works because the spec and the build agree.
03
Ownership is the open question.
The hardest call isn't visual, it's whether print lives inside the web design system or beside it. That decision sets the cost curve for the next five years of reports.
redesign of 140+ equipment icons used across John Deere’s digital ecosystem, replacing toy-like, inconsistent artwork with a precise, scalable system grounded in real product photography.