Designing a Contribution Model within organizational constraints
During my time leading AXIOM, the Edward Jones design system, the DesignOps team was responsible for setting, and maintaining design standards. We (DesignOps) supported roughly 60 designers and nearly 300 developers across a large product ecosystem.
As the design system lead I knew that to ensure AXIOM stayed an evergreen design system, we needed a healthy feedback loop with product.
We needed contribution from between product designers and developers and the system. Getting there, required designing a contribution model specific to the Edward Jones organization.
It wasn't going to be easy...
Myself, along with the rest of DesignOps always saw our designers and engineers as our first customer. We wanted to empower them to be creative, maintain design excellence, and generally make their lives easier.
However, at the same time designers and engineers wanted more engagement, executives expected greater stability, predictability, and lower risk. They increasingly expected our small DesignOps team to account for every penny we spent, discouraged us from "taking time away from designers", all while while expecting we be the voice of designers at Edward Jones.
The decision of what to work on was also not up to us, and everything required heavy stakeholder buy-in, in a Shark-Tank-style PI ceremony where DesignOps presented business cases and stakeholders needed convincing. If DesignOps didn't have the right data to back up what products needed next, it was never gonna happen.
In my opinion, designers and developers should have been involved in voting on what we do. In any case, embedded in product teams, designers were working on real user problems and it was our job to support them.
We knew many of the design solutions those teams were building had reuse potential — which is easy math in economies of scale. But could we prove it ?
The constraints
We needed a contribution model that protected our high standards, allowed us to prove demand, and was easy enough for designers to want to use, amid their endlessley complex day as a product UX designer.
The question became what data can we get, asynchrnously, without having to interact directly with designers?
As Figma organization admins, DesignOps had visibility into how components
were used across files. We could inspect frames asynchronously. We could
comment directly in context. We could see where patterns were emerging.
Figma became the connective tissue between the design system and product
teams. It made asynchronous governance possible and gave me an idea.
The Experimental Library
The solution was to introduce a middle state, introduce a service level agreement that explicitly removes our high obligation of stablity. In software, essentially this meant a "beta" version of the design system.... but the
service level agreement was explicit: these patterns show promise, but they are not yet AXIOM standards, and may never become AXIOM standards... USE AT YOUR OWN RISK.
The submission process:
- A designer opens a branch in the Experimental library
- The proposed component, or other design solution, is added with rationale and research
- A Jira ticket is created, and now we have an async communication channel with that designer via comments (metric)
- The design system team reviews
The criteria
We evaluated contributions against these questions:
- Does AXIOM already solve this problem?
- Does it align to existing standards and tokens?
- Is it technically feasible?
- Is it durable, not trend-driven?
- Is there research or evidence of success?
- Does it demonstrate reuse potential?
The platform:
When a contribution met the criteria, it was published to the Experimental library immediately.
Once published, the broader design community could use it in real user tests, and in their workflows.
By using Figma analytics and direct feedback, we could observe adoption across teams, and inspect implementation contexts.
We were able to bring this data to our stakeholders, to advocate for what our designers needed. Within tight organizational constraints, we built a model that protected standards, proved demand, and allowed AXIOM to scale deliberately. As trust grew with the process, we were seeing a quicker feedback loop, and greater collaboration and empathy throughout our network.
Final thoughts
I wanted to be frank about the realities I faced, because this situation drives home the belief I have that design systems are an artifact of culture, and organization. Edward Jones happened to have a very careful, siloed culture that made fast iteration and innovation particularly challenging. Every design system's challenges are different, and this is a good thing! The flaw would be to expect every design system to be the same, thereby miss boutique opportunities, and reducing a powerful differentiator to a common cog.