Design systems — in the wild
If there has been one thing digital product designers have collectively drooled over in the past few years, it has to be design systems. And no wonder. The most developed design systems are the ideal of what we want our products to be — holistic, systematic and well-documented wonders. Some even come with their own branding and marketing. Tech giants, product houses and consultancies alike have thrown themselves on the bandwagon, enticed by the promises of lightning-fast delivery and a consistent design language.
But the truth is, many of these well-intentioned design systems fail in the end. Creating a design system is a lot of work. Often much more work than anticipated to get set up — not to mention the effort of actually maintaining and renewing the system over time. They quickly become stale, deprioritized, and ultimately abandoned.
So how does one reap the benefits of design systems, while guarding against the pitfalls that puncture so many? After joining a new project this fall and seeing the need for some sort of structure, I wondered exactly that — so I turned to the experts. On a chilly day in Oslo, Norway, I gathered BEKK’s finest to share their tips and experiences on what it was like working with the holy grail of digital product development — in the wild.
Their tips for those starting out:
First of all: Be sure there is a product/market fit.
Before you go gung-ho on initiating a full-scale design system, know what problem you are trying to solve, and the resources available for solving that problem. In this case, your market is an internal one, making it even more important to scope for a MVP. Many of the needs addressed by design systems can also be met with quicker, cheaper tools. Does your team need to get new members up to speed quickly? Pair-designing may be cheaper. More sharing between designers? Maybe Wake can fix your problem. Smoother hand-off between design and dev? Give Zeplin a try.
The same Lean principles you would apply to your product or service also apply to internal tools: find out first what the greatest need is, then find the tool or method that delivers that value in the easiest and cheapest way possible. When the mandate of your team is to deliver and maintain the client’s digital channel or product, it is important to start small, then build your way up to a full design system (if that is what your team needs). Sometimes, if your team is small or you have few products to share components between, just a sketch file combined with a zeplin project is all you need. Many of the needs that could be answered with a design system can also be met with simple tools. And that is ok.
Completeness is not the goal.
Now that you’ve determined a design system is the right way to go, the biggest challenge here is survival. If there is one thing that will guarantee the extinction of your design system, it is requiring every component in production to be a part of the system. Designers inherently want to experiment with new ideas, and have the flexibility to adapt existing components to a variety of contexts. Developers on the other hand prioritize a stable component library along with clean code.
Just as you need to define what combination of tools is the minimum required to meet your team’s needs, the same goes for the contents of your design system. Define what is most important to keep your product(s) feeling consistent and include those principles/guidelines/components in your system. Let the rest adapt to their surroundings. By only adding the most fundamental and universal components to your system, you can make the whole team happy.
Allow for rapid mutation
Deviation from the system is going to happen. This is healthy, and keeps your system growing and adapting to new contexts. Instead of fighting it, rig your system to tolerate a bit of experimentation, then make it easy to incorporate the experiments that work.
This process can look different for different teams, depending on your size and culture. Successful experiments could take the form of cards in a Trello board if your team is small, or you could adopt a more formal quarterly delivery framework with a dedicated design system team if your system has multiple product teams as users. But one thing is certain: if there is no routine in place for the renewal of your system… it will not happen. Having a flexible but structured renewal routine is key.
In addition, designers and developers alike should be able to update as much of the system as possible. This eliminates the bottleneck of always having to go through a developer to update simple things like examples, descriptions, principles and design files.
Make your system accessible and adoptable.
A beautiful, systematic, documented system has no value if no one wants to use it. Especially if you have a large team, getting others to buy in to and adopt the system can be big challenge. In the words of Lillian Ayla Ersoy: “Like any other product you are trying to sell, everything from name to accessibility is important. People have to want to use it. Having a good name that is easy to remember is a great place to start (Think Spotify’s GLUE). Make your system easy to find and reference with open links and easy accessibility.” Ryan Rumsey has written in-depth on this topic.
A design system is the result of an aligned team, not the other way around.
Though there are many ways to rig a design team depending on the organization, there are a couple of things to keep in mind:
- When starting out, training is a must. Take the time to on-board and train your team members with hackathons or playful tutorials. Many designers and developers (not to mention your client) are not used to working in this way, so take the time to let them get excited about this new way of working as well.
- Keep as few doors as possible between those who define the system and those who use it. Continuous and low-effort communication is key. Lots of bureaucracy tips the scales of value vs. effort of your design system, to where it becomes easier to work around the system than to use it. Make a slack channel for the design system or try a Trello board for requests and updates.
- Dedicated resources: Different organizational structures and team sizes allow for different types of teams when it comes to design systems. While resources fully dedicated to the design system is always easiest (especially at scale), it is possible to continually develop a design system on the side of normal project work. What is important is that there is a core team that feels ownership to the system. That team should be motivated to put in the extra work it takes to keep the system fresh, and willing to help others use it.
A note on tools
While the success of Sketch has toppled Adobe’s reign and opened the floodgates for design tools in recent years, none have quite hit the nail on the head — yet. New tools are being developed all the time with Sketch, Adobe, Invision and a myriad of startups leading the charge to develop tools to enable more teams with fewer resources to have their own design systems.
We are looking forward to a tool that shines when it comes to both building and maintaining a design system. Something along the lines of this would be optimal:
So… Where do I start?
Define your team’s needs.
What are you trying to achieve with this design system? What is your most urgent need, right now?
Get your team onboard.
Gather the troops and sell them on how, with a bit of effort, this tool will make their lives easier in the end. Get buy-in from stakeholders and put together a core team who feels ownership for the system.
Determine what is most essential to your brand.
This will be the start of your design system. Marcin Treder has written about a set of design system sprints, starting with an audit which can help you get started. Remember: the goal is not to capture a complete picture of every element of your product, but rather to find what makes up the essence of your brand and get alignment there first.
Build enough tooling
… to get alignment on those most essential things. The rest can come later. Try starting with a Sketch Library synced with Zeplin, for example.
Set up a renewal process
… that fits your team culture and speed of delivery.
Be inspired by some great design systems
… and see how they have made design systems work for their teams. Remember: one size does not fit all.
Credit where credit is due
This article would not have been possible without many enlightening conversations with my colleagues. A huge thanks to the 21 designers and developers who participated in the workshop, especially Maria Skaaden, Lillian Ayla Ersoy, Kent Andersen, Nicklas Utgaard, and Åshild Aaen Torpe for their experience, patience and willingness to share.
This is how we have made design systems work in our projects, what has worked in yours? Is there something we missed? Leave us a comment below and give us a 👏 if our experience resonated with you.
