Design Systems have been booming all around the tech world. Frameworks based on components and overall market need for brands to communicate the same image throughout products and channels have made design systems a popular dream between big and growing companies. Normally, the design system gathers the companies' shared components and elements that need to be reused on different apps, web platforms, Instagram campaigns, Power BI dashboards, you name it. So, to be more specific: buttons, lists, tables, colors, fonts ... Pretty much all you need to have a coherent look for the brand on a product and communication level.
The thing is, even though design systems are a very cool thing, the practicalities on how to operationalize it are still a hard thing to crack. That is because there is a complicated puzzle at the center of this whole discussion. The bigger the company, the more important to have a design system. After all, bigger companies have different products on different platforms and teams spread on different places on earth. However, the bigger you are the harder it is to make an effective design system exactly because you have different (already developed) products and different systems all around.
I have experienced first hand putting together a design system in a huge company with many different products and let me tell you, that is a hustle. If for one side you need to centralize the designs somehow, on the other you can not depend only on the design system team's workforce. Besides that, in a big company, different design needs came from different business' contexts. Also and perhaps even more problematic, when we talk about components there is a matter of implementation. Can you imagine one team being responsible for the components' design and implementation of more than 40 products? It is virtually impossible.
After starting working with this, I got the habit of going into cool companies' design websites. Many of these companies keep a .design domain - such as Spotify, Google, Airbnb, and Facebook - in which they share articles and news on their design systems. By benchmarking that way, I noticed that when it comes to this topic there is no one size fits all solution, unfortunately. And normally the approach is iterated many times. I believe that finding the sweet spot between centralizing the design and simplifying the production pipeline depends on how your company is already shaped and how much adoption you are going to find in it.
It is important to take into account that the design systems won't live outside your development process, so the rules of that development flow will apply to it as well. For example, one thing that we know well in the tech development world is that rooted legacy systems make everything harder. I would say that depending on how much legacy you have, the more realistic you need to be on your design system's potential reach. Do not go around talking about the component library and other cool-modern things if your system was build using something old, like AngularJS or PHP monoliths. In that case, I would say that there is a need to have an honest conversation between development and design on how far can we go with the unification. The trick in that situation, I believe, is to remember that the goal is to have a coherent design and even though it may seem that a component library is the only way to do that, that simply isn't true. A component library can't guarantee the success of your design system, neither its absence will necessarily result in its failure.
The situation is, of course, different for new companies. In that case, I believe that the design system should be developed from the early days on its full glory. The catch here is that early-stage companies are fully focused on survival and the rest seems secondary, but that is exactly the right time to start building good foundations for the future. Investing in openly sharing within the organization a component library, version-controlled design files, and code, will payout in the future, for sure. Having a reviewing process that expands the individual teams can also work as a way to generate accountability to the unified design guidelines.
Finally, on a more practical note, one common thing that is useful for building a design system in any size company is to offer well-documented guidelines. You may or may not be able to provide assets such as components or things like that, but you can always offer complete and clear documentation on what is the unified design patterns that represent your company as a brand. Also, the design team should always see themselves as a support system inside the company. Talented people are working on different teams and these people are probably the best at understanding that product and team-specific need. There needs to be trust, a rigorous accountability system, and clear communication so that a coherent design can be developed throughout the teams in a seemly organic way.
Top comments (0)