Figma Design System
A three-phase, research-led strategy that turned a fragmented component library into a shared system robust enough for anyone at Skyral to build a product without a dedicated designer.
Cut design time by 50% and improved delivery consistency.
Post-launch issues caught early through system standards.
18% fewer
32% happier
Users reported greater satisfaction across geospatial tools.
22% faster
Product adoption accelreated following earlier UX intervention.
Timeline
Aug 23-May 25
Role
Lead Product Designer
Tools
Figma, Jira, Adobe, Storybook, Omlet
Keywords
Scale up
End-to-end
SaaS
B2B
Design system
Data vis
0-1
Context
When I joined Skyral, there was no unified design system underpinning the product. Designers and engineers were both recreating components from scratch on every project — Figma components lacked the right properties, and engineers had no reliable library to build from — which meant inconsistent output and duplicated work across the organisation, with no single source of truth.
Without tokens, even basic variations like light mode or high-visibility mode were considered too costly to build. And without a contribution process, pipeline visibility, or usage guidelines, teams had no structured way to propose changes, no data on which components needed deprecating or expanding, and no shared rules for when to use which colour, component, or pattern — so every team made those calls on their own, inconsistently.
Engineering Manager x1
QA Testers x2
Full Stack Engineer x1
Product Designer x1 (Isra Tabassum)
The team
Strategy
As lead of the design system team, I owned the planning end to end — setting the phased roadmap, sequencing what needed fixing first, and deciding what each phase would tackle. The Button component gives a glimpse of that plan in action across all three phases.
Evidence-led iteration: Omlet and analytics
I ran group sessions with engineers and designers to hear their pain points with the existing system, and to find out which components they valued most and which new ones belonged in the pipeline. I paired this with data — introducing Omlet for design system analytics, alongside our internal dashboard and Figma's own analytics — to see how components were actually being used and prioritise accordingly.
Accessibility
Accessibility was foundational from day one — every component was built to be WCAG 2.1 Level AA compliant, with minimum font sizes and colour contrast ratios baked in by default. Once tokens landed, light and dark mode became simple extensions of that compliant foundation rather than manual rebuilds.
Atom-level thinking
This atomic mentality ran across the whole system, not just icons — Labels, Links, and other small, reusable elements were all built as independent atoms that larger components could pull from. The Icon component makes it easiest to see in practice: individual icons called as consistent, centrally-maintained instances rather than dropped in ad hoc, so any update to an icon propagated everywhere it was used.
Tokens library
I built the variables library and its naming system from scratch, designed around how our teams actually worked — so a token's name told you what it was for, not just its value.
Components with usage guidance
Every component shipped with guidance in Figma and Storybook: do's and don'ts, related components, child atoms, and accessibility notes for engineers. Checkbox shows this in practice.
Company-wide adoption
With too few designers to support every team, the token map let engineers apply the system independently, backed by a brand-guide-style onboarding doc for onboarding. I piloted the system with specific product teams using examples from their own projects before wider rollout, then kept people engaged through bi-weekly updates and a contribution process that gave everyone a real stake in the system. This active involvement, rather than a top-down mandate, is why adoption faced so little resistance.
© Copyright Isra Tabassum 2026