Scope of Design Systems
— Article currently W.I.P.
We've seen the main benefits of a Design system but it can still be overwhelming, especially with examples such as Google Material Design, IBM Carbon, and Apple Human Interface Guidelines. Don’t worry though, those design systems are made to cover millions of use cases and allow people external to those companies to build native applications.
Most companies need a design system to cover very specific requirements and, unless you have an elevated number of applications, the result should be a design system with a simple infrastructure that would make it easy to scale, maintain, and work with over time.
Disclaimer: DO NOT compare
As with any other project, inspiration is a good start when building design systems but you should always avoid comparing results and solutions to those from another company. Team structure and budget are variable and depend on how well the idea was sold to stakeholders and how much the company was willing to invest in the project and its members.
There are design systems built with only 3 members and others with 30 team members, this of course has a direct impact on the reach of the project and each member's responsibility. It's key to have a roadmap and know how to prioritize the work while also setting quality standards and managing expectations.
Design System Scope
Design systems are a product/service that never stops evolving. Defining the scope is a way to understand the design system's reach and evaluate what elements need to be provided to create value for the company objectives and its users'.
The scope should be adapted depending on the company and its context. Building a huge design system for a company with a single application is as wrong as building a small one for a company with multiple brands.
Remember to use these lists only as guidelines and never strict rules as everything is relative, and depending on the context recommended elements might change. For example, I included the theming capabilities in the third list as it's commonly used to cover the inclusion of multiple brands, but a single application that allows users to customize the interface will require theming capabilities from the beginning.
The following list will help you get an idea of the different design systems' scopes.
Single Application
The great advantage for companies with one product from implementing a design system is that scalability is practically granted and it will provide a solid infrastructure that will be almost future-proof.
In this scenario, product teams can handle part of the alignment and responsibilities such as accessibility, writing guidelines, testing, QA, etc, and collaborate directly with the design system to build a coherent product.
In this scenario, a design system can have an impact and bring results to the company and its users by covering the following elements:
Roadmap & KPIs
For planning and alignment with product teams. A roadmap helps organize and communicate the future tasks of the design system.
Anticipates how the design system team will work and produce the different elements, all following a common set of rules and principles.
The design library should include the same components as the development libraries to enhance the collaboration between design and development.
Defines how teams can collaborate with the design system and also request new components, patterns, or even reviews of the built features.
Defines the reach of the system to handle the expectations and responsibilities and specifies what is included in the DS and what isn't.
A single source file that will include all the defined styles of the design system to .
Design and Development elements must use the same naming to allow better communication inside product teams and among their members.
Describes the interaction patterns included in the product such as drag & drop, upload, actions, etc, and how to reuse them with different examples.
Multiple Applications
As the company grows, it's common to see the applications number increase and so the product teams working on them. The design system needs to adapt to serve them all and guide them to build a coherent experience.
The DS must establish the right channels for communication and collaboration as it becomes more challenging to have alignment. Having more people also means more requests which means more chances to work on something that's not a priority.
This is where the design system starts to be a separate entity with more responsibilities, the team will need to provide guidance and solutions making sure product teams apply the right elements to their use cases.
A design system that serves multiple applications should provide alignment among product teams and become guardians of the big picture goals and best practices. The following list of elements will help covering those needs.
Count all the elements from a single application DS plus the following:
Weekly Meetings With Product Teams
It's crucial to be aligned with product teams. Having regular meetings helps the DS find inconsistencies and anticipate product requests.
Having official communication channels allows the DS to provide updates on any change in the system and inform product teams about the status of the requests.
A design system is the best team to guide product teams in the right direction when using reusable elements with guidelines for Visual Styles, UX Writing, Motion, Imagery & Illustrations.
It can also include Branding and Marketing guidelines for the construction of reusable assets.
As applications grow in size and quantity, components and patterns should allow for more pre-defined customization to cover all the use cases of those applications.
UX Research
aaa
As the number of teams grow, it's important for the DS to have a dedicated space to answer doubts and provide guidance.
Anticipation is key and product teams always have some last-minute urgency to cover. The DS team should have some dedicated time in the roadmap to help in those cases.
aaa
Sometimes to reduce costs,
aaa
Multiple Brands
Including multiple brands brings once again more changes to the processes. The company (or companies) now works with multiple styles, foundations, and different applications. Product teams increase in number again, making it harder to be aligned and keep track of all the communications.
This makes the DS team able to help in those situations as well
All the elements from a multiple application plus the following:
Mentoring Sessions
aaa
aaa
Is React the best solution for every company? Would it be forever? Design system engineers will help answering those questions by checking new technologies and advancements.
aaa
aaa
aaa
aaa
aaa
Multiple Companies & Multiple DS
Some companies are building multiple design systems to cover their needs of having multiple brands under the same company. It works for cases where there's a clear division at a branding level. An example of this is Microsoft Fluent vs GitHub Primer, both are part of the same company but under very different brands and objectives which makes having multiple design systems a really good option. The main reason to take a similar direction is having different users that require very different interactions and features from each design system.
Careful though, there are also examples where it doesn't work that well, especially if there's not a clear division at the branding level. I know one company that has built multiple design systems just to cover multiple sites under the same brand, and now they have a Pandora's box of design systems full of inconsistencies with product teams using disconnected components to build features.
Coming Next: Building a Design System Team
In the next article, I will talk about the size and tiers of design systems and how your team doesn't need to build the next Material Design or Apple Human Interface Guidelines to impact how the company works.
Issue 03