Industry

Customer Experience Management

Company

Sprinklr

Hyperspace Design System:
Designing for designers

Hyperspace
Design System: Designing for designers

Hyperspace Design System:
Designing for designers

What is Sprinklr?

Sprinklr provides enterprise software for customer experience management
(reviews, customer service chat etc.)

My role

Design Systems Lead

Responsibilities

  • Led and oversaw design systems at Sprinklr

  • Created and managed Figma components, tokens, and documentation

  • Diagnosed, planned, and resolved design and frontend workflow issues

  • Built processes to scale design systems work for 30+ designers

  • Mentored designers one-on-one and through weekly workshops

Impact

4x adoption of
library components

40% reduction of
code misalignment issues

Increase in designer
efficiency & happiness

The problems

Misalignment of process
Designers did not know what to do when they ran into component issues.

Over-reliance on local components
Designers heavily relied on locally created components, with an average of 20% of components being local. This practice introduced inconsistencies and increased the likelihood of designer error.

Minimal documentation
Nearly all components (99%) lacked usage rules or guidelines, leading to misuse and inefficiency.

Production design, not product design
The team was always caught up in granular component issues and not thinking about how to solve product experiences.

Move like water

Move like water

Move like water

As a Design Systems Lead, I worked to bridge the gap between leadership’s vision with the technical and cultural needs of the design system. By focusing on education, teamwork, and clear communication, I showed how well-built Figma components and a supportive team culture work together to ensure the system’s success.

Truth for everyone

Truth for everyone

Truth for everyone

Filling in the missing documentation for a design system used by 30+ product designers saved significant time. Clear, accessible documentation helped designers understand and use the system confidently, reducing confusion and the need for constant back-and-forth communication. Additionally, it made onboarding smoother for new team members and saved time by providing clear answers to common questions.

Thorough documentation included anatomy, specs as well as use cases and how to avoid common mistakes.

Thorough documentation included anatomy, specs as well as use cases and how to avoid common mistakes.

Thorough documentation included anatomy, specs as well as use cases and how to avoid common mistakes.

Important invisible things

Important invisible things

Important invisible things

In my opinion, what makes design systems work is not building the visual components. It's the unseen things like getting the team to understand the why the design system matters, how changes are made, and respect for the process.

I introduced educational initiatives, like workshops and daily office hours to help the team better understand the system’s purpose and best practices. Additionally, I established a feedback loop in multiple channels to identify recurring pain points and address root causes proactively. This approach fostered a culture of open collaboration, ensuring the system evolved thoughtfully and sustainably.

This is an example of a workshop educating designers on the details that could be missed. The topic was highlighting differences in the global nav and left rail design for Enterprise and Persona App user types.

This is an example of a workshop educating designers on the details that could be missed. The topic was highlighting differences in the global nav and left rail design for Enterprise and Persona App user types.

This is an example of a workshop educating designers on the details that could be missed. The topic was highlighting differences in the global nav and left rail design for Enterprise and Persona App user types.

Leading everyone onto the same path

Leading everyone onto the same path

Leading everyone onto the same path

Fixing the design system process played an important role in fostering a culture where designers felt their concerns were genuinely heard and addressed. By adjusting the workflow to include clear feedback mechanisms, the process shifted from being reactive to proactive. Designers gained confidence that their input on usability, consistency, and innovation would directly shape the system, encouraging them to voice concerns and share ideas.

Formalizing the process helped prevent teams and individuals from steamrolling their will and helped balance work in a way that encouraged healthy and objective discussions.

Identify the Need for a New Component

Understand the use case

Check existing components

Developer discussion

Considering the Component

Determine component organization

Define anatomy

Evaluate variants

Designing the Component

Design for decision driving

Accessibility considerations

Consider use cases for different sizes

Critique and review

Design peer feedback

UXR feedback

Developer feedback

Iterate

Apply necessary feedback

Deploy

Communicate with developer partners for implementation

Provide necessary details

Document and share

Write documentation

Communicate through various comms channels

Educate team through brownbag session

Library > local

Library > local

Library > local

Using Figma analytics, components with the highest usage frequency and highest rate of detachment were targeted first, ensuring the greatest immediate impact. This ranked list provided a base for designer interviews to reveal the root causes of detaching components. After resolving the issue, updates to the library component were socialized through team communications and brownbag sessions so that designers could stay on top of updates in more than one way.

By targeting the most used and most detached components, I was able to steadily shift designers away from using disconnected local components to design library components.

By targeting the most used and most detached components, I was able to steadily shift designers away from using disconnected local components to design library components.

By targeting the most used and most detached components, I was able to steadily shift designers away from using disconnected local components to design library components.

4x adoption of library components over a 1 year period.

4x adoption of library components over a 1 year period.

4x adoption of library components over a 1 year period.

Key takeaways

Key takeaways

Key takeaways

Advocating for resources and support

As the sole lead, I quickly understood the importance of advocating for additional resources, such as a dedicated engineer or another designer, to scale the system effectively and meet the growing needs of the team.

Education saves time

Not all designers had the same familiarity with design systems. I found that investing in training, onboarding materials, and one-on-one guidance helped bridge the knowledge gap, empowering the entire team to use the system effectively.

© Daiji Shikama 2024

© Daiji Shikama 2024

© Daiji Shikama 2024