Episode #48: Scaling Product Quality Through Design Systems with Kelby Hertanu

A design system is not only a library of reusable components. It is also a way to help teams deliver coherent product experiences while reducing repeated decisions. In Episode 48, Asana product designer Kelby Hertanu explains how systems thinking, customer evidence, internal support, and cross-functional communication work together.

What you'll learn

• How Kelby moved from graphic design into UX and design systems

• What documentation and component alignment contribute to product quality

• How customer research, A/B tests, and dogfooding answer different questions

• Why a design system team must research its own internal users

• How to explain design choices to engineers, product managers, and designers

Move from individual screens to scalable decisions

Kelby grew up in San Jose and was drawn to digital art before studying graphic design at Cal Poly San Luis Obispo. Near the end of that program, he began teaching himself UX because he wanted to work in the Bay Area technology industry. His first UX role was an internship at Mindbody while he completed school.

Google's introduction of Material Design influenced his view of product design. He saw the work as solving user needs through choices that could remain flexible and scale. Even before design systems appeared in his job title, systems thinking informed work across digital collaboration tools and financial technology.

That background led him to focus on design systems at Asana. His aim was broader than creating a successful experience for one user flow. He wanted to help other designers, make their work easier, and support the business through consistent foundations. The progression is useful for any product designer: look beyond whether a screen works in isolation and ask whether its decisions can be understood, reused, and maintained elsewhere.

Treat the design system as product infrastructure

Kelby's day-to-day work moved between documentation, Figma, code alignment, planning, and direct support for feature teams. He might update usage guidelines for components and patterns, then align Figma components with coded components through properties that reflect the component API.

The design system team also worked with product teams during feature releases and throughout product development. The goal was to help those teams move faster and maintain quality while producing solutions cohesive with the rest of Asana. This matters in a work management product where tasks roll into projects, projects into portfolios, and portfolios into goals. Product surfaces have dependencies, and users bring expectations about how interactions should behave across them.

Kelby described Asana designers as attentive to visual design, interactions, and micro-interactions. Yet detail does not eliminate coordination. Teams working on different surfaces need to collaborate because changes in one place can affect another. A design system provides shared guidance, but the people maintaining it must stay engaged with the feature work it is intended to support.

Use evidence that fits the risk

Kelby outlined several feedback loops rather than one universal test. Across Asana, a UX research team developed a voice of the customer by combining inputs, understanding user needs, and prioritizing them to inform the roadmap. Product teams also used A/B testing to measure the effect of design choices instead of settling questions such as icon selection or placement through internal argument alone.

Before release to customers, teams used dogfooding by making features available to Asana employees, who use Asana for their own work. Kelby was careful about the limitation: employees are not the customers. Internal use is still valuable for stress-testing features, finding places where something might break in production, collecting immediate feedback, and increasing visibility into what product teams are building.

These methods serve different purposes. Customer research helps identify and prioritize needs. A/B tests compare the effects of alternatives. Dogfooding can expose operational problems before release. Choosing among them begins with the uncertainty the team needs to reduce, not with a default attachment to a particular technique.

Research the designers and developers you serve

For a design system team, the immediate users are internal designers, developers, and product teams. Kelby's team held office hours and offered support channels so those users could explain what they needed. Tight qualitative feedback loops helped the team check whether its work was actually being used to improve the product.

The team had also started examining component adoption and deprecation across the codebase. That creates a more concrete view of whether components are spreading, lingering, or failing to replace older patterns. Kelby said the team was still scaling its ability to test component variations, which keeps the account appropriately grounded: measurement was developing, not finished.

Translate design reasoning for each audience

Kelby identifies articulating design decisions as an enduring challenge. Engineers may care about technical effort and code hygiene. Product managers may think about scope and product impact. Designers may discuss contrast, composition, layout, color theory, or detailed conventions around an icon.

The same rationale therefore needs different framing. Clear communication does not mean stripping away design judgment. It means connecting that judgment to what the audience must decide. Kelby also discusses imposter syndrome as a signal to examine what specific situation is creating doubt, rather than treating the feeling as proof that he does not belong.

Listen to Episode 48 for a practical account of design systems as internal product work, supported by evidence, adoption signals, cross-functional collaboration, and careful explanation.