Running a Design System team like a Product team
Imagine Design System is a product and service that serve your company’s designers and developers, how would you make this product and service to compete with the Material Design for designers and Bootstrap for developers?
You indeed need buy-ins from management level to get people to use it, but if you put that on the side, you are still in the market that is filled with great open-source design systems like Material, Lightening, Carbon, etc. So, how do you ensure that your users, designers and developers, are not going to use those well-crafted libraries, but yours?
The Team
Well, first, you will need an essential team that can create that product and provide that service. NN/g recommended a minimal team would have at least one senior interaction designer, one senior visual designer, one UX developer. This team will only get you started with the product; however, to have a great system that can compete with the others in the market, it’s ideal to have at least one UX/product designer, one developer, one QA, one technical copywriter, and one sales engineer. These positions make up a product squad that you can expand later as the system grows.
The Product
As we all know, a design system consists of design, documentation, and code. Regardless of the design tools, Sketch, Figma, or XD, that your organization is using, it’s the UX/product designer’s responsibility to create the components using that tool(s). If your organization is using multiple front-end frameworks, you might need to expand the development team to create relevant code snippets. QA comes in importantly in terms of visual and code quality, as well as accessibility. Although the whole team should have accessibility mind when building components, the QA is the last door when shipping a quality system. Documentation is another important piece of the design system. Whether the rationale behind a design decision or the comment on the use of a code snippet, it’s important to document them and make it easy to read by a technical copywriter. Well-crafted documentation can make a lot of technical conversations much smoother.
In order to keep the system living and breathing, regular sprints and releases are critical. With each release, it can be design updates, code updates, or some documentation updates. The resale notes or the announcement will keep your system in sight of designers and developers. It’s exciting to see your system goes from one star to five in the App Store and Play Store. Just kidding.. we don’t release that way, but you get the idea: a regularly scheduled release keeps your product living, breathing, and in-sight.
The Buy-in
Although some teams might have management support to use the design system across product teams, some teams might not be that lucky. In order to break the silo, the team will need to sell your system to your designers and developers. So here is where a sales engineer plays an important role, where he/she can conduct workshops, demos, and even campaigns to promote the design system. A sales engineer usually knows the technical details of the system as well as the users’ needs.
The service
Once the designers and developers are on board using the system, it’s important to keep the service up with different channels, ex: Slack, email, and in-person. It’s too extravagant to have a service team with a 1(800) call number, but the team should be able to handle the feedback, bug, or feature request from your users. And those are more direct and qualitative user messages to your team, which is very valuable to improve your system.
In conclusion
We all know that it takes great effort and resources to make a good digital product in the market that has its place. So does a good design system. When we stop treating a design system as a side project or a support team within an organization, the design system would be at a better place just like other products that we care about and craft. So let’s get back to work and care and craft the design system that we all love in your organization.
