Building Tabnine’s Product Design System
Creating a shared component foundation and live Storybook documentation to improve consistency, speed, and handoff across Tabnine’s product surfaces.
- Design System
- Storybook
- Product UI
- Enterprise SaaS
- Design Engineering
As Tabnine’s enterprise product expanded, UI decisions were being made repeatedly across features — buttons, tables, forms, feedback states, and layout patterns were often solved screen by screen.
I created a product design system that turned those repeated decisions into a shared foundation: tokens, reusable components, interaction states, and live Storybook documentation that design and engineering could use together.
The system was built as part of the product workflow, not as a separate artifact, so it could evolve alongside real features and support new UI patterns as they emerged.
Consistency was getting harder to hold onto.
As more product surfaces were added, consistency became harder to maintain. Similar patterns appeared in different forms, small interaction decisions were repeated across features, and handoff often depended on explaining details that should have been standardized.
The challenge was to create a system that was practical enough for engineering, flexible enough for product work, and clear enough to become a shared reference across teams.
Because the system was ongoing, it also had to stay practical: flexible enough to support new product needs without becoming a static library.
What we set out to do.
I framed the work around outcomes that would make the system useful in real product development, not just complete as a library.
- 01
Improve UI consistency
Give the same UI decisions the same shape wherever they appear across product surfaces.
- 02
Speed up design and engineering handoff
Shrink the distance between a Figma component and its code equivalent so both sides trust the source of truth.
- 03
Make component usage easier to adopt
Document components with variants, states, and usage guidance so teams can adopt shared patterns without reinventing them.
- 04
Define component states and variants
Make hover, focus, disabled, loading, and error states visible and inspectable — not tribal knowledge.
- 05
Align design and engineering around one reference
Create one visual, interactive, and code-backed reference that design and engineering could both trust.
- 06
Support scalable product development
Give ongoing product work a stable foundation so pace doesn’t come at the cost of coherence.
How the system took shape.
The system grew through real product work: auditing repeated patterns, defining foundations, aligning with engineering, and documenting reusable behavior in Storybook.
Audited repeated UI patterns across product surfaces.
Mapped recurring decisions across buttons, forms, tables, feedback states, and layout patterns to identify where the product needed shared standards instead of one-off solutions.
Defined foundations and token roles.
Translated colour, typography, spacing, borders, and state treatments into reusable tokens so components could reference intent rather than isolated values.
Built reusable components with engineering partners.
Worked with engineering to connect Figma components, React implementation, and real product requirements, so the system reflected how components were actually used.
Documented variants, states, and usage in Storybook.
Published components with controls, props, states, variants, and usage guidance so the system could be inspected, tested, and reused beyond static design handoff.
What the system covers.
The system brought together four layers: foundations, reusable components, Storybook documentation, and applied product patterns. Together, they created a shared vocabulary for designing and building Admin Console and related product experiences.
The priority was not to document every possible UI element, but to stabilize the components and patterns that repeatedly shaped enterprise workflows: forms, tables, wizards, feedback, and analytics.
Foundations
The foundational layer defines the primitives everything else builds on — what colours mean, how type scales, how space accumulates, and how a component knows it’s disabled or focused.
Colour tokens carry both raw values (primitive palette) and roles (surface, ink, border, accent, status). Typography follows a consistent scale from display to caption, with weights and line-heights tokenised so components can reference intent rather than specific values.
Component System
The component layer covers the UI building blocks that appear across product surfaces. The system spans simple primitives — buttons, alerts, form controls — and more complex enterprise patterns like advanced tables, bulk-action toolbars, wizards, and charts.
Each component is documented with its variants, states, props, and usage guidance in Storybook.
Storybook Documentation
Storybook became the implementation and documentation layer of the system. Core components were documented with variants, states, controls, props, and usage examples, making the system inspectable rather than static.
This helped engineering test component behavior directly and gave designers and reviewers a clearer way to compare states, variants, and props during implementation reviews.
Applied Patterns
The components were organized around product patterns, not only UI categories. Forms combine inputs, validation, and inline feedback. Data-heavy admin surfaces combine Advanced Table with BulkActions. Multi-step configuration flows use Wizard patterns. Analytics views rely on Chart components with tokenized colour and typography.
This pattern-to-component mapping helps new product work start from shared decisions instead of rebuilding common interactions from scratch.
The calls that made the system usable.
The work was not only about creating components. It was about deciding how the system should behave, scale, and stay useful inside everyday product work.
Use semantic token roles, not only raw values.
We decided
Define colours, type, spacing, and state treatments by role — surface, ink, border, accent, status, disabled, focus — so components could express intent consistently across product surfaces.
Why it worked
Semantic roles made the system easier to apply and evolve than one-off values. Designers and engineers could discuss purpose, not only hex codes or pixel values.
Treat Storybook as a shared source of truth.
We decided
Document components in Storybook with variants, states, controls, props, and usage examples — not only as static design references.
Why it worked
Storybook gave engineering and design a live place to inspect behavior, compare states, and reduce ambiguity during implementation review.
Document states as first-class behavior.
We decided
Make hover, focus, disabled, loading, error, and validation states visible and reusable across components.
Why it worked
Many UI inconsistencies come from edge states, not default states. Making those states explicit helped teams avoid re-solving them feature by feature.
Organize components around product patterns.
We decided
Connect components to the product patterns they support: forms, advanced tables, bulk actions, wizards, analytics, and feedback flows.
Why it worked
This made the system easier to use in real product work. Teams could start from a pattern instead of assembling isolated UI pieces from scratch.
What changed.
The impact is qualitative: the system made repeated UI decisions easier to reuse, discuss, and implement across ongoing product work.
Outcomes
- Improved consistency — helped align colour, spacing, and interaction treatments across surfaces that use the system.
- Clearer shared language between design and engineering — created a shared reference for components, states, variants, and behavior.
- Reduced repeated design decisions — teams could start from existing components and patterns instead of re-solving the same UI questions feature by feature.
- Better documentation for component behavior — variants, states, and props are visible in Storybook instead of living only in handoff notes.
- Stronger foundation for future product work — new Admin Console and product experiences can build on shared primitives and patterns.