Cyral Design Style Guide
A design system built to outlast the designer who built it.
The Cyral Design Style Guide was a component library and visual language built from scratch during my time as Lead Designer. It standardized typography, color, spacing, and component patterns across the product, giving engineers a single source of truth and eliminating the inconsistency that had accumulated from a team making individual styling decisions without guidelines.
Overview
Joining as the first designer
Cyral provides data access control to enterprise security teams. Early product features were built by engineers converting low-fidelity Google Slides wireframes into production UI; this was a reasonable way to ship early and a difficult one to keep consistent.
I joined as the first and only designer. There was no design system, no component library, and no reference for anyone to work from. Design decisions had been made individually, and nothing was documented properly.
Problem
Designing without a source of truth
The Cyral product UI had accumulated inconsistency quietly over the span of a year. Typography varied across screens, color values were technically different but visually similar, spacing was unstandardized, and border radii on buttons and inputs were mismatched with no apparent logic.
The engineering team had been converting low-fidelity Google Slides wireframes into production UI, making individual styling choices without a shared reference. When a new engineer joined, there was nothing to hand them, so they learned by asking colleagues which styles to use, which slowed everyone down.
When I joined Cyral, I set out to standardize design decisions and document them to define a source of truth.
Solution
Designing with no bandwidth
Executive buy-in was limited at the start; I was a new hire brought in to craft experiences for prioritized features, so it was difficult to request dedicated bandwidth for standardizing design. As a result, I built the system in parallel with feature work, defining the styles that mattered most and introducing them through whatever was shipping at the time. Existing inconsistencies were eventually addressed during natural refactors.
Working within this constraint provided a logical path to standardizing the design choices without feeling overwhelmed. Foundational styles came first, then the components already in heaviest use: buttons, tables, iconography, cards. At Cyral, I was fortunate to have peers who were comfortable navigating Figma. I documented design decisions in a file, with a page per category and a changelog that propagated updates across projects.
Impact
Built to be handed over
The work across three years was a steady set of small alterations to individual components, and a lot of new components added because a feature needed one.
Certain portions of feature development timelines were improved as design decisions were standardized and documented. Providing front-end developers with a design source of truth enabled them to establish reusable components and eliminate opportunities to introduce inconsistencies, into both the product UI and the codebase. New hires were also able to get up to speed and familiarize themselves with the front-end codebase much faster, without dedicated oversight from other engineers.
Reflection
What I learned
Coming into a startup to establish a design culture and a presence in product discussions was incredibly challenging. I was excited to tackle that challenge, and saw it as an opportunity to personally shape the design direction for a product. I learned how to articulate design decisions to get buy-in from stakeholders, how to communicate with engineers so that designs are faithfully implemented, and how to rally teammates so that everyone’s aligned on the same outcomes.