Design System Architecture

Why design systems?

The concept of a design system has its roots in the early days of graphic design when designers would create style guides to ensure consistency in print media. However, with the rise of digital products and services, designers faced new challenges in maintaining consistency across multiple platforms, devices, and contexts.

Some of these challenges were:

• As products grew, companies hired more personnel to maintain them, resulting in inconsistent design within the products.
• As companies grew, companies hired separate teams to design and develop more products, resulting in inconsistent design across products.
• As products became more complex, so did their UI components and patterns. UI components became more challenging to develop as they needed to become responsive and accessible.

Developments in technology and attempts to solve these issues resulted in a shift from page-based design to component-based design.

To fully appreciate and understand how complex modern user interfaces have become, we can measure complexity using a system complexity scale.

In modern web user interfaces, just a single component can yield 64 x N discrete states. Mature projects can contain hundreds of components with thousands of discrete variations.

Design systems were created to address the challenge of maintaining consistency and scalability in digital products and service design. They emerged in response to the growing complexity of digital products and the need for a more structured and systematic approach to design.

Requirements

Now that we identified a problem and the need for a solution, we can begin to define the requirements for our solution. Imagine we live in a world where design systems don’t yet exist. What would some requirements of a design system be?

Requirements of a design system revolved around these core system functions:

• Enable systematic design
• Manage design complexity across products and organizations
• Act as a single source of truth for design decisions

These requirements can be further refined and decomposed into more tangible general functions:

1. Scalability. The system shall be able to scale to accommodate new components, features, and design elements.
2. Consistency. The system shall provide a consistent user experience, brand expression, and user interface across the specified digital products, services, platforms, devices, and contexts through a shared design language.
3. Accessibility. The system shall be designed according to accessible, internationalization, and inclusive design standards, ensuring users can access and use digital products and services regardless of ability.
4. Flexibility. The system shall be flexible enough to accommodate the needs of different teams, projects, and stakeholders without sacrificing consistency or usability.
5. Integration. The design system should be integrated with other systems and processes within the organization, such as development tools, hardware, and content management systems.
6. Collaboration. The design system must facilitate collaboration among designers, developers, product managers, and other stakeholders including external product teams, allowing them to work together more efficiently and effectively.
7. Documentation. The design system must be well-documented, providing clear and comprehensive guidance on system usage and maintenance throughout its life cycle.
8. Governance. The design system must be governed by a clear set of rules and standards, ensuring that it is maintained and updated in a consistent and systematic manner.
9. Efficiency. Design systems must streamline the design and development process, allowing teams to work more efficiently and effectively by deferring arbitrary design decisions to the design system.

These requirements create a general functional foundation to guide the development of design systems. In practice, these requirements must include business and user requirements, and stakeholder expectations to ensure any commitments are obtained and realized. Care must be taken to maintain and analyze the relationships between requirements, stakeholder support and opposition, to ensure the success of the overall system.

In any case, further decomposition of functions and requirements is necessary to translate ambiguity into detailed specifications. Eventually, this process allows us to map functions to specific forms, realizing a more tangible solution.

For example:

Another level of decomposition results in more specificity and starts to map function to form.

In agile, requirements will also be derived from stakeholder expected use cases, user stories, and acceptance criteria. Using Scrum, the lowest level of requirements comes from decomposing acceptance criteria from user stories.

What is a design system?

Now that we defined the problem, need, requirements, and functions, we can conceptually define what we are trying to build.

First, we need to understand what a system is. At a high level, a system is a representation of a natural or artificial entity.

From a systems engineering perspective, a system is the combination of elements that function together to produce the capability required to meet a need. These elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose; that is, all things required to produce system-level results. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected.

From a human-systems integration perspective, a system is socio-technical—composed of humans and machines in interaction. A system is recursively defined as including people, machines, and systems. A system can then be considered as a system of systems.

With these definitions, a design system can be as simple as a set of interacting guidelines and personnel or as complex as a system of systems. When we consider the simplest example of a design system, we will see that design systems, conceptually, are not that complex.

Here are some conceptual models of design systems with various structures, requirements, and effectiveness, with the third more towards an ideal representation of a modern design system. When people think about design systems, they usually refer to some variation of the third model.

While the first two models may fit the definition of a design system, most people would recognize that these do not necessarily provide the value that we would expect from a design system. Why is that? A design system may include tangible objects like guidelines, principles, best practices, UI components, and code libraries—but its core value lies in the ongoing process of defining, refining, and maintaining a shared language and systematic approach to design and development across teams and projects—that is, the value added by the design system as a whole is primarily created by how its parts are interconnected.

In essence, a design system is a socio-technical system that enables consistency, efficiency, and systematic design in product design and development, manages design complexity, and other needs as defined by the system. While design systems do not specify strict requirements about their elements, they typically consist of design guidelines, components, and code libraries, as it relates to user interface and experience. To learn more about the possible elements, check out the Design System Checklist.

Architecting Design Systems

So far, we defined the need, purpose, requirements, and concept of design systems. In this section, we combine all these ideas to create the architecture of a design system, the embodiment of a concept in which we map all the requirements and functions to their tangible forms and define the interface and processes in which these forms interact. For this exercise, the concept I selected to base our architecture on is this:

This concept is based on service design in which a dedicated design system team is responsible for creating, maintaining, and distributing the design system as a product for other product teams to consume. Rather than have teams build their own design system from scratch, they leverage existing design systems offered by a dedicated design systems team. These design system teams act as service providers to offer ongoing support and maintenance, allowing product teams to focus on their core objectives while benefiting from the latest design best practices and innovations.

When architecting a design system, we can model it by using a system modeling language. In this example, we’ll use Object Process Methodology (OPM) for its simplicity. Let’s begin:

To satisfy the function of providing a consistent user experience, brand expression, and user interface across all digital products, services, platforms, and devices, we create elements in the form of guidelines for user experience, brand expression, UI components, and UI patterns.

These elements can be further decomposed into lower-level elements.

The function of these can be constrained to digital UI or expanded to all types of media and mediums. Generally, design systems boundaries are limited to digital UI. In the case where the design system must account for multiple digital products, services, platforms, and devices, the recommended structure is to maintain separate subsystems for each medium since they tend to have different accepted UI patterns, design standards, and criteria while maintaining unity through shared guidelines where possible.

After repeating this process for all requirements, here is the resulting OPM model.

Note that at this level, the model attempts to not ascribe specific technology to use but generalizes the necessary functions and forms. This is important in web development because many technologies perform similar functions. If we follow the system architecture, we will achieve the desired functional system regardless of the technology used. This makes the system flexible, adaptable, and robust to change throughout its entire life cycle.

As you can see, this can be a long process. To create systems that do the right thing and do it well, and comply with current and future regulations and standards, it is necessary to leverage creativity, previous experience, and analysis to compose system components and subsystems into architectures that meet functional requirements. Experience is critical to understanding and establishing rules that constrain which components and connections can exist and coexist.

With that said, there are still several aspects missing. Good architecture must consider performance, resource utilization, cost, operability, system capacity, and other human-system integration domains. Early and careful consideration of human factors and behavior when interacting with such complexity has become essential to planning and designing for total system performance and long-term value and outcomes. In the next section, we will discuss additional considerations and component interactions in more detail.

Human-Systems Integration

One of the limitations of systems engineering is that it tends to overlook the human aspect and involvement in complex systems. As a result, human-systems integration (HSI) was created as a technical management process to facilitate the integration of human factors into systems engineering. After recognizing the cost-value benefits of HSI, the US DoD has mandated HSI as a required process in the design, development, and acquisition of defense systems technology.

While this process is not necessary for the design and development of most design systems, the principles and practices involved in HSI can be leveraged to our benefit through optimization of total ownership costs and total system performance by addressing reliability, supportability, and maintainability and all other human factors in the early stages of systems development and the entire system life cycle. The degree to which HSI should be integrated into design systems depends on the context in which the design system will be operated.

HSI divides areas of focus into several interrelated domains depending on the mission context. In this context, the relevant domains are:

• Personnel
• Training
• Human-Factors Engineering
• Maintainability
• Safety
• Habitability
• Operations

HSI is a very involved process. HSI is integrated into organizations by collecting data, creating implementation plans, performing tradeoff analysis, and reporting their findings to the project manager for further consideration. For our purposes, we will discuss the theoretical benefits and outcomes of using HSI. The following are general recommendations and factors to consider when designing your design system.

Personnel

Personnel refers to personnel and the necessary physical and cognitive capabilities, abilities, and skills required to perform the role, tasks, and functions as required by the system. Optimizations and tradeoffs can be made by architecting the system to minimize the personnel requirements to operate the system, ensuring personnel requirements are in line with the personnel availability pool, as well as defining personnel requirements and selection procedures to identify successful candidates. In the context of design systems, this includes:

• Selecting popular technology and software that the target personnel pool would likely be familiar with.
• Automating complex workflows to limit human activity, user error, task load and reduce overall required knowledge, skills, and abilities (KSA).
• Listing experience, skill, degrees, and certificates, required by personnel to be successful in the role.
• Identifying any gaps in capabilities to determine additional training necessary as well as their associated costs.

Training

Training is concerned with the development of personnel to reach the capability required to successfully perform the responsibilities of the role defined by the system to operate the system. This includes the development of instructional material, exercises, and evaluative measures to ensure personnel acquire and retain the necessary KSAs.

For design systems, training is required for the personnel developing and maintaining the design system and for the end users to ensure they successfully adopt the design system.

Organizations and companies will typically have an established onboarding process. To aid and supplement this process, the design system should create additional instructional material. This can include creating courses, tutorials, learning objectives, hardware and equipment set-up procedures, and designating mentor roles.

To help end-users successfully adopt the design system, consider creating detailed technical component API documentation, examples, and tutorials to get adoptees started and familiarized with the design system. This can also include establishing office hours, support teams, or other procedures where adoptees can reach out for help. Additionally, consider how these training materials will be used in part of the end-teams own onboarding process and collaborate as needed.

Human Factors Engineering

Human Factors Engineering (HFE) assures that the system or equipment design, required human tasks, and work environment are compatible with the sensory, perceptual, mental, and physical attributes of the personnel who will operate, maintain, control, and support it. HFE is directly related to design systems as its components and guidelines should be designed to optimize human-computer interaction.

HFE can be used to identify and suggest improvements to the design system by researching and collecting data to simulate and model real-world component use and interaction. Depending on the complexity of the design system context, HFE may be required to ensure the system does not exceed or extend beyond human capabilities or expected personnel requirements. HFE is used to optimize human performance in complex systems:

• Stay up to date with the latest research related to UX, HFE, and HCI.
• Continuously research, explore, and discover ways to design and develop guidelines and components to optimize human performance and the quality of the service and product.
• Perform experiments, tests, evaluations, and deliver components requirements and guidelines.
• Design and develop optimal patterns for mission-critical tasks such as alert systems and other safety or risk-related tasks, procedures, and activity.
• Implement data-gathering analytical methods to support findings.

HFE can also be involved in factors involving tasks/workload, information/situation awareness, environmental factors, communication, organizational culture, operational factors, cognitive–physiological, and system components.

Maintainability

Maintainability requires designing for the full life cycle. It is related to accessibility, reliability, and safety domain, and addresses design, development, as well as maintenance task analysis, and designing for efficiency in the tools, training, and manpower necessary to maintain and sustain the system. It also encompasses maintenance manuals, documentation, and system availability. Maintainability can be improved by:

• Select tools that are easy to maintain or were developed with maintenance in mind.
• Select tools that are likely to last a long time.
• Regularly schedule maintenance and develop maintenance procedures.
• Maintenance task analysis.
• Keeping up to date with technological advances and relevant applications.
• Limit system boundaries to keep the system contained.
• Avoid feature creep.
• Allocate more resources to maintenance.
• Automation.

Safety

Safety involves implementing safety measures and considerations to limit risk and hazard to the system including personnel and system outputs. Safety is related to cybersecurity, government regulations, design quality assurance, quality engineering, software assurance, and accessibility including motion and sound design.

• Audit end products to ensure the design system is used correctly.
• Design components to be robust.
• Design components with a deliberate, safe API.
• Test components and monitor test coverage.
• Document and design patterns with safety in mind, such as alert systems usage to reduce alert fatigue and cognitive load.

Safety is also concerned with factors in organizational structures that may induce hostile, unsafe, or conflicting work environments, and those that enhance the human performance and productivity of personnel who operate, maintain, or support the system in the intended operational environment. Relevant considerations could be whether the design system should support multiple themes, including dark mode, to allow UI personalization and customization in user environments, and limiting which functions and components should or should not be part of a digital UI as it relates to safety.

Habitability

Habitability relates to ensuring system integration with humans through design and continual evaluation of internal/external living and working environments necessary to sustain safety, human and mission performance, and human health. Habitability is directly related to safety.

Traditionally, habitability was limited to onsite facilities and campuses. With the rise of remote and hybrid work, habitability should be expanded to consider remote working conditions.

Federal contract defense work tends to be onsite for obvious reasons. Onsite work allows more control over workers and provides benefits such as ease of access to company facilities that promote human health and performance, while remote work allows for more freedom in their working environment. Careful negotiation should be had to find an optimal solution for stakeholders to design a system that reduces physical and mental fatigue.

In addition to benefits such as health insurance and behavioral health access, ensure office facilities have an appropriate interior design (lighting, acoustic), architecture, and environmental health.

Operations

Operations are the full life cycle engagement of operational considerations into the design, development, maintenance, and evolution of systems and organizational capability to enable robust, cost-effective operations for human effectiveness and mission success. Operations involve:

• Communication protocols and pipelines
• Automation
• Resource allocation
• Leadership operations
• Internal team processes
• Project management
• Logistics
• Equipment sourcing
• Services
• Developer operations
• Human resources

Perhaps the most relevant design systems operations are workflows related to team processes.

Leadership team processes:

• Project management processes to facilitate sustainable development
• Project roadmap planning and transparency
• Project prioritization
• Feature requests prioritization
• Personnel development

Internal team processes:

• Designer developer collaboration
• Designer developer hand-off procedures
• Design review procedures and evaluation
• Code review procedures and evaluation
• Designer developer QA
• Documentation and patch notes
• Help and support request handling
• Support team assignment
• Maintenance and dev-ops

External product team processes:

• Self-service
• Feature requests
• Contributions
• Issue submissions
• Help and support requests

Detailed operation procedures highly depend on organizational structures. For more insight into how successful design systems operate at scale, I recommend these articles from the Carbon Design System leadership team.

• The Power to Serve by Shixie
• Automating a Design System by Jeff Chew

Conclusion

Design systems play a crucial role in managing the design complexity of modern software applications and ensuring a consistent user experience across digital platforms, devices, and contexts. Design systems should be treated as an investment to address long-term design and technical debt across organizations and their products by enabling systematic design, consistency, and scalability in digital product and service design, allowing teams to work more efficiently and effectively, and ultimately reducing the cost of designing and building new features and applications.

However, to realize these benefits, design systems must be designed appropriately to meet the needs and integrate well into the larger system. Design systems personnel must consider the entirety of its mission context from stakeholder requirements, functionality, performance, resource utilization, cost, operability, system capacity, and human-system integration domains to lower detailed component-level interactions in order to create design systems that achieve total system performance at minimized total ownership costs.

As design continues to play a critical role in shaping user experiences, mastering the principles of design systems architecture will become increasingly important for designers and design teams. By understanding the fundamentals, purpose, and value of design systems, we can confidently make better, informed decisions when creating a design system to ensure they scale in appropriate and maintainable ways. Creating a design system can be a complex and intensive process, but is a necessary step in becoming a design mature organization.