A living web Design System created for Tokio Marine to make digital products more consistent, accelerate delivery and give designers and developers one shared language for building interfaces.
I worked on the structure and evolution of the web Design System, translating recurring product needs into reusable foundations and components. My work included defining variables and semantic tokens, creating component variants and states, documenting responsive and accessibility behavior, and aligning the library with developers so the same decisions could move more reliably from Figma into production. I also contributed to the governance model that turned Design System compliance into a publication requirement for company web applications.
Interface studyScroll to unpack the thinking ↓
Tokio Marine maintains multiple web experiences serving different audiences and business journeys. The opportunity was to reduce repeated decisions and inconsistencies without limiting product teams. The Design System needed to be flexible enough for varied applications, specific enough to create recognizable standards, and practical enough to support engineering delivery.
Web applications were being designed and delivered across different teams, contexts and technical constraints. Without a shared foundation, familiar interface patterns could be solved repeatedly, visual and interaction decisions could drift, and handoff required extra interpretation between design and engineering.
I helped develop a Figma-based system that connects foundations to implementation: semantic variables, reusable tokens, responsive grids, icons and production-ready components with documented states, variants and usage guidance. The library makes decisions explicit and gives development teams a more predictable reference for implementation.
The system moved beyond being a design library and became part of how Tokio Marine governs web quality. A key milestone was integrating Design System validation into the publication pipeline: every company web application must meet the system requirements before release. The library remains in continuous evolution as products, accessibility needs and technical standards change.
The redesign was less about removing required information and more about changing how and when that information was presented.
Repeated interface decisions across independent web projects.
Shared foundations and reusable components provide a consistent starting point.
Handoff depended on teams interpreting visual files project by project.
Variables, tokens, variants and documentation make implementation intent explicit.
System adoption relied mainly on awareness and manual review.
Compliance is validated as part of the web application publication pipeline.
I started by listening for the moments where the experience stopped making sense.
Interface inventory, recurring-pattern audit, component-state mapping, designer and developer alignment sessions, and continuous feedback from product implementation.
The largest opportunity was not simply creating more components. Teams needed shared decisions: naming, semantic meaning, responsive behavior, states and acceptance criteria that could be understood in both Figma and code.
Treat the Design System as product infrastructure, connecting design assets, implementation guidance and release governance in one evolving practice.
Variables and tokens describe purpose rather than a single visual value, allowing the system to evolve without forcing teams to replace decisions screen by screen.
The library documents variants, interaction states, responsive rules and accessibility expectations instead of presenting components as static visual examples.
Naming and documentation were shaped to make sense in Figma and in development, reducing ambiguity during handoff and implementation.
The publication pipeline checks whether web applications meet Design System requirements, turning consistency into a delivery criterion rather than an optional final review.
Simplifying the quote did not mean removing business-critical information. Several decisions required balancing user simplicity with underwriting, technical, and commercial requirements.
The system standardizes recurring decisions while preserving extension points for legitimate product-specific needs.
Components are added and expanded from validated cross-product needs, avoiding a library that grows faster than teams can maintain it.
Pipeline criteria focus on essential system requirements so quality improves without turning the system into a release bottleneck.
The system was validated continuously through adoption in real web application work and collaboration with development teams. Component coverage, naming and guidance evolved from implementation feedback. The strongest organizational validation came when compliance with the Design System became a required check in the publication pipeline.
Core color roles, typography, spacing, grids and semantic variables established a common visual and technical vocabulary.
Recurring controls became documented components with variants, states, responsive behavior and usage guidance.
Closer collaboration with developers aligned Figma structures, token intent and implementation expectations.
Design System requirements became part of the publication pipeline for company web applications.
A mature Design System is not only a component library. Its real value appears when design decisions are understandable in code, teams trust the shared foundation and governance is embedded in delivery. Connecting Figma variables, components, developer collaboration and pipeline validation turned the system into durable product infrastructure.