Four collaboration lessons from the Jacobi Design System
The Jacobi Design System exists to connect all of our teams working on different components, functions and stages of the Clover Assistant’s product development. That, of course, means collaboration is essential to design system success. So for our first deep dive, let’s talk about some of the lessons we learned working together.
Lesson #1: Dedicate time and space for your design system
Like many design system owners on growing teams, I am responsible for so much more than the design system. At any given moment, feature-related work is usually my highest priority. That’s all the more true for other design system collaborators. Before even getting to work on Jacobi, overcoming everyone’s higher priorities ended up being our first lesson.
For myself, meaningful progress on the design system every week meant blocking out my calendar. For the team as a whole, that meant running a weekly design systems meeting block. Create the expectation with yourself and your team that regular design system work is a routine aspect of work.
Meeting blocks with the wider team proved effective, but collaboration still had to happen between meetings. Clover always had a Slack channel for Jacobi, but participation was initially lacking; posts were far and few between. One trick that proved useful: designating our #design-system Slack channel for all design and engineering collaboration. Since our scrum teams lacked a shared channel for communication across teams, async design system collaboration went through the roof.
Still, nothing proved as effective in engineering collaboration as our next lesson.
Lesson #2: Find a design system engineer
When I first started at Clover, I did what I could as a designer to deliver system improvements. The result was our design work moved faster and our design specs were consistent. Yet the product we shipped still suffered from inconsistency and repeated work.
Unfortunately, the engineering team had a long list of feature-focused priorities that got in the way of requisite, up-front design system work. Familiar story, I know. But we’ve since created a robust engineering-side design system despite continuing to have high-priority engineering work. So what changed?
Clover found Peter Agar, a front-end developer with a wealth of experience in design systems. While I was initially most excited for Peter’s expertise, his enthusiasm was what brought about the most effective change to Jacobi’s engineering side. Before, when a design system improvement was decided upon, it would disappear into the JIRA abyss. Now, Peter jumps at the opportunity to contribute and finds time to sneak in our improvements.
It goes both ways. As a design system power user deeply embedded in engineering territory, Peter is the ambassador of a key design system user base. Peter’s feedback, sourced from the engineering team as a whole, has allowed us to create system pieces and processes that better integrate across our teams. Bringing us to lesson #3.
Lesson #3: Feedback is the #1 measure of design system success
Another misstep in my early days at Clover: trying to create a fancy system for design system analytics. The reality was that maintaining (accurate) metrics was a manual process that only uncovered problems already being brought up by stakeholders. At that early stage, I learned that my effort building out analytics would be better spent tracking internal and external feedback and streamlining our collaboration with engineering. Especially as a design system owner working so closely with product development.
To design folk, listening to user feedback may sound obvious. On a design system, though, where feedback needs to continuously come from the same people, we learned that users also need to feel listened to. Initially, each piece of feedback would go straight into a prioritized list of design system to-dos; these days, we immediately close the loop on new feedback if possible.
Our last lesson gets into how feedback isn’t always so direct.
Lesson #4: Leverage desire paths
One of my first projects for Jacobi was establishing a component process. The first pass was a long and in-depth Confluence page covering all of our requirements and scenarios, while ensuring that all system additions would pass through the necessary stakeholders. I don’t think anybody actually read it.
If they did read it, it certainly didn’t show. For example, the process outlined that every new UI component needed to pass through a review panel with the design system owners and design manager to determine whether it should be systematized and documented as a Jacobi component. But because the team was accustomed to simply Jacobi-fying every time we used a component more than once, the process was forgoed in favor of what best fit our workflow.
Even I will admit to having skirted the process. Maybe more than once.
Revamping our component process, we learned to align with the team’s desire paths. Our new documentation even added a flowchart to reach those choosing not to read. With that, the component process became a formalization of what already worked in practice, and a quick way to onboard new members.
Thanks for reading. Our next post will cover how we created a more useful, usable, and accessible color system. Follow to stay updated as we publish each deep dive on how we built Jacobi.
