Having a Design System can increase your productivity by up to 50% (Kluver, 2019), and get you to market up to 65% faster (ElevenSpace, 2024). Understanding if you need a Design System, and when the right time to create one is, can be of vital benefit to your organisation by saving time and money.
Do I Need a Design System?
A Design System is worth considering, if:
- You are reusing something, anything, and are designing or building it from scratch each and every time, OR,
- You have different products or applications doing the same thing in different ways
If you don’t start thinking about having a Design System (and efficiency more broadly) you will end up with a digital development team who are rebuilding the same things repeatedly, wasting your organisation’s valuable time and money. This wastage is exponentially worse when you have multiple digital teams or a larger enterprise-scale digital team. If you want your digital development team to move fast, you need to provide them with every tool and capability you can to help them move.
In the first post of the series, Intro to Design Systems, we discovered that treating your Design System like a product, and striving to find the right product/market fit is important. This product-led view is valuable from the standpoint of what your Design System should contain (the components), as well as how it should be experienced by your digital design & development teams (the user experience). Taking this product-led view, your Design System can work for your organisation, bringing the productivity and speed-to-market benefits you read about above.
So do you need a Design System? Yes.
What are the Pains a Design System could help with?
A Design System can have beneficial impacts to many different facets of your digital development operations. Below are some concerns that may prompt a rethink about your digital capabilities (including Design Systems), loosely categorised into four groups, are:
- Digital Development Team Challenges – these are the things that come from within your digital design and development teams:
- Slow design and development cycles: repetition or duplication of efforts means longer for your teams to get to Done.
- Increasing levels of tech & design debt: versioning is difficult, you are always ‘behind’ the new version of something, or you have tons of legacy code bloat in your platform.
- Friction between designers & engineers, or collaboration between the teams is troublesome: design and development teams are not working together to create a usable Design System (for both end-users and digital teams) leads to friction.
- Release management is cumbersome: slow dev cycles and versioning issues (among other things) lead to release management nightmares.
- Testing is taking longer than expected: re-writing tests every time you rebuild a component takes longer to get to ‘Done’. Also, varying levels of testing and test quality lead to longer test cycles.
- Debugging is a nightmare: there are so many lines of code, and they all do something, but trying to figure it out is like trying to unpick a giant knot of wool.
- Organisational Challenges – these are the signs that might be felt beyond just your digital design and development teams:
- Long onboarding times: specifically in design and engineering, as new team members find it confusing and difficult to navigate through code or design tools/libraries and understand the processes used.
- Quality is patchy: quality testing is only as good as your most thorough teams as your standards are likely inconsistent between teams or people.
- Difficulty scaling teams out: you’ve tried to expand your digital teams but are having trouble with knowledge getting lost or a few people being blockers as they hold everything together.
- Low team morale or high turnover: Unhappy designers and developers – ones who feel unsupported and like everything they are trying to achieve is slow and difficult – will leave, costing your business in the endless recruitment cycle.
- External Challenges – these are the concerns that come from beyond your organisation, from your users or the market:
- Inconsistent User Experiences across products: when a User needs to do the same action in two different ways, they will get confused or annoyed by the inconsistency
- Increased support calls/tickets from users: time is spent assisting users to navigate the application or platform they are using as tasks are not easy or intuitive to complete
- Decreased speed to market: Meeting the demand of your users fast enough, or keeping up with the competition feels impossible
- Business Event Triggers – these are some specific scenarios that might make you consider if now is the right time to start your Design System:
- Are you about to scale your dev teams?
- Have you just launched a product?
- Do you want to refresh your products’ UX/UI?
- Are you looking to build multi-tenancy (or multi-brand) into your product?
NB: Business events within your organisation should trigger a rethink of your digital product development processes beyond just a Design System, but if you are considering a Design System, they also mark a good point for this.
Many of the pains above can also be symptoms of other things going wrong with your digital development. Be mindful that a Design System isn’t the only solution to these issues.
Organisations with these pains may be tempted to solely target delivery processes and aim to “fix” those. However, when you see these signs, consider all the possibilities: consider your delivery process, consider your technical environment or capabilities, consider team culture and morale, and consider anything else that may be at play here too.
So WHEN Do I Need a Design System?
You really need some form of Design System as soon as you replicate something (anything) in your digital product development process. Taking reusability and a product-led view as some first principles will help to guide you to the right Design System solution for your organisation.
Most commonly with Design Systems, this ‘something’ is a UX/UI component reused within your apps or platforms. However your ‘something’ could also be a boilerplate for development, a microservice, an analytics helper method, or a standard development pipeline – anything that would be rebuilt each time if it wasn’t componentised. (NB: Really the term “Component System” or “Component Libraries” is also relevant here as it could be more than Design-related).
No two Design Systems are the same. The scale of your organisation, your applications and platforms, the problems you solve for users – all of these things will mean different things belong in your Design System. The Design System that fits your organisation may be 3 components, or 300 components. It may be open-source or custom-built, or a mix of both. See the previous reference to Product-Market fit to find the right thing for you.
Start by looking for things that can be reused between teams (or people) in your digital development functions. How often are your digital teams doing the same thing over and over again? Take that ‘something’, and systematise it. Think about how much time and money you can save your business by doing this.
A Final Word
Any form of Design System (or Component System), containing components relevant to your organisation, will increase your time to market and quality, and decrease your ongoing development costs.
If you are experiencing any of the symptoms and signs above, and you know you aren’t giving your developers and designers the best foundation of tools and capabilities to work with, consider if a Design System would enable your teams.