Strengthening adoption through shared understanding
ACE (Ansarada common elements) is Ansarada’s design system. It defines the visual language, interaction patterns and components used across the product.
While ACE existed as a source of truth, adoption across teams was inconsistent. Designers and product teams were using it differently, which created friction, slowed delivery and weakened alignment between design and development.
This project focused on understanding how teams actually used ACE, identifying barriers to adoption, and creating clearer practices around how the design system should support everyday product work.
The problem
ACE was intended to unify how we design and build, but in practice it was being interpreted in different ways. Teams understood the system differently. Some relied heavily on it, while others worked around it.
This led to:
- Inconsistent use of components
- Unclear expectations around when to create new patterns
- Designers spending time on UI decisions instead of interaction thinking
- Gaps between design artefacts and development implementation
The issue was not the design system itself. It was how people consumed and worked with it.
Vision
The goal was to shift design effort away from crafting interfaces and toward understanding customer problems.
In this model:
- Wireframes become the primary design artefact
- Interaction thinking happens early and deeply
- ACE provides the visual and interaction foundation
- New components are introduced only when genuinely needed
Designers focus on behaviour and experience first. Visual refinement happens later, once decisions are clear.
ACE becomes the shared language that connects product, design and engineering.
Goals
We wanted to enable teams to:
- Move faster without sacrificing consistency
- Default to existing components with confidence
- Spend less time recreating UI patterns
- Better understand what ACE contains and how to use it
Ultimately, the aim was momentum through clarity.
Hypothesis
If we clearly define how designers and product teams should work with ACE, teams will spend less time designing interfaces and more time solving customer problems through interaction design.
Approach
Rather than prescribing solutions immediately, we started by listening. The work centred around a collaborative retrospective designed to uncover how ACE was experienced across the organisation.
1. Understand current perception
We explored:
- What ACE meant to different team members
- Where adoption was breaking down
- What felt difficult or unclear
- What people were working around instead of with
This helped reveal gaps between intention and reality.
2. Facilitate a design system retro
A structured retrospective session was run with cross-functional contributors.
Participants reflected on:
- What we should start doing
- What we should stop doing
- What we should continue doing
Each contributor shared their thinking behind submitted notes, allowing deeper discussion rather than surface-level feedback.
The goal was shared understanding, not critique.
3. Identify actionable themes
Through discussion and synthesis, we identified:
- Friction points preventing adoption
- Opportunities to simplify usage
- Areas where documentation or guidance was missing
- Misalignment between design practice and tooling
This turned abstract feedback into concrete action points.
4. Explore tooling and workflow improvements
Alongside the retro, we investigated ways designers could work more directly with up-to-date ACE components.
We evaluated:
- Design tooling aligned with React components
- Compatibility with existing infrastructure
- Effort to implement versus benefit gained
- Learning curve for teams
The intention was to reduce translation between design and development wherever possible.
Outcome
The retro created clarity around how ACE should function within the design practice.
Key outcomes included:
- Clearer expectations for when to use or extend components
- Improved understanding of ACE as a shared source of truth
- Identified opportunities for better documentation and token usage
- A roadmap for improving how teams consume the design system
More importantly, it shifted the conversation from maintaining a system to enabling better product thinking.
What this project demonstrates
This work reflects an early shift toward systems thinking in my practice. Design systems are not just libraries of components. They are organisational tools that shape how teams think, collaborate and make decisions.
Sometimes the most valuable design work is creating alignment, not interfaces.Suggested image placement Since this project is workshop and systems focused, visuals should support collaboration and thinking rather than polished UI.
Leave a Reply