This is all true and the shining light that has been put on Design Systems the last few years makes it a high priority goal for companies and teams. It is easy to learn about the best design systems out there, dig into their documentation, explore components, and bask in their beauty.
It is also easy to think this level/maturity of the Design System is what you, your team, or your company needs. In reality, most of you/us don’t work for a company like Google, IBM, or Shopify. A lot of us work for a company with a headcount under 10, some with a design team under 5, some who are a lone designer.
All of this boils down to is a single question to ask when starting your Design System journey.
“What makes sense for me/us/our company?”
We went through this challenge recently at my company and these were my biggest takeaways from what we learned.
1. Define the most important goals
What are the highest priority problems your Design System is going to solve? This will again depend on your specific organization and will be driven by different people. This could be an initiative driven by the design department or the CEO.
In our example the number one issue was consistency. We were in a flux period with a few complex legacy apps merging into one, a new one was spinning up, and more were being planned. Different teams had built these apps and we needed to bring them in line with each other sooner than later.
Number two was efficiency, we needed a way to improve design/engineer collaboration and workflow.
Defining this upfront can help establish a vision and principles for your system.
2. Start with the bare minimum
Once these top-level goals are defined you start thinking through what is the lightest weight version we can start with. Essentially define your Design System MVP. This is especially helpful if you are overloaded with day to day work and have to squeeze this in the cracks.
For us, this lightweight version ended up being a Typeface selection and tokens for
- Type sizes
- Corner radius
Then, we defined and type weight pairing, grid, icon set, form inputs, and buttons.
Our MVP definition was to have these defined and the apps using some of the tokens.
Originally we also had plans for a list of other basic components, screen templates, complex components, and flows, design system guild plans, documentation, update flow, etc. This is where I learned the most important takeaway…
3. Be flexible
It’s worth reminding ourselves that we work in the real world. Priorities shift, resources switch, and in general, situations are fluid which means we never have full control. That is a good thing, in my opinion, it pushes us towards a more collaborative and unique workflow that can be right for your company/team.
In our example, timelines and other factors on our engineer team required us to rethink a lot of what we had planned and scale back. This is where those two main goals helped.
Yes, we had to scale back.
Is it ideal? No.
Will the apps still feel consistent with our users? Yes.
Can we still be more efficient when collaborating? Yes, when the tokens are used.
Reframing back to those core goals and knowing they would be met helped me not be bummed out and stay excited with our progress.
Being flexible doesn’t mean losing sight of the long-term goals and vision, sometimes it just means a slightly different path to get there.
4. Embrace the continual improvement nature of a design system
We all know that Design Systems are never done. They are always evolving, being refined, and iterated on.
Remembering this helps us realize one size doesn’t fit all, ourselves included. This first version we released fits our needs right now. Will it next quarter? Next year? We don’t know, and that is the beauty and excitement of it.
By starting with a small and lightweight version we set ourselves up to meet immediate needs, deliver value right away, and scale if needed.
So what is the takeaway here?
Design Systems are powerful tools but they can seem overwhelming, especially at smaller companies. It’s also easy to compare yourself/team to someone like IBM and think your system needs to be at that same level of maturity.
Take a step back, evaluate your needs, and embrace the fact Design Systems come in all shapes and sizes. For your scenario just defining tokens could be enough to meet your goals. Then continually re-evaluate your goals and grow as needed.