Design System: From Code Chaos to Design Clarity

Forecastio | 0 → 1 Design System | Figma & Tokens | Shipped 2025

ON THIS PAGE

THE STORY

THE PROBLEM

THE PHILOSOPHY

PRODUCT IMPACT

CHALLENGE

WHAT I LEARNED

THE STORY

Understanding the codebase

When I joined, there was no design in the traditional sense. We had no Figma files, no style guides, and no mockups. There was only the live product. It was functional but built entirely by frontend developers on the fly. My challenge was not just to build a design system. I had to reverse-engineer order from a chaotic codebase and close the gap between engineering logic and user experience.

Product

Web | B2B SaaS

TIMELINE

2025

MY ROLE

As Designer, I owned the entire system architecture: from reverse-engineering a codebase with zero design files to building the first component library and establishing a shared design-to-dev language.

SKILLS

Systems Thinking, UI Architecture, Token Mapping, Figma Engineering, Frontend Collaboration

IMPACT

Transformed a chaotic, developer-built interface into a structured design system. Standardized 15 button variants into one, eliminated infinite color guessing, and cut new feature implementation time, while reducing user confusion through predictable interactive states.

THE PROBLEM

The developer art reality

The product suffered from engineering UI. It worked fine but lacked visual hierarchy and predictability for the user. The only source of truth was the browser itself. To design a new feature, I had to screenshot the existing site and paint over it. We carried massive visual debt with fifteen variations of the same button and a color palette that was technically infinite because every developer picked hex codes visually. Development was painfully slow because every interface element was built from scratch. We were accruing technical debt with every commit.

THE PHILOSOPHY

The cultural shift of system building

I knew we could not just stop product development to redesign everything. We had to build the plane while flying it. I treated the design system not as a cleanup task but as an internal product with its own lifecycle.

Building a design system is definitely a journey not a one-and-done project. It is hard to capture the countless hours, iterations, and little wins that went into it over time. The hardest part of this journey was the culture shift rather than the UI itself. Because the developers were used to working without designs, I had to earn their trust.

I worked directly in their environment to inspect the DOM, understand their CSS constraints, and offer solutions that reduced their workload.

My goal was not to build a perfect system immediately but to build a scalable one that could evolve with us by moving engineers from guessing the design to assembling it from a standardized kit.

The goal was measurable and practical:

STEP 1

Visual archaeology + audit

Since I had no design files to reference, I audited the code directly. I took screenshots of every component in production including inputs, modals, and headers. I compared duplicated components across different screens to identify what was truly reusable versus what needed to be retired.

Grouping them revealed the scale of the problem to the stakeholders. Seeing twelve different shades of gray on one board made the business case for a design system undeniable. I cleaned up the unused styles and mapped the most common UI patterns we were repeating to establish a strong visual foundation.

We started with the foundation: Chart on top, Table below. Familiar territory.

We also treated the chart as more than a visualization. It is where investigation starts. So we added two context layers directly on the timeline: Google updates and custom notes. Users can see algorithm shifts in the same view as their performance changes, and leave their own markers to explain what happened and why.

In native GSC, the answers are still hidden behind clicks. The most common question is: “Which Page ranks for this Keyword?” And answering it costs context.

STEP 2

Consolidating + rebuilding

I began consolidating scattered elements into one scalable framework. Redundant card styles collapsed into one unified component with clear states for icons, clickable areas, and footers. Unified components powered by strict variants entirely replaced the old one-offs. Left navigation, data tables, pagination, and tags became standardized atomic elements ready for reuse across the entire platform.

Moving the team away from hard-coded values to semantic design tokens fixed both the visuals and the communication. Design and engineering finally spoke the exact same language.

We started with the foundation: Chart on top, Table below. Familiar territory.

We also treated the chart as more than a visualization. It is where investigation starts. So we added two context layers directly on the timeline: Google updates and custom notes. Users can see algorithm shifts in the same view as their performance changes, and leave their own markers to explain what happened and why.

In native GSC, the answers are still hidden behind clicks. The most common question is: “Which Page ranks for this Keyword?” And answering it costs context.

STEP 3

Documenting + systematizing

Strict documentation turned the library into a scalable tool for both designers and developers. Existing code blobs became proper Figma components governed by atomic design principles. Auto layout and component properties mirrored exactly how the frontend handled padding and flexbox behavior. A shared naming convention organized the entire architecture. Embedding mini-usage guidelines directly inside the design files eliminated the need for future teams to guess the interaction rules.

We started with the foundation: Chart on top, Table below. Familiar territory.

We also treated the chart as more than a visualization. It is where investigation starts. So we added two context layers directly on the timeline: Google updates and custom notes. Users can see algorithm shifts in the same view as their performance changes, and leave their own markers to explain what happened and why.

In native GSC, the answers are still hidden behind clicks. The most common question is: “Which Page ranks for this Keyword?” And answering it costs context.

ACCESSIBILITY

Designing for inclusivity

Inclusivity was baked into the foundation from the start rather than treated as a late addition. Accessibility best practices dictated the structure of every component. Enforcing strict color contrast ratios guaranteed that text and interface elements met established visual standards. The system actively supports keyboard navigation through distinct interactive states for hover, focus, and disabled elements. Form inputs received proper labels and clear error states. This structural clarity drastically reduced user confusion and improved task completion during heavy data entry workflows.

We started with the foundation: Chart on top, Table below. Familiar territory.

We also treated the chart as more than a visualization. It is where investigation starts. So we added two context layers directly on the timeline: Google updates and custom notes. Users can see algorithm shifts in the same view as their performance changes, and leave their own markers to explain what happened and why.

In native GSC, the answers are still hidden behind clicks. The most common question is: “Which Page ranks for this Keyword?” And answering it costs context.

SCALING

Growing beyond the basics

Phase 1 established the baseline, but the system had to prove its worth in heavy usage scenarios. We adapted to a smarter intentional process where engineering was involved during the creation state itself.

Phase 2 focused on scaling from simple buttons to heavy data structures. I introduced advanced molecular components like nested data tables, multi-select dropdowns, and dynamic empty states. I adapted components to fit new contexts by transforming vertical form fields into horizontal layouts when spatial constraints demanded it. The design system transformed from a basic visual kit into a full platform language capable of handling our most demanding enterprise features.

We started with the foundation: Chart on top, Table below. Familiar territory.

We also treated the chart as more than a visualization. It is where investigation starts. So we added two context layers directly on the timeline: Google updates and custom notes. Users can see algorithm shifts in the same view as their performance changes, and leave their own markers to explain what happened and why.

In native GSC, the answers are still hidden behind clicks. The most common question is: “Which Page ranks for this Keyword?” And answering it costs context.

PRODUCT IMPACT

Fixing the user experience

A design system exists to solve direct user friction rather than just internal inefficiencies. I used the new component library to establish strict spatial logic across our analytics dashboard by anchoring the calendar and global filters into a predictable top toolbar. Users stopped treating every new screen like a scavenger hunt because they could finally rely on established layout patterns. This architectural shift also transformed our heavy data entry flows.

CHALLENGE

Challenges <> Clarity

CHALLENGE

Custom code for every feature

Frontend engineers spent hours writing fresh styles for basic modals. They guessed padding values based on flat screenshots.

CLARITY

Building with modular blocks

Engineers now assemble interfaces using our atomic components. They pull variables directly from our established tokens to eliminate visual guesswork entirely.

CHALLENGE

High cognitive load

Users clicked unclickable elements because our text links shared the styling of primary actions. The interface lacked spatial logic.

CLARITY

Predictable interactive patterns

We anchored core controls into dedicated toolbars. Standardized interactive states mean users navigate the platform through muscle memory rather than active problem solving.

CHALLENGE

Tribal knowledge blocked scaling

Onboarding a new designer meant spending weeks explaining undocumented rules and digging through the live codebase.

CLARITY

A shared visual vocabulary

New hires pull the component library on their first day. The interaction rules are baked directly into the file properties so they can start building actual features immediately.

WHAT I LEARNED

Key takeaways

  1. Code is the ultimate source of truth: Auditing the live codebase taught me more about real usage patterns than any user interview would have. When no design files exist, the browser shows you exactly what the product actually is rather than what the team thinks it is.

  1. Ship components instead of redesigns: Attempting a massive redesign would have failed entirely. We avoided the trap of a big bang release. Shipping tokens and atomic elements incrementally allowed us to fix technical debt without freezing the product roadmap.

  1. Adoption requires engineering empathy: A system fails if engineers refuse to use it. Learning how to inspect the DOM and map CSS constraints earned me the trust required to change how the entire team shipped software. The countless hours spent talking to developers were just as valuable as the hours spent aligning pixels in Figma.

Footer Illustration

You've made it to the end of quite the scroll.. Great job!

In some other universe, we're already friends. So why not in this one? So let's connect!

Serious Me
I'm currently open to full-time opportunities! Let's create something amazing together! ✨
Footer Illustration

You've made it to the end of quite the scroll.. Great job!

In some other universe, we're already friends. So why not in this one? So let's connect!

Serious Me
I'm currently open to full-time opportunities! Let's create something amazing together! ✨