Working in the corporate industry has taught me many things, one of the most challenging lessons to learn was how to deal with minimal support and resources. The unfortunate truth is that there are many underfunded or undersold projects; as a design system designer this has never felt more true.
I work in a small design system team (there are four people max, including myself) with an enterprise level design system to build. As there is no option to hire more people, the second best option was to take contribution from non-design system designers. On paper that sounds wonderful, we could have a sort of centralised-federated design system that people lovingly donate their time and components to. Except this was never going to be the reality; what seemed like a “free” resource to the organisation had issues elsewhere:
If a project or product is not valued by senior staff and the c-suite, why should a regular designer care?#
This one seems quite obvious to me but if the smallest voices in the room are the only ones who seem to care about the design system, chances are other members of the organisation won’t care all that much. This is why buy-in from senior staff is so important, it really helps when you have a more powerful champion on your side.
People, especially busy people, don’t want to do extra work they are not getting paid or reimbursed for#
Asking people to do more than their jobs can be tricky, unless the order is coming from their manger or its in a dreaded OKR/KPI/other acronym for goals. This means that to get people to work on the design system it should be as part of their existing workload and benefit them somehow; or they have to care about the design system itself (chances are, it is the former).
Non-design system designers do not have all the functional knowledge to entirely relieve the design system team of a task#
Alas, contributing to the design system isn’t as easy as making a few changes to a Figma branch. It requires system knowledge as well as the some understanding of the design system governance and standardisation. After the initial work is done there is typically a review process, depending on the task, person, quality, background knowledge, etc this can take a while.
Where are the hidden costs?#
The cost of building a design system this way adds up. The hours spent reviewing work, amending designs that did not meet a particular standard, or simply wasn’t consistent enough with the existing content all take up time. The teaching and templating required also adds to the that cost and slows down the core team from working on other things. Despite a smaller upfront cost to the business, there is also a high risk of the design system work being deprioritised. This can cause blockers or at best become stale.
Are there any benefits to working with a centralised and contribution model?#
This way of building a design system doesn’t come as a complete challenge. Combined with governance and human connection I have been able to develop aspects of the design system (that have been actually needed) with subject matter knowledge; this is due to the product specialists contributing their time and designs to the design system.
The more human aspect of managing a design system has allowed for collaboration across multiple products. The messaging has been focused around building a design system that people want for the designers and product in question. This has been a Herculean efforts but has meant that I now have built trust with my fellow designers.
Although this approach to building a design system has some hidden costs associated with it, it can work. You can even increase collaboration and contribution with non-design system designers as well as get a few more people to care about your humble design system.
⋆˚｡⋆୨୧˚Thank you for reading my post ˚୨୧⋆｡˚⋆