3 design system challenges no one is talking about
Design systems are all the rage now. They are widely considered a powerful tool to boost efficiency and brand consistency, and to eliminate brand and tech debt. So understandably, tech companies everywhere are enthusiastically putting their eggs in the design system basket. But design systems do come with their own set of challenges no one seems to be talking about.
In this article I will review 3 design system challenges myself and the team at Worthy have faced since deploying our design system — Clarity, and the best ways to deal with them.
#1 Cross platform deployment
You’ve finished developing your components and are eager to start deploying them. Fun! But when you get down to it you may realize that quickly eliminating your brand and tech debt by deploying your new components all across your platform is simply not an option. When developing design system components you’ll likely use relevant technology like React, which may not work properly with your existing legacy code. This is when you find yourself having to spend a considerable amount of time making adjustments to your existing code. Not a showstopper, but costly.
Solution: Researching your existing legacy code compatibility with your design system code while still in the planning phase of your design system’s life cycle is the best way to tackle this challenge. If you’re short on time try quickly developing a very basic, POC component and testing it all over your product. This can help you reach a lot of insights in a short amount of time and save valuable time later on.
#2 Keeping it going.. and going
A design system is never complete. It is meant to be a living, ever evolving organism. So simply designing and building it is not enough to make it succeed. Think about it, business needs change, companies grow and products evolve to reach new markets. So if you build a design system and just let it sit there, without constantly updating it, you may find yourself dealing with some newly accumulated design and tech debt. So always remember a design system is supposed to change and grow with the company and if ever it stops evolving and growing it becomes obsolete.
Solution: Maintaining a design system’s relevance, both design and code wise, depends on you and the processes and procedures you choose to put in place. Things like weekly committees to discuss the design and development on new components and the incorporation of component development in dev protocols are critical to keep your design system going. Prepare for this stage ahead of time by including it in your design system’s grand plan and training developers to use components and build them. You should also start spreading the word about your new design system as early as you can to get people on board and even appoint a design system liaison in relevant departments to get as many people invested in it as possible. Once updating and developing components becomes embedded in your day to day work, you’re golden.
#3 Component bugs and fine tuning
It’s easy to get the impression that once a component has been designed and developed, it is done. But when you get around to actually using it in your designs and incorporating it in your live product you’re almost always bound to find out its missing some attributes / states / steps. For example, when we were trying to implement our first ever component — a button. We quickly realized we had forgotten to include loading animation and the button was built without it. So we ended up having to put the feature on hold until we got the animation working. Then, something similar happened with our input field component. This time the problem was the way the component was built. When we tried using it we found out it doesn’t actually work and had to spend some time fixing it. So bear in mind that a design system component is only really complete after it has been designed, developed and used at least once.
Solution: Spending some extra time on planning your components should help avoid such setbacks. Document all of your components in a spreadsheet and list the different states they should have. Share it with your team (developers included!) to make sure you’re not missing anything and to make sure you’re all on the same page. I would also recommend setting aside some more time for their initial implementation to cover all of your bases and bring unexpected delays to a minimum.
To conclude, a design system is a wonderful tool to boost efficiency and maintain consistency. But you have to plan ahead. Deploying a design system to your product and then constantly updating it are key steps in insuring its long term success. It is a continuous project that will always require some resources, fine tuning, periodic maintenance and governance. So if you’re done building your design system — that’s great! But remember, your’e in this for the long hall. In fact your work has only just began.
