Rescuing a Failing SAR 700K Design System Initiative

Context

In April 2024, I joined Rewaa, one of Saudi Arabia's fastest-growing SaaS startups, as a Sr. Lead Product Designer. Rewaa's platform powers inventory, POS, and accounting across thousands of stores, but the product had grown messy. Years of rapid feature development left the platform riddled with visual inconsistencies, fragmented patterns, and disconnected user flows across dozens of interconnected modules.

When I arrived, a design system initiative called "RDS 2.0" was already underway, three quarters into development. The project had executive buy-in, dedicated resources, and a clear promise: build a component library in Storybook, boost consistency, and multiply development speed. On paper, it made perfect sense.

In practice, it was destined to fail.

Organizational Maturity

• Design team: 1 senior, 3 mid-level, 2 juniors, led by a Product Design Director. The team had limited design systems experience

• Product management: Output-driven, disconnected from users, operated like a "feature factory" with minimal UX understanding

• Engineering: 40+ engineers, only 1 specialized front-end developer, most were back-end engineers labeled "full-stack"

• Product state: Massive platform with deep inconsistencies at every level (visual, interaction, navigation)

The Problem

The team had spent 9 months and $170K+ (2 full-time engineers, design support, PM overhead) building a single Data Table component for Storybook. It was the first component they chose to tackle, reasoning that tables appear in almost every module, so building one reusable table would deliver a "quick win."

But the approach was fundamentally flawed:

• No foundational token system (colors, typography, spacing)

• Complex component built first instead of atomic building blocks

• All variants hardcoded into a single monolithic component

• No scalability plan for future components or adoption

Within the first week of rollout, the component became a blocker. The Reports team needed table functionality the component didn't support. They had two bad options: detach and customize (defeating the purpose), or halt their work while the design system team added features (making the system a bottleneck, not an enabler).

Everyone involved, designers, engineers, PMs, leadership, had walked into this with good intentions but no design system expertise. The Director had sold the CEO on a 3-5 month timeline. Nine months later, they had one broken component and mounting frustration.

My Role

I joined mid-crisis, and within weeks I could see the structural problems clearly. But identifying the issue wasn't enough, I needed to convince skeptical stakeholders to abandon sunk costs and reset the approach.

What I owned:

• Diagnosing why the existing approach couldn't scale

• Building the case for a complete rebuild (despite 9 months of work already invested)

• Designing a new 2-month plan with proper atomic foundations

• Restructuring the Figma UI kit to follow atomic design principles

• Coordinating parallel design-engineering sprints

• Documenting components and building adoption strategy

Collaboration:

• Worked directly with the Product Design Director (who asked for my help after the initial rollout failed)

• Partnered with 1 dedicated front-end engineer for execution

• Navigated resistance from PMs who called me a "perfectionist" and pushed back on the timeline reset

Challenges & Trade-offs

Challenge 1: Convincing Stakeholders to Abandon Sunk Costs

The hardest part wasn't the technical work, it was the organizational inertia. The team had already spent 9 months. The Director had promised the CEO results. PMs were impatient and dismissive of "perfectionism."

I spent weeks explaining why "we'll fix it later" doesn't work with design systems. If the foundation is wrong and teams start adopting the broken components, fixing it later means rebuilding from scratch, but now you're also migrating dozens of implementations across the platform.

The breakthrough came when the Reports team hit the wall. The pain became real, and suddenly my objections made sense to everyone.

Challenge 2: Speed vs. Quality Under Scrutiny

After convincing leadership to reset, I had to deliver fast. The Director was already in an awkward position with the CEO. I couldn't afford another failed timeline.

I proposed a 2-month plan with a clear milestone: 32 atomic components + a properly architected table component. The trade-off was ruthless prioritization, we focused only on components needed for the table system and the most common UI patterns.

Challenge 3: Limited Front-End Expertise

With only 1 qualified front-end engineer available, I had to design the system with extreme clarity. Every component needed tight documentation, clear token usage, and minimal ambiguity. There was no room for interpretation, the engineer needed to move fast without constant back-and-forth.

Process

Step 1: Audit & Diagnosis (Week 1)

• Reviewed the existing Figma UI kit and Storybook implementation

• Mapped out dependencies (e.g., what core components are needed to build a table?)

• Identified gaps: no token system, no atomic structure, hardcoded variants

Step 2: Stakeholder Alignment (Weeks 2-3)

• Built the case for a reset: showed how the current approach would compound costs

• Presented a 2-month plan with clear milestones and deliverables

• Negotiated buy-in from skeptical PMs and nervous leadership

Step 3: Foundational Rebuild (Weeks 4-5)

• Restructured the Figma UI kit with proper token architecture (colors, typography, spacing, sizing)

• Designed 32 atomic components (buttons, inputs, checkboxes, dropdowns, popovers, badges, etc.)

• Created a backlog for parallel design-dev sprints

Step 4: Parallel Execution (Weeks 6-8)

• Design sprint: finalize component design + documentation

• Dev sprint: engineer picks up completed components and builds in Storybook

• Continuous feedback loop to ensure components were production-ready

Step 5: Adoption Strategy (Week 8)

• Designed a phased rollout plan: package the library, push to production repo, test integration, then roll out module by module

• Documented contribution model for future scalability

• Prepared training materials for designers and developers

Outcomes

Efficiency Gains

• 18× more efficient on engineering resources: 1 engineer for 2 months (2 eng-months) vs. 2 engineers for 9 months (18 eng-months)

• 32× better output: Delivered 32 reusable atomic components + properly structured table system vs. 1 unmaintainable component

• Saved ~$135K in wasted resources by stopping the wrong approach early

Team Impact

• Doubled designer productivity: The new Figma UI kit with proper token architecture and atomic components made design work significantly faster across the 7-person design team

• Enabled faster engineering execution: Clear documentation, token system, and component dependencies helped engineers plan better and move faster

• Created scalable foundation: The atomic structure meant future components could be built by composing existing pieces, not starting from scratch

Cultural Shift

• Demonstrated the value of slowing down to speed up: proper foundations pay off exponentially

• Shifted the conversation from "ship fast" to "ship smart"

• Proved that design systems are strategic investments, not quick fixes

The Unfinished Chapter

Just as we were ready to roll out the first phase (packaging the library and testing production integration), the company underwent mass layoffs. The only engineer with the expertise to execute the integration was let go a day before starting the task.

The design system project was paused indefinitely, not because it failed, but because the business priorities shifted dramatically. The foundational work remains intact and usable if the company ever revives the initiative.

Reflection

What I'd Do Differently

Start with a pilot, not a platform-wide initiative.

If I could rewind, I'd push for a single-module pilot first. Pick one product area, implement the design system there, measure the impact, then scale. This would have:

• Proven the value faster

• Reduced organizational risk

• Built internal champions before asking for broader buy-in

Invest more in adoption strategy upfront.

I focused heavily on building the right technical foundation, but adoption is where design systems live or die. If the layoffs hadn't happened, we would have hit adoption challenges eventually, teams resisting change, implementation inconsistencies, lack of governance.

I should have spent more time early on:

• Identifying champions in each product team

• Building a clearer contribution model

• Setting up a design system working group with rotating membership

Communicate progress more visibly.

The Director was in an awkward position because the CEO had been sold on a timeline that didn't pan out. I rebuilt the system fast, but I didn't spend enough time making that progress visible to leadership. A simple weekly update deck showing components shipped, adoption readiness, and timeline would have bought more goodwill.

What This Taught Me

Design systems fail because of people and processes, not components.

The technical work, designing tokens, building components, writing documentation, is the easy part. The hard part is organizational alignment, adoption strategy, and sustained commitment. A design system is a product, and like any product, it needs a roadmap, stakeholders, and ongoing investment.

Sunk cost fallacy is expensive.

The team spent 9 months going in the wrong direction because no one wanted to admit the approach was flawed. The longer you wait to course-correct, the more expensive the fix becomes.

Speed + quality aren't opposites if you have clarity.

I rebuilt the system in 2 months because I knew exactly what needed to be done. The original team took 9 months because they were figuring it out as they went. Slowing down to plan properly often means you ship faster in the end.