Consistency ↑
Design misalignments dropped across platforms
Design System for StockNews.ai
Overview
Scaling Without Slowing Down
As a Founding Designer at an early-stage AI fintech startup, I built a design system from zero, in parallel with a live product redesign, with no dedicated DS engineer and an existing template too bloated and generic to fit the product.
The challenge wasn't just building the system - it was deciding what to build first, when to pause, and when to push it further, all without slowing down the product.
I approached it in three triggered phases, each one prompted by a real gap, not a predetermined plan.
Impact: -25% engineer handoff cycle / Design consistency up across desktop & mobile / Scalable component library ready for Storybook integration
- MY ROLE
- Founding Designer
- TEAM
- 2 Designers, Front-End Engineer
- PLATFORM
- Desktop & Mobile
- SCOPE
- Figma -> CSS -> Storybook
Context
We Were Building a Product With No Design Foundation
Challenge
When I joined StockNews.AI as a Founding Designer, the product was an MVP with no design guidelines - buttons had inconsistent border radii, colors were defined ad hoc, and the existing Figma template was bloated with unused components. Two designers were about to work on the same product simultaneously.
Without a shared language, every sprint would create visual debt the engineering team would eventually pay. I proposed building a design system - and had to make the case for it despite initial skepticism about the time investment.
I proposed building a design system. The harder part was making the case for it. In a fast-moving startup, anything that doesn't ship immediately is a hard sell.
Strategy
Rather than building everything at once, I mapped a phased delivery - starting with what would unblock the team immediately, and letting each next phase be triggered by a real gap I discovered along the way.
Phase 01 - Audit/ Style/ Atom
A Lite Version, Built in Parallel
Problem
Designers shipping simultaneously, no time to build a full system first
I was leading the core product redesign. The second designer was building the landing page. We needed shared buttons, colors, and type - but I couldn't pause the redesign to build a full system first.
Decision
Ship a Lite Version first - unblock both designers without pausing the redesign
Ship a Lite Version immediately, covering only the essentials. Style tokens (color, type, spacing), atomic components (buttons, inputs, tags), and clear naming conventions so the engineer could mirror the system in CSS without ambiguity.
What I Built
Color system:
Primary blues, system colors (Bullish/Bearish), function colors - all with semantic naming
Typography scale:
Archivo type family, Display -> Headline -> Body hierarchy with spec'd line heights and letter spacing
Atomic components:
Inputs, buttons, tags - built in Figma with light/dark variants and WCAG-verified contrast (4.83:1)
Naming convention:
Aligned to how engineers write CSS. Handoff became a translation, not an interpretation
Phase 02 - Organisms/ Documentation
The System Grows With the Product
Trigger
Redesign shipped. Time to close the gaps
Once the core redesign went live, I returned to the system with time to do it properly. The product had grown - new features meant new component patterns that hadn't been formalized. I documented the full organism layer and wrote interaction specs: hover states, expand/collapse behavior, tooltip triggers, and copy-to-clipboard flows.
Approach
Add new components back. Write specs the team can follow.
The redesign had introduced new patterns that lived in the product but not in the system. Every new component was becoming a one-off. I went back to formalize what we'd built - turning product decisions into reusable system rules.
Phase 03 - CSS System/ Storybook
When I Realized the System Wasn't Crossing the Line
Problem
Engineering gap discovered
After the redesign launched, I started noticing visual inconsistencies in production - components with slightly off colors, hover states that didn't match the spec. I traced it back: engineers were applying styles directly in their templates, not pulling from a shared CSS token system.
The design system existed in Figma, but it wasn't living in code.
Decision
Build a Storybook to be the only source of truth
I made the case to build toward Storybook, a component library in code that engineers could pull from directly. This meant bridging the gap between my Figma tokens and the CSS variables the engineering team was already using, and documenting the component API so they could implement with confidence.
Impact
Scalability ↑
System supported responsive & mobile-ready features
-25% Handoff
Engineer handoff cycle time reduced
Reflection
"A design system isn't a deliverable. It's an ongoing conversation between design intent and engineering reality"
WHAT WORKED
Starting lean and iterating. The Lite Version unblocked both designers immediately without becoming a bottleneck. Letting the system grow with the product meant it stayed relevant.
WHAT WAS HARD
Cleaning up the old bloated template was unexpectedly time-consuming. Merging inconsistent legacy components into a coherent system takes patience, and discipline to throw things away.
WHAT THIS SHOWS
I don't just design components. I think about how design decisions live and die in production. That's the part most designers skip.
WHAT I'D DO DIFFERENTLY
Establish CSS token alignment with engineering at the very start, before any components are built. Discovering the gap in production is a preventable problem.
Design System Case Study