Diana Wolosin on Building Design Systems: An Exclusive Interview

Design systems are easiest to understand when they are small. A team creates a component library, documents a few patterns and agrees to reuse them. The harder questions arrive later: what happens when the system serves hundreds of practitioners, when Figma introduces a new model for variables and components, when accessibility and localisation become system-level responsibilities, and when every improvement carries migration cost?

Those are the questions that make this conversation with Diana Wolosin worth revisiting. Diana has worked on design systems at Indeed, including its Email Design System, and describes the work less as library maintenance than as cross-functional product infrastructure involving designers, developers, accessibility specialists, localisation and content.

That framing fits closely with DesignWhine’s wider coverage. Our DesignWhine Guide to Design Systems sets out the broader architecture of components, tokens, code, documentation and governance; our practical guide on how to build a design system focuses on the operating model behind the library, while Why Design Systems Fail looks at what happens when governance and adoption break down. Diana’s perspective adds something those guides cannot: what the work feels like from inside a mature system.

Her own Indeed Design System case study describes work on components deployed across global teams. In the interview below, we have preserved her original answers and updated only the surrounding editorial context.

What Is Your Role at Indeed?

DesignWhine: Please introduce yourself and your role in creating the various design systems at Indeed.

Diana Wolosin: Hola! I’m Diana Wolosin, a proud Colombian designer currently living in sunny San Diego. I lead the design efforts for the Email Design System team at Indeed, which is part of the larger Design System. With over four years of experience working on design systems, I’ve had the opportunity to build them from the ground up at small companies and contribute to growth in large organizations like Indeed.

At this stage, the Indeed Design System is quite mature, and my team is focused on optimizing it to better serve our users and ensure it remains a powerful tool for our internal users.

How Does Mindset Affect Systems?

DesignWhine: You’ve spoken about your interest in mental attraction. Could you share more about this concept and how it might be applied to design systems or UX overall?

Diana: Yes, I’m a firm believer in the power of mental attraction, as I’ve personally experienced how focusing on specific goals with faith can help bring them to life. This mindset has had a profound impact on both my personal and professional life.

For instance, at the beginning of each year, I create a vision board to visualize my aspirations. One of my goals this year was to deepen my knowledge of AI in design systems. Amazingly, I had the opportunity to enroll in an AI class that was supported by Indeed, helping me move toward this goal. I also added goals related to improving my public speaking and storytelling abilities. This year, I’ve been fortunate enough to have several opportunities to speak in front of others, which has helped me refine these skills.

Mental attraction has touched every part of my life, and it’s a philosophy I carry with me in both my personal growth and my professional journey. I believe it can also influence how we approach design systems by setting clear intentions and focusing specifically on what we want to achieve, whether it’s building stronger stakeholder relationships, gaining more clarity around team goals, or fostering alignment within the design system ecosystem. Little things can significantly enhance the way we work and collaborate.

How Do You Balance Innovation?

DesignWhine: Design systems are constantly evolving. How do you balance the need for innovation with the technical debt that comes with maintaining a large, established system like Indeed’s?

Diana: Balancing innovation with technical debt is always a challenge, especially when managing a large, established system like Indeed’s. Tools like Figma have played a pivotal role in driving innovation, particularly with recent releases like Variants and Variables. These features have significantly shaped the foundation of our design system.

However, with innovation comes the need to refactor parts of the system. While some refactors are necessary to stay competitive, others can be less practical, especially when the cost of change outweighs the benefit. We’ve already gone through a major breaking change when Figma released Variants. Although I can’t take credit for that transition, I remember the incredible work done by my teammate, Stephanie Canales. She played a key role in planning and executing the transition, ensuring the users could adopt seamlessly.

Similarly, the introduction of Variables was another game-changing innovation for our design system. In this case, my teammate Keith Weston became the go-to expert for anything related to tokens. He helped shape the semantic token structure, which not only improved the system but also set the stage for future capabilities like theming.

That said, regardless of the technical innovations, design systems will always follow a product lifecycle that persists through time. It’s important to strike a balance between integrating new technologies and maintaining stability and integrity of the system.

DesignWhine: That tension now sits at the centre of mature system work. Our deeper guide to design tokens looks at why semantic naming increasingly behaves like a cross-tool contract, while our guide to design-system governance examines the ownership, migration and lifecycle decisions that determine whether those technical changes remain manageable at scale.

How Does Culture Shape the Work?

DesignWhine: As a Colombian immigrant, you bring a unique cultural perspective to your work. Have you found ways to infuse your heritage or personal experiences into the design system world?

Diana: Being a Colombian immigrant has given me a unique perspective that I often infuse into my work. Coming from a country where people work really hard and not everyone has equal opportunities, Colombians often develop a strong sense of resourcefulness and resilience, qualities that are essential in building and maintaining design systems. I am also highly aware of the importance of inclusivity and representation.

My experiences as an immigrant, navigating new environments and cultures, have made me more empathetic to users from diverse backgrounds. Understanding our users and their diverse needs is key to creating systems that work for everyone. Fortunately, localization and accessibility are also something that Indeed prioritizes, and I’m proud to work for a company that truly cares about inclusion and different cultures.

Even though I lean more toward the introverted side, I still feel a strong sense of pride and responsibility to uplift my heritage. Sometimes this shows up in subtle ways, like bringing vibrant energy to the team… or at least trying to! Occasionally, I’ll throw in a joke, and sometimes no one laughs, but then I remember: jokes don’t always translate well (That’s not going to stop me from trying!).

Through my years of working with people from different cultures, I’ve realized that while we all have our own quirks and cultural differences, respect is the universal language we all speak. I’ve been lucky enough to work in environments that embrace this diversity.

What Should New Practitioners Learn?

DesignWhine: What advice would you give to UX designers starting out on their design system journey, especially in terms of looking for inspiration?

Diana: My biggest piece of advice for UX designers starting their design system journey is to focus not only on developing technical skills but also on honing your soft skills.

Of course, learning the basics of design systems and mastering the necessary tools is essential. You need to understand how components, patterns, and documentation work together to create a cohesive system. However, what will truly help you grow professionally is your ability to navigate the broader picture; this includes project management, communication, and leadership skills.

Design systems are collaborative by nature, so being able to work effectively with cross-functional teams, manage stakeholder expectations, and lead initiatives is just as important as the technical side. These soft skills will allow you to move projects forward, align your team, and communicate the value of design systems in a way that resonates with everyone.

Inspiration is everywhere. Look beyond just design. Great design systems are a blend of creativity and organization, so find inspiration in architecture, nature, or even how other systems operate. What I love about design systems is that they’re not just a set of rules; they’re a mindset!

What Still Holds Up

The most useful part of Diana’s perspective is how little of it depends on one design tool. Variables and component architecture matter, but the recurring themes are migration cost, cross-functional alignment, accessibility, localisation, communication and leadership. Those are precisely the areas that become more important as systems mature.

They also become more important as AI enters the workflow. Our later argument that AI needs a design system before it can design coherently depends on the same premise Diana describes here: a system is valuable because it preserves organisational decisions, not because it contains polished components.

And as teams experiment with Figma MCP, Code Connect and coding agents, the technical layer is becoming more explicit. Our guide to making a design system AI-ready extends that conversation. What has not changed is the human requirement Diana emphasises: someone still has to align the people, maintain the system and decide which changes are worth making.