Morningstar Design System
You’re viewing MDS v3 documentation. Legacy documentation for MDS v2 and prior is available here.
Back to Blog

Building a Communal System

For a design system to be successful, it needs to think about its relationship to the people it serves

October 6, 2020—Systems aren’t a new concept. They’ve existed as long as existence itself. Rules and structures of the natural world have been and constantly are being applied to create and perpetuate life. As humans, we’ve built our own systems to structure societies, and facilitate various facets of life within them. Human-made systems have great potential and great risk. They can create sustainable ways of living for all involved. They can also amplify human biases and narrow perspectives to the detriment of existence. Design systems seem miniscule when thought of in the context of these much larger structures, but they are part of this same dynamic.

Design systems are often pitched as a kit of reusable parts to build products, providing the all-important benefit of efficiency. While efficiency is one of the benefits, focusing on efficiency alone can limit the potential of a design system, creating a situation where people’s agency and the quality of user experience are traded in for faster delivery. To reach its potential, a design system should be considered as a means to provide benefits on many fronts, in many ways. At a high level, the intent of a design system is to make it easy to create unified and useful user experiences. Providing the assets to create those experiences is a key part of a system, and for those assets to be valuable, they need to be implemented with the right balance of flexibility and cohesion.

This balancing work is an ongoing process, one which will never be finished, as standards need to grow and change to adapt to the needs of everyone utilizing them. A design system serves many groups, including internal users—the designers, engineers, and others within your organization—and external users, the people who use the software built with the design system. There are many ways to address this dynamic, including treating your design system as a product or service that supports your organization’s product teams. Regardless of the organizational structure your design system utilizes, running it as a communal system can help ensure its success.

The power of collective ownership

Illustration showing arrows connecting various circles, representing individuals, and an octagon, representing a design system.

A communal system relies on collective ownership. This means that the standards that make up the system are defined by the people who use the system to build products, rather than being defined by an independent group and handed off to others to use. This helps ensure a direct connection between the system and the end user, as the people tasked with understanding their users’ needs are also the ones shaping the system to meet those needs. By distributing and decentralizing standard-making power to the people working to build products, design systems can become more responsive to changing needs and ensure solutions are thoroughly reviewed by a wide array of perspectives.

Since a communal system includes the voices and ideas of a expansive set of people—all of whom can see their individual and collaborative efforts manifested within the system—it is far more likely to be something that people will be excited to contribute to and promote. This makes it possible for a design system to become a means for people to have a broader and deeper sense of satisfaction and impact in their work, as their individual efforts benefit the larger organization.

By providing this support structure for people, a design system helps to ensure its own sustainability and longevity. People who see themselves represented in a system will be more invested in making sure it continues to exist and grow, as the system is something they are a part of, rather than something they just use.

While different organizations have different structures in place to support their design systems, ranging from dedicated, centralized teams, to fully distributed contribution models, there are many principles that can be helpful across this mixture of scenarios. Three such principles are:

  • Address internal user experience
  • Build active feedback and contribution loops
  • Support a collaborative view of creativity

Let’s break down what each of these principles mean, and what they might look like in practice.

Address internal user experience

Focusing on the needs of the user is a standard practice in the design world. Design systems add an additional layer to this practice, since their users include both the external users of software, as well as the internal users building with the system’s parts. Solving your internal users’ problems can be one of the most effective means of creating a sense of communal ownership and support for the system.

To the extent that the internal users working with your system are in touch with their external users, addressing the needs of the internal user is a clear way to help ensure you’re meeting external users’ needs as well. It also means that you’re helping to improve the day-to-day experience of your coworkers by giving them the tools and foundational pieces they need to do their work. Ideally, this provides them with the space and time to consider how they can make more impactful, systemic changes to their products, rather than needing focus on building every aspect of their UI.

In practice, this might look like:

  • Making it easy for internal users to report bugs or request features, and actively following up on these submissions
  • Prioritizing your roadmap based primarily on the needs of the teams and people that use the system
  • Working to help address internal issues, like improving shared code standards, or getting teams to utilize the same front-end framework

Build active feedback and contribution loops

It isn’t enough to say you’re open to feedback if people do not feel empowered to contribute. Often, because of structural issues and personal experiences, people may not feel like they have the experience or power to give input on or contribute to shared standards. Communal systems need to actively seek out participation and feedback from those that will utilize their standards, ensuring individual needs and perspectives are brought together to develop collaborative solutions.

Facilitating contribution of work from your design system community gives them agency to confidently use the system, as it provides people a means to evolve standards to meet their needs, rather than feeling blocked by something outside of their control. While this evolution requires a give and take to maintain the right balance of adaptation and consistency, navigating it helps to ensure alignment and support.

In practice, this might look like:

  • Reviewing in-progress design system work with the larger organization on a regular basis and inviting open feedback
  • Finding opportunities to encourage teams to contribute bug fixes and new features that they’ve already identified a need for
  • Establishing working groups with participants from across the organization to work through larger design problems for the design system

Support a collaborative view of creativity

Creative work is often thought of as a solitary endeavor, the lone genius developing innovative ideas to shape the future. But this is rarely, if ever, the case. These narratives often only exist to bolster the cult of personality around particular individuals, hiding the contributions of many other people working on a particular product or idea. In reality, creativity often consists of drawing unconventional connections between existing ideas.

A great way to make these connections is to bring together diverse perspectives from people of different identities, disciplines, and experiences. Using the design system as means to facilitate collaboration and communication between many different people spread across your organization provides a strong model for how working outside of traditional boundaries can foster better outcomes for those working with the systems and the end users interacting with products.

In practice, this might look like:

  • Using the wide perspective of the design system to identify opportunities for collaboration between people who working on similar problems but are unaware of each other’s work.
  • Providing a model for how designers and engineers can work side by side to solve problems, rather than the traditional “hand-off” relationship
  • Developing a discovery process that helps the designers working on a new design system component get valuable input from the larger community to ensure it meets shared needs

Where we are

The Morningstar Design System team does its best to embody these ideas, but we know we have much room for improvement and growth. Underlying the pursuit of these principles is a shared commitment to improvement through healthy self-criticality and community feedback. It’s also important for us to recognize that we are just one system operating alongside and within many other systems that exist within our organization.

Learning to navigate and shift these other systems to help them be inclusive of the needs of our coworkers is an important complement to the work we do on the design system. Ideally, the design system is just one of many parts of an organization focused on addressing the real needs of all users, creating relationships founded on trust and support.