How do we involve developers in the Design System before asking them to write code
Introduction
When we tend to evaluate any design design, we try to look at it’s success by only looking at the adoption, but also how effectively it supports and engages developers.
It is obviously to meaningfully include the devs before delving into the implementation details to make sure they understand the core functionality and purpose of the components, and they can give you more feedback based on codebase and other points.
This is based on my observations made after constructing a Branch Metrics design system. This design system was constructed with anything we felt was necessary for our product in mind.
But once it was finished and developers got to work putting it into practice, we got together once more to make a few adjustments, and those few meetings gave me further insight into why it is crucial for designers and developers to work together rather than handing off.
Next, in order to close the gap between design and development at this crucial post-implementation phase, we scheduled a call.
Placing Oneself in the Shoes of Developers
Consider the situation that a developer might face while starting a design system project. You have a design system full of your own designs and components at your disposal, together with a rapid knowledge transfer about what will be utilized where and when it is really implemented.
You’ve attempted to understand it on your own, but there’s a persistent problem that keeps you back. That’s when discussions comes into play.
We begin by comprehending how developers ask questions, what are the things they have in mind, and you together build a new and more inclusive mental model. We are aware of their difficulties and the chance to turn uncertainty and annoyance into fruitful cooperation.
Encouraging feedback
When developers run into difficulties, they can leave a comment in our Figma comments section, and I can review and attempt to fix it. This acts as a safety net for them. These channels serve as lifelines in situations where documentation is inadequate or components exhibit unexpected behavior.
They remain active until the issue is fixed or another person experiencing the same issue can observe the progress. It is crucial to encourage developers to pose questions.
When they do, it’s important to express gratitude. Has a bug been discovered? I’m grateful they noticed it. Do the papers make sense? Thank them for their input. Uncertain about how to utilize our components? Together, let’s solve this.
Someone becomes a hero when they report a problem. This kind support helps us achieve the desired behavior and contributes to a more robust design system. It helps you understand, it’s not just yours, it’s a collaborative thing which needs attention from everyone.
Celebrating Questions: Encouraging Engagement
Our Figma comments serve as safety nets for developers encountering hurdles, they post a comment at the point and I can go back and try to resolve them. These channels are lifelines when documentation falls short or components behave unexpectedly, and they stay there until it is resolved or someone else encountering the same thing can also see the progress. Encouraging developers to ask questions is paramount.
When they do, it’s essential to show appreciation. Did they find a bug? Thank them for spotting it. Are the docs unclear? Express gratitude for their feedback. Don’t know how to use our components? Let’s work through it together.
When someone files an issue, they become a hero. This gentle encouragement fosters the behaviour we desire and contributes to a more robust design system.
Beyond Support
Support transcends answering questions; it’s about fostering a sense of community around the design system. By providing access to documentation, design specs, and aligning in the code, we alleviate the need for teams to create and maintain these resources themselves. Additionally, we ensure that when teams face issues, they’re not alone. They’re part of a collective, where mutual support is the norm. Witnessing teams collaborate and assist one another is a testament to the strength of this community. Support is not just about resolving individual problems but continuously reaffirming our commitment to all consumers.
Performing at Two Levels: Systemic and Immediate
I designed the dashboard and managed the design systems autonomously as part of a very small team. I provide assistance by taking care of both the immediate problems and the underlying systemic problems.
These two procedures operate simultaneously but take different approaches. Urgent issues deserve our rapid attention. Whenever a developer files a bug, I set aside a specific period of day to evaluate everything, make any necessary adjustments, and then notify the developers over the Slack API. If they need to make modifications as well, I raise a Jira. Developers are blocked; each day, we have to figure out the best way to let them proceed.
But we also need to think about the bigger systemic issues that caused the problem. Systemic answers are frequently needed for these systemic problems, but they take time to put into practice. Keeping both in check is crucial. Efficiently address urgent issues while upholding standards and reducing technological debt. Concurrently, start talking about systemic changes to create the groundwork for long-term gains.
Conclusion
Perfection in the field of design systems is hard to achieve. It’s possible that your system will never fully reflect your or your customers’ desires. On the other hand, a strong support network may fill in the gaps and guarantee that teams receive enough assistance. Although procedures change as the system does, developing a support mentality never changes.
Effectively including developers in the pre-implementation stage creates the conditions for a design system that flourishes and enhances the spirit of cooperation between developers and designers.
