This case study reflects my experience working on a confidential Deloitte Digital project, where I contributed to the development of a large-scale marketing tool. Due to NDA restrictions, I'm unable to share visuals or name the product directly, but I can speak to the system thinking, cross-functional collaboration, and design infrastructure that shaped the work.
In the coming sections I reflect on the sprint that transformed our post-MVP chaos into a scalable design system.
This is not just our story. Across the industry, product teams turn to design systems for exactly the same reason: to scale without chaos, to maintain consistency across growing teams, and to create a shared source of truth that empowers collaboration.
Role: UX/UI Designer
Deliverables: creating a custom design system in Figma and reviewing the implementation in Storybook
Platform: SaaS
Before diving into the sprint, I grounded our work in the broader context. This slide outlines the core benefits of a design system: consistency, efficiency, and scalability, echoing the very challenges we were facing. It served as both a visual anchor and a quiet advocate for the strategic shift we were making.
"A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels." - NN/g Norman Nielsen group
The sprint that changed everything
We had just shipped the MVP. It was fast, scrappy, and full of promise. As it moved into development, though, the cracks began to show. Button states varied across screens. Spacing rules were improvised. Developers pinged us daily for clarification: “Is this modal padding 14px or 16px?” “Should this hover state match the primary or secondary style?” It wasn’t anyone’s fault, we simply hadn’t built the shared language yet.
By the end of that sprint, it was clear that our current approach wasn’t efficient or sustainable. The inconsistencies were slowing us down and creating daily frustration. So we took a moment to evaluate and made a strategic decision of creating a design system. Life went on. Features shipped, deadlines approached, and the product kept evolving. But amid that momentum, I began creating a design system that could reduce ambiguity, improve handoffs, and support the product as it scaled.
Approaching the implementation section, I shall ground this part in the broader impact of design systems. Collaboration and accessibility are guiding principles. This visual served as a quiet reminder of what we were building toward, a system designed to support cross-functional clarity and inclusive design from the ground up.
Building the backbone
Before having a design system, our workflow was reactive. Components were added ad hoc, often duplicated or slightly tweaked without documentation. The Figma file felt like it’s going to turn into a maze of mismatched styles. Developers struggled to interpret spacing logic or font usage, and QA flagged visual bugs that stemmed from design ambiguity rather than code errors. We were losing cohesion.
I started by asking the most important question: where do we begin? Logically, with an audit of the existing designs in Figma, mapping components, spotting duplications, and identifying subtle variations.
Rather than reinventing the wheel, I leaned on established design systems like IBM’s Carbon and Google’s Material Design as benchmarks for what works well at scale. Dan Mall’s guidance in Starting a Design System helped sharpen my focus: don’t try to include everything, start with what’s already used everywhere. Identify elements that show up across screens, such as navigation, headers, footers, grids, and use those as starting point. With this approach, we could prioritize components that were doing the heavy lifting.
There’s no shortage of best practices and insights as design systems become more widely adopted but the real challenge is building one that works for your team, your product, and your workflow.
The impact
We continuously tested components—not just for aesthetics, but for functionality, clarity, and alignment. Product managers and stakeholders reviewed them in context, ensuring they supported real user flows and business goals. Our global design team also weighed in, as our system needed to align with Deloitte’s broader design language.
Every component had to serve the product. We tested how it behaved across edge cases, how it supported accessibility, and how it held up in development. These reviews were essential to ensure that the system works for everyone: designers, developers, PMs, and users.
As taking shape, the system’s influence became tangible. Design reviews grew faster and more focused. Developers spent less time interpreting spacing or font choices, and QA flagged fewer visual bugs rooted in ambiguity. The shared language we built, through tokens, documentation, and consistent components, allowed each team to move with more confidence.
The impact was cultural, too. The system gave us a way to talk about design with clarity and shared intent. It created space for better feedback, faster iteration, and more inclusive decision-making.
Reflections & next steps
Creating a design system offers many benefits: consistency, scalability, clearer collaboration, and faster iteration. But beyond the frameworks and efficiencies, this process shaped how we worked, how we communicated, and how we grew individually and as a team.
For me, the impact was personal, too. Building a system with technical constraints, across tools and disciplines, required humility, curiosity, and trust. I worked in Figma daily, developers worked in their own environments. We had to bridge gaps in understanding, accept our limitations, and create space for safe collaboration. The process of learning each other’s tools, language, and constraints was as valuable as the system itself.
Design systems live between disciplines. They’re not just libraries of components but they’re shared agreements, built through conversation, iteration, and care.
Like all design, designs systems are imperfect and always in progress. Their usefulness depends on how well they’re maintained, or how clearly they reflect the needs of the product and the people using them.
We continue to check the system’s vitality, its relevance, clarity, and adaptability. That means pruning what no longer serves, refining what does, and staying open to change
Good systems aren’t just scalable but also relational. They grow with the people who use them.