Cornerstone
Design System

Before components came principles. I wrote four to guide decisions when trade-offs are required. They aren’t strict rules; they give teams a shared foundation for conversations and help everyone align on what “good” means.

I also set the accessibility baseline early. Every experience in the system should meet WCAG 2.2 AA, treated as a requirement from first sketch to final build, not something added at the end.

Typography uses Roboto in three weights, with a defined set of heading and paragraph styles. Color starts from a core palette in tonal steps and is applied through usage tokens for text, icons, and semantic meaning.

Text colors are tested against WCAG 2.2 AA, so using the right token means meeting the 4.5:1 contrast requirement without checking it by hand.

Fourteen components are documented: badge, button, card, checkbox, chip, date picker, dropdown select, grid table, modal dialog, radio button, switch, tabs, text input, and toast. Each page follows one structure, covering anatomy, states, usage, key behaviors, content guidelines, layout, accessibility, and code.

The library follows atomic design, a method by Brad Frost. Atoms like tokens, buttons, chips, and checkboxes combine into molecules like labeled inputs and selects, then into organisms like cards, tabs, modals, and the grid table. Patterns show how those parts come together in context.

Every experience in Cornerstone should meet WCAG 2.2 AA, so more people can use our products regardless of ability, device, or context. I treat that as a baseline requirement, so the components carry it instead of leaving it to each team.

Every component page splits accessibility in two: what the component is built to meet, and which criteria can still fail depending on how it’s used. Here’s the short version.

Documentation only helps if it stays true to the product. Each component page links to Storybook, which I treat as the source of truth for states, variants, and supported combinations, and lists the props engineers use to configure it.

The component theme lives in Telerik ThemeBuilder, with variants for each button emphasis and status. The documentation itself is a living resource, and it grows as the product, tools, and ways of working change.

Developers adopt what they can try in minutes. Every component page in the documentation links to a Storybook preview, where the full set of states, variants, and interactions runs live. The documentation treats Storybook as the source of truth for how a component behaves and which combinations are supported.

The goal is to make trying a component take minutes instead of a handoff. A developer opens the story, changes a prop, watches the result, and checks the code, all without translating between design language and engineering language.