Overview
FieldView had accumulated several design libraries and systems, built at different points in the product's evolution. Some were partially deprecated, others had no active maintenance, and each working group used its own components and criteria.
As the Design Engineer responsible for Foundry, FieldView's design system, I worked alongside the Design System Lead to audit that ecosystem, consolidate its foundations, and build a single reference for designers and developers.
The result is an infrastructure made of component libraries, design tokens, iconography, technical documentation in Storybook, and a Figma plugin built to analyse how much of the system each file actually uses.
Role & Tools
Role & Tools
- Design Engineer / Design Systems Designer
- Audited the existing library ecosystem across products
- Defined the system architecture: tokens, components, icons
- Designed components, variants, states and properties
- Wrote and maintained the technical documentation in Storybook
- Built the Figma plugin that measures adoption per file
- Ran the feedback loop with designers and developers
Tools
- Figma (libraries, components, tokens, icons)
- Figma Plugin API + TypeScript (adoption tooling)
- Storybook (technical documentation)
- Adoption surveys and interviews with product groups
Team
Core problem
As FieldView grew, different teams built their own libraries, components and interface solutions. That let each team move independently, but it fragmented the platform: several design systems coexisted inside the same organisation, some libraries were deprecated or unmaintained, and designers on different teams used similar components that behaved differently.
There was often no correspondence between the components in Figma and the ones actually implemented, developers had no single source of documentation, and it was hard to know the real level of adoption. Problems surfaced through isolated conversations rather than structured information.
The challenge was not simply to build another library. We had to understand the existing ecosystem, decide what to keep, what to migrate, and how to get teams to adopt a shared solution.
Constraints
- Foundry could not become just one more library — it had to consolidate what already existed rather than add to the pile.
- Teams had to keep shipping, so migration needed to be progressive rather than a hard cutover.
- Adoption could not be mandated; the system had to earn its use by covering real needs.
- Adoption metrics could only come from what we could actually observe, not from self-reporting.
Solution
We built Foundry as three separate libraries plus a documentation layer and a tool to measure its own adoption.
- Foundry Tokens centralises the foundational decisions — colour, typography, spacing, borders, radii, elevations, visual hierarchy and semantic values. Separating tokens from components gave us a more scalable base and cut down on stray one-off values inside designs.
- Foundry Components holds the reusable elements, each worked through for purpose, anatomy, variants, properties, states, behaviours, use cases, composition rules, scalability and correspondence with code. The goal was not to cover every conceivable scenario, but to be flexible enough for real needs without losing consistency.
- Foundry Icons keeps iconography in its own library, so teams stop shipping different versions of the same icon and updates land in one place.
- Storybook documents each component's purpose, anatomy, variants, configurable properties, interactive states, usage rules, expected behaviours and implementation notes — so developers understand not just how a component looks but how it should behave.
- A Figma plugin inspects any file and reports how integrated it is with Foundry, turning adoption from a matter of perception into something observable.
Process
- 01
Audit the existing ecosystem
We started by auditing the libraries and components in use across products and working groups: which libraries each team used, which components were still active, what was deprecated, what development actually maintained, which patterns repeated across products, which solutions did the same job with different behaviour, where design and implementation diverged, and which needs no library covered. That gave us a map of the ecosystem and kept Foundry from becoming yet another parallel library.
- 02
Understand what teams actually need
A design system doesn't work just because its components are well built — it has to answer the needs of the people using it. We ran adoption surveys, talked with designers, met with developers, followed up with each working group, and reviewed real files and use cases. I kept that communication going alongside the Design System Lead and turned the feedback into concrete improvements, which meant Foundry's roadmap started being driven by real needs rather than internal assumptions.
- 03
Build the architecture
To keep the system maintainable we split it into three libraries — Tokens, Components and Icons — each with its own scope and release cadence. Splitting them meant a token change could ship without touching components, and iconography stopped being duplicated inside product files.
- 04
Ship as MVPs
Rather than finishing the whole system before letting anyone use it, we shipped an MVP of the Figma system and an MVP of the Storybook documentation. Designers and developers started using Foundry while it was still evolving, which let us validate component structure, spot missing variants, fix problems before they scaled, improve the docs, catch design–implementation gaps, and prioritise by impact. The system evolved as an internal product, through cycles of implementation, feedback and iteration.
- 05
Connect Figma to Storybook
Documenting Foundry in Storybook built a clear bridge between design and development. Beyond writing the docs, I worked on improving the correspondence between the properties exposed in Figma and the APIs of the implemented components — which reduced ambiguity during handoff and strengthened the collaboration between both disciplines.
- 06
Make adoption observable
Surveys and conversations told us how teams felt, but not what was actually in each file. A designer could believe they were on Foundry while still carrying components from older libraries, detached instances, local styles, manually built elements and patterns that didn't belong to the current system. So I built a Figma plugin that inspects a file and reports how integrated it is: which system resources are in use, which components or styles are external, what's inherited from previous libraries, and where a file contradicts itself. That let us compare projects, spot migration opportunities, prioritise support for teams still on older systems, and assess adoption with far less guesswork.
Results
- Moved from multiple fragmented systems to a single centralised reference.
- Reduced dependence on deprecated and unmaintained libraries.
- Unified visual, functional and interaction criteria across the platform.
- Centralised the platform's design tokens and consolidated iconography into a shared library.
- Improved the correspondence between Figma and code, reducing ambiguity at handoff.
- Gave developers technical documentation in Storybook covering behaviour, not just appearance.
- Built an in-house tool that evaluates adoption file by file, so migration opportunities can be found deliberately instead of by chance.
- Established a systematic feedback loop with the product groups, so the roadmap is prioritised on evidence.
Conclusion
I'm not quoting adoption percentages or time savings here: those still need to be validated against internal data. The verifiable change is structural — an ecosystem that was fragmented and hard to observe is now centralised, documented, and equipped with its own means of evaluation.
Foundry changed how teams design, document, implement and maintain the platform. Designers work from a shared reference, developers can consult components in Storybook, foundational decisions live in tokens, teams reuse solutions instead of rebuilding them, and adoption can be assessed inside each Figma file.
The project reinforced one idea: building components is only part of a design systems designer's job. Making a system work inside an organisation also means understanding each team's context, designing the adoption process, documenting decisions, building internal tooling, measuring real use, and keeping a continuous relationship with designers and developers — treating the system as a product rather than a finished deliverable.
Links