Ansarada design system (ACE) usage retro

Role: Product Designer, design systems and DesignOps
Product: ACE (Ansarada common elements), the design system behind Ansarada’s platform
Initiative: A structured usage retrospective to understand why adoption was inconsistent, and to reset how teams work with the system
My contribution: Retro design and facilitation, research synthesis, adoption roadmap, tooling evaluation

---

ACE is Ansarada’s design system. It defines the visual language, interaction patterns and components used across the product. On paper it was the source of truth. In practice, every team had its own version of that truth. Some leaned on it heavily, others worked around it, and the gap between the two was slowing delivery and weakening alignment between design and development. Instead of pushing more components or stricter rules, I ran a structured retrospective to understand how teams actually experienced the system, then turned that understanding into a concrete adoption roadmap. The most valuable design work here produced no interfaces at all. It produced alignment.

The problem

ACE was intended to unify how we design and build. Instead, it was being interpreted in different ways across the organisation, and the symptoms were showing up everywhere:

• Inconsistent use of components across teams
• Unclear expectations around when to create new patterns versus reuse existing ones
• Designers spending their time on UI decisions instead of interaction thinking
• Gaps between design artefacts and what development actually shipped

The important realisation was that the issue was not the design system itself. The component library was solid. The problem was how people consumed and worked with it. That distinction changed the entire shape of the project: this was a people and practice problem wearing a tooling costume.

Vision

The goal was to shift design effort away from crafting interfaces and toward understanding customer problems. In the model we were working toward:

• 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 the decisions are clear. ACE becomes the shared language that connects product, design and engineering, rather than a library people visit occasionally.

Goals and hypothesis

We wanted teams to move faster without sacrificing consistency, default to existing components with confidence, spend less time recreating UI patterns, and genuinely understand what ACE contains and how to use it.

The hypothesis was simple: 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.

1. Understand current perception

We explored what ACE meant to different team members, where adoption was breaking down, what felt difficult or unclear, and what people were quietly working around instead of with. This surfaced the gap between the system’s intention and its lived reality, and it did so in people’s own words rather than through assumptions.

2. Facilitate a design system retro

I ran a structured retrospective with cross-functional contributors: designers, engineers and product folks together in one session. Participants reflected on what we should start doing, stop doing, and continue doing. Crucially, each contributor talked through the thinking behind their submitted notes, which turned surface-level feedback into genuine discussion. The framing mattered: the goal was shared understanding, not critique of the system or the people maintaining it.

3. Identify actionable themes

Through synthesis we identified the friction points preventing adoption, opportunities to simplify usage, areas where documentation or guidance was missing, and misalignment between design practice and tooling. This step turned abstract frustration into a concrete, prioritised list the team could actually act on.

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 the React components, compatibility with existing infrastructure, effort to implement versus benefit gained, and the learning curve for teams. The intention was to reduce translation between design and development wherever possible, because every translation step is a place where consistency leaks.

Outcome

The retro created clarity around how ACE should function within the design practice:

• 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. The retro’s findings became the foundation for the ACE documentation enhancement work that followed (Parts 1 and 2), so this project was the diagnostic phase of a much larger system evolution.

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.

---

Frequently asked questions