Building OTKit: From Drift to Discipline

Overview

When I took ownership of OTKit — OpenTable's design system spanning iOS, Android, and web — the system existed on paper. In practice, it lacked cohesion, governance, and trust. Design drift, fragmented sources of truth, and inconsistent adoption were slowing teams down and introducing costly QA issues.

My mandate was not just to redesign components.

It was to turn a drifting system into an operational platform teams actually relied on.

The Problem

Design system drift was expensive and invisible.

Research through user surveys and 1:1 interviews revealed:

• Three competing sources of truth (Figma, Storybook, internal token sites)
• Visual inconsistencies across products and platforms
• Late-stage QA bugs tied directly to token and component mismatch

We estimated the cost of drift at ~$237K/year in inefficiency and rework.

User Research

A survey of 37 respondents across design, product, and engineering revealed the depth of the problem:

One-off component creation

100% of iOS designers said they were creating new or one-off components often or occasionally, compared to 60% of web designers across both Restaurant and Diner teams. iOS teams suffered the most, which made sense given we had a much more mature web component library (Buffet) but nothing comparable for native.

I think iOS lacks the rich component system that web has (Buffet), and that poses some challenges for us. (Restaurant iOS engineer)

Time spent clarifying styling during release

75% of Restaurant web designers reported spending 4–8 rounds clarifying styling with engineering during each release cycle. Meanwhile, 100% of Diner web designers reported only 0–3 rounds. Cross-functional Restaurant teams were spending significantly more time reconciling their style guide with designers and developers.

Consolidating research

We ran 1:1 interviews and remote collaborative brainstorms using FigJam and Dovetail. The main insight was clear: designers and engineers often had the same problem, namely unclear documentation, scattered sources of truth, and no shared language for components. Most folks knew what colors and styles to use, but much of the style guide lived in designers' heads rather than in a system.

We have a ton of legacy styles and pages on our iOS apps and it's always a push and pull on when and how to update those. (Cris, designer on Restaurant product)

Constraints

The system had to evolve without stopping product delivery.

• Six product and platform teams shipping in parallel
• Legacy UI patterns deeply embedded in production
• Cross-platform requirements (iOS, Android, Web)

Strategy

To stop drift without breaking teams, I focused on foundations first, then scaled upward:

• Tokens before components
• Accessible color and typography foundations
• Documentation as a first-class system artifact

Foundations: Tokens, Type, Icons

These foundational changes made consistency possible without forcing large rewrites — adoption could happen across active codebases, not instead of them.

Color tokens

• Audited and documented all existing colors cross-platform
• Deprecated legacy redundant colors
• Rebuilt the color system around accessible, semantic tokens
• Built mixed light/dark theming for existing UI

This resolved cases where critical actions appeared disabled, improved cross-platform parity, and allowed teams to adopt the system without rewriting existing UI.

System thinking in action: Table Statuses

A real product use case validated the color system early. The Table Statuses feature needed color-coded indicators for reservation states — and the product team initially proposed 21+ new colors. By collaborating with the design system team, we satisfied the project requirements using the existing accent palette, reducing color sprawl while shipping on time. The product got what it needed. The system stayed coherent.

Contextual typography

The existing type system was a one-size-fits-all scale that:

• Was not mobile-optimized
• Encouraged incorrect font usage in native apps
• Had ballooned to 39 fonts in the codebase

Solution

• Introduced a contextual typography scale by platform
• Defined size, weight, and family per context
• Added support for Apple Dynamic Type

Impact

A/B testing showed a +2.19% increase in diner bookings (+600 weekly net bookers) on pages using dynamic type.

Icon system

• Introduced shape-based icon grids
• Unified keyshapes for indicators
• Centralized icon repositories across platforms
• Added SF Symbol parity for accessibility

The result: a searchable, themeable SVG system shared across native and web teams — duplication dropped, accessibility parity improved.

Brand Evolution: "Black Is the New Red"

OpenTable operates in an industry dominated by red and orange. Partnering closely with Brand, we translated a premium direction into a tokenized theming architecture rather than one-off visual treatments.

This allowed brand evolution without breaking product consistency. Namely:

• Two new font families
• A refreshed color palette
• Visual distinction for Iconic restaurants

The key insight: by encoding brand decisions as token values rather than hardcoded styles, the system could absorb a major brand shift without requiring teams to rewrite their components.

Theming in Practice

The tokenized architecture made it possible to deliver two visually distinct experiences from a single component library.

Mass Theme

The Mass theme serves OpenTable's core restaurant audience. Editorial in feel, it uses a two-column structure inspired by e-commerce: booking surfaced immediately, decisions guided with minimal visual noise. Every component follows the same token-driven pattern, so new features land consistently without bespoke design decisions at the component level.

Iconic Theme

For OpenTable's premium Iconic restaurant tier, the system delivered a distinct but coherent experience. Full-bleed photography, dark wine-inspired time slot styling, and sticky booking flows communicated prestige without sacrificing usability. The same underlying tokens and components powered both themes. No fork required, just a different set of token values.

Outcomes & Impact

OTKit delivered measurable ROI:

• 25% reduction in QA time
• ≈ $59K/year reclaimed in developer time
• 50% fewer Figma libraries
• Unified design language across 6 teams
• Supported a full OpenTable brand refresh

Designers and engineers also reported a 27% lift in clarity around Figma component sources in our follow-up survey. The consolidation work made it easier to find authoritative components without hunting through legacy Storybooks and one-off libraries.

OTKit scaled across 6 product teams, supporting iOS, Android, and web simultaneously.

What Made This Work

OTKit's adoption didn't happen through enforcement. We built a network of design ambassadors: designers embedded in product teams who championed the system locally and surfaced friction back to the core team. This created a feedback loop that made the system more useful over time.

Documentation was treated as a first-class deliverable, not an afterthought. Component specs, token definitions, and usage guidelines were kept in sync with engineering. We ran regular office hours, live demos, and shipped a system newsletter to keep teams informed and engaged.

I wanted to directly reach out and thank you for your feedback in today's session. All of the links and resources you shared were incredibly helpful. (Stephanie, Restaurant Design Ambassador)

I wanted to mention how helpful it has been having River support me on the design systems front. His depth of knowledge has been invaluable for our team. (Jordon, Restaurant Design Ambassador)

Trust was built through follow-through. When teams reported issues, we responded quickly. When we made breaking changes, we migrated them. That responsiveness turned skeptics into advocates.

Learnings

Challenge: Lack of native Figma support for design tokens

We started work on the foundations before Figma released Variables. This meant we initially had to manage tokens through workarounds: naming conventions, separate documentation, and manual syncing. When Variables shipped, we migrated quickly, but the gap cost us early momentum.

What I'd do next time: More upfront communication around the limitations of tooling and clearer expectations about what would change once better tooling arrived. Teams need to understand the 'why' behind interim solutions.

Challenge: Communicating with remote teams

Working in a remote setting with teams distributed across North America, Europe, and Asia created real communication challenges. Updates got lost, context didn't travel well across time zones, and synchronous meetings couldn't cover everyone.

What I'd do next time: Lean harder into async from the start, with more recorded video demos, tech talks, dedicated Slack Q&A channels, and newsletters. The newsletter ended up being one of our most effective tools, and I wish we'd started it earlier.

Challenge: Scaling myself

Design systems work often got sidelined into supporting feature work that needed system alignment. The constant pull between system-level thinking and product-level support was real, and without clear boundaries, it was easy to become a bottleneck.

What I'd do next time: Be clearer upfront about the design system team's role and responsibility relative to product work. The Ambassadorship model helped with this, but establishing those boundaries earlier would have preserved more time for foundational work.

Reflection

The success of OTKit wasn't the components. It was the shift in mindset. The system became something teams relied on, not something they worked around.

That's the difference between a library and a platform.