Introduction
As Design Systems continue to gain traction, decisions and budgets are shifting inside of organizations. What was previously the domain of individual design and engineering teams has become a major strategic asset and an important purchase for many enterprise organizations. These decisions span teams, products, and often budgets as executives learn the value and strategic importance of leveraging systems to scale their digital products.
This rise has also created an ecosystem full of stories, implementation guides, architecture documents, adoption strategies, and heaps of other content. Despite this, there is little information about how an organization should evaluate their design system needs.
What is a Design System?
A design system is a set of standards and guidelines that are used to create a consistent look and feel across digital products. By using a design system, teams are able to produce a product that is more cohesive and easier to use. This helps make sure that users have a consistent experience across the product, and that they can quickly understand how to use it.
At the same time, a well-defined design system allows teams to be more efficient. By having a consistent set of rules and components, teams can save time by reusing existing elements and quickly prototyping new ideas. This also creates a common language that everyone on the team can use to discuss the product.
Overall, a design system helps teams create better products faster. It ensures that the product is cohesive and easier to use, and it allows teams to be more efficient.
Considerations for Design Systems Software
There is an ever growing list of tools that support design systems in some way. However, the industry is still immature, and it can be confusing / difficult to assess what tools are right for your organization. Much of this depends on how your organization views software and its own maturity in understanding how to effectively use design systems.
Further, design systems aren’t just about tools. There are many human and organizational factors to consider when evaluating a design system purchase.
Regardless, in the search for a design system, you’re innately looking at buying into a set of constraints. By its existence, design systems create constraints around how we build products. These can be positive – such as providing clarity on a color palette – or they can feel restrictive.
These constraints are based around two correlated continuums:
These two spectrums are usually highly correlated – most opinionated tools create constraints within the system, and most that offer opinionated implementations create constraints from workflow.
Smaller less complex organizations tend to want to be on the left of the continuum. It’s easier to adopt a system that has a specific way of doing things even if it doesn’t clearly align to existing workflows. Implementation is “easy” because there are only a handful of ways to implement. In this case, the pain of changing workflow outweighs the pain of having to conform to the constraints of a tool.
Large organizations almost always favor the right size of the spectrum, largely because they already have scalable workflows in place that are difficult to change and are core to the way the organization builds product. In this case, it is extremely painful and expensive to change these workflows, and a tool must be flexible enough to accommodate a huge variety of ways of working without introducing too many constraints.
Another important aspect of this continuum is scale – as an organization grows and matures, they begin to run into the constraints imposed by a system. Systems with opinionated implementations are often flexible enough to change with the organization, while opinionated tools rarely are. This can force a switching cost on the organization. That “easy to adopt” solution can often lock organizations into an inefficient and painful workflow that is difficult to switch away from.
Organization assessment
The first step is looking inward to understand what level of maturity and capability your organization can attain. Using design systems is an interactive process that includes constantly examining traditional creative processes related to digital products.
Establishing the buy-in for a design system
- How many teams are interested in using a design system?
- Is buy-in cross functional (e.g. are product, design, and engineering interested?) Is a particular team leading the effort?
- What is the compelling reason for a design system? Are parts of the organization already using one?
Assess organization design and communication practices
- Is there a central design systems team, or does the design system live with a product team?
- How do product, design, and engineering communicate and work together now? Does that workflow revolve around reusable components or patterns, or more bespoke development?
- Are there roles or norms established that are natural owners of a design system?
Aligning on budget and procurement process
- How does your organization buy software? What is the lead time relative to implementation goals and timelines?
- Is this new budget or coming from an existing team or department? How is that budget allocated?
- Do you need to consider assistance from an outside agency or adding / allocating headcount?
You'll know you're ready when:
- Buy-in is established
- Stakeholders and their basic needs are understood
- What systems are currently in use, what's working, and what could be improved
- Timelines are understood and there is a basic understanding of how your organization buys software
Capabilities of Design System Software
Design systems tools cover the following four areas:
- Organization of design assets
- Creation of documentation
- Visualization of coded components
- Delivery of the design system into a product
Prioritizing the above based on your organizational needs is important, but all of them are present in every design system and should be a part of the evaluation process.
The type that fits your organization is largely determined by a combination of size, maturity, and complexity. We've written previously about the different types of design systems, and fundamentally it comes down to fit with your organization.
Brand management and Content
Design systems are evolving toward becoming a natural way to manage a digital brand. While not specifically focused on digital brand management, these systems are powerful tools for the expression and maintenance of a brand that directly interfaces with product. Eventually, design systems will compete (and potentially replace) brand management software. The biggest blocker to this is the state of content in design systems. Tooling is just beginning to consider how content will work within a design system or to provide valuable digital asset management.
Likewise, content within design systems is becoming increasingly common. This usually includes content guidelines, but it can also include sample content that directly relates to how your design and engineering teams empathize with their users.
Be sure to evaluate your design system tooling based on the current state of your organization and also where it is headed in the future. Often, teams are asked to source a documentation solution or something that visualizes code. Those might make for a great reference site that is a design system, but it doesn’t actually represent something that delivers product value. Be wary of tools that aren’t able to integrate into your production workflow.
Architecture and Customization
There are essentially three ways that design systems are built.
- Organizations that value cross-discipline collaboration
- Are operating at a large scale with either many brands or many products within a single brand
- Are looking at “systems-of-systems” approaches
- Have a lot of ecosystem diversity within their products
- Companies that are fighting fragmentation. Often, they just become another point of fragmentation in the system
- Require support for lots of different tools or technologies in their ecosystem (multiple design tools, coding languages, and product pipelines)
- Have massive scale
- Early / immature design systems, or those just experimenting
- Organizations that aren’t yet focused on the strategic value of a design system or the value is constrained to a single team
- Favor an easier to adopt and more opinionated approach
- Are able to change their workflow to meet the constraints of a system
- Organizations that don’t have a lot of organizational buy-in for a design system (e.g. it is an experiment or constrained to a single team)
- Are unsure of their design system approach or how it will be used in product design or development
- Are focused on a particular aspect of the design system (e.g. docs) with little value on the other areas.
Custom
We don’t typically advocate for building custom systems except in especially niche use-cases. Most often, these cases amount to highly specific integrations (e.g. with a particular CMS that doesn’t use common front-end coding languages) or in the case where a design system is being presented as a customer interface (e.g. Salesforce Lightning). In these cases, the initial and ongoing cost of a custom solution may have provable ROI and strategic value. However, most people that invest in custom systems get a solution that is great for a “point in time”, and may even be well adopted. However, they often find that their organization’s appetite for continued reinvestment and operational costs aren’t aligned. Because of this, you see a lot of great custom systems fall into a trap of design / technical debt or languish as teams are broken up and reduced in size. It takes a lot to sustain a custom system, and it has to operate an an unusual scale with unusual value to prove value beyond the initial period of excitement.
Security and Support
Design systems are generally not critical in terms of security – they rarely contain personal or identifying information, and many organizations elect to make theirs publically available.
However, design systems do often touch production code, and it’s important to understand your organization’s security requirements before selecting a tool.
Specifically, this includes:
- What sort of certifications does your organization require? SOC2? ISO27001?
- What does the security review process look like?
- How do other cloud software providers or local software providers work within your ecosystem? What approvals did they need?
- Is it essential that tools support SSO, SCIM, IP white listing, or other technical requirements?
Security isn’t often the reason why a design system tool is chosen, but it’s often the reason why one is blocked by your organization.
Cost
There are solutions at a wide variety of price-points. Typically, they range from a few hundred dollars per month up to several hundred thousand dollars on an annual basis. Custom solutions often have annual budgets in the multiple millions to build and maintain.
Cost usually comes down to how flexible or opinionated the solution is. More flexible solutions are usually more expensive and serve larger customers.
Regardless, cost should be clearly justified based on your expected ROI. Every vendor you speak with should be able to help you make this justification, and you should benchmark the progress along the way.
Move the sliders to input your employee costs and assumed efficiency gain to calculate total employee savings from implementing a design system. If you need help figuring out how efficient you might be, try calculating Time Savings by Component on the next tab.
Select an example component or UI element to calculate the estimate efficiency gain using a system vs. unique implementation. Pick between the two starting scenarios - a simple (e.g. button) or complex (e.g. dynamic menu) component.
Select between the different starting scenarios based on different team sizes and product complication. Move the slider on employee costs and efficiency gain to calculate the total savings.
Software Adoption
We often measure the success of a design system based on adoption. Indeed, it is one of the most highly correlated metrics with ongoing design system investment and success. The ability of a system to get adopted is often reviewed as a part of a trial or early in the design system’s life. When assessing a design system’s ability to be adopted, it must clearly represent a “path of least resistance” for the vast majority of stakeholders. This means that everyone should feel like it is the right way to build using the system instead of building around it.
Often, this is interpreted as “the main stakeholder group” must find the system ‘easy’ or ‘user friendly’. However, this can create a myopia, as design systems touch a huge variety of stakeholders and what may work well for one may not work for another. It’s important to involve all of the folks that you want to use the system in any evaluation and to get feedback on where things feel great and where there is friction.
Integrations / Ecosystem
Design systems have to touch a lot of other pieces of software to fulfill their promise. A design system that just lives in Figma isn’t all that valuable. Neither is one that just exists as a set of coded components in a Git repository. A tool’s ability to connect to these systems and centrally manage these connections is a huge part of the value.
Great tools allow for a diverse set of design tools, coding languages, testing frameworks, and may even present APIs or endpoints to extend them. Organizations often select tools based on the idea that they have standardized many of these things, but they fail to consider that the environment changes. What happens if something better than Figma comes out? What if we move from React to something new? The ecosystem changes frequently, and it is important to pick tools that can adapt to those changes.
Webinar
Key Takeaways
- Design systems can’t be purchased out of the box but instead combine software, process, culture change, and team modifications.
- Future-proofing design systems and determining the value of tailored, customizable, multi-tool, and open-source solutions rely on the organization's unique requirements and level of maturity.
- Prioritizing budgeting and comprehending the financial implications are crucial steps before implementing design systems. Dan and Chris provide concrete figures for Design System software and team expenses.
Support & Enablement with Knapsack
While choosing the right tooling is undoubtedly a crucial factor in building a successful design system, it also requires careful consideration of processes and strategies that can help teams navigate the project successfully, ensuring the system's long-term effectiveness and scalability. Knapsack offers expert services and support to complement our end-to-end platform, ensuring that our customers have access to the tools and knowledge they need to achieve their goals. We understand that no tool can solve every problem on its own, which is why we are committed to providing comprehensive solutions that address the unique needs of each organization.
Knapsack provides unparalleled support to help large organizations build their design systems successfully. With a dedicated Slack channel and support professionals with decades of expert experience, Knapsack offers the enablement and personalized assistance necessary to guide enterprise teams through building a scalable and flexible yet durable design system. We prioritize our customers' needs by providing them with the attention, care, and expertise required to overcome any challenges they may encounter along the way.
The team at Knapsack has helped with hundreds of complex design systems and is available to assist you in finding the best approach and avoiding potential pitfalls based on our expertise.
Reach out to our team at hello@knapsack.cloud for a conversation about your design system goals.
