Skip to main content

Cooperative Design Systems

By Tyler Sticka

Published on September 9th, 2019

Topics

Stop me if you’ve heard this one before: There once was an organization whose products lacked harmony. Its teams struggled to embrace a shared vision, continuously reinventing wheels of infinitely varied size and shape. Then one day they all joined hands and created the Design System, addressing everyone’s needs and forever banishing the dissonance they’d felt for so long.

Unfortunately, the reality can be far more complicated. Sometimes an existing system won’t meet the needs of your project or users. Maybe it was created with too narrow a focus, or without enough involvement from outside teams. Maybe the problems you’re solving are new, or at least newly prioritized. Maybe the work to date simply doesn’t meet your team’s standards for design, accessibility, performance or inclusiveness.

Whatever the reason, don’t despair! Depending on the state of the existing system and the goals of your project, there are several strategies for adopting a scalable, pattern-based approach without sacrificing the user experience or inviting tiresome organizational turf wars.

Here are a few to consider, in order from most collaborative to most independent.

Your team uses the existing system, proposing or contributing necessary changes or new features along the way as needed.

  • The existing design system provides three button variations. Your team proposes a fourth based on the needs of your project.
  • Your project relies on dynamic charts and graphs, which aren’t part of the current system. Your team works with others in the organization to design and develop a set of data visualization guidelines that everyone will benefit from.
  • The principles of the existing system suit your users, team and project.
  • The system allows and encourages direct contributions.
  • You’re able to participate in the ongoing governance of the system.
  • Your project’s timeline is able to accommodate what may be a slow process of evaluating changes that will work for every application of the system.

Your team contributes a new namespace of patterns or components, meant to work within the existing system but entirely optional.

  • Your organization’s flagship application uses system fonts to harmonize with the user’s operating system while minimizing load times. But your team is responsible for marketing materials, which benefit from more distinctive typography. You develop and introduce a set of optional “Marketing Typography” components and accompanying documentation.
  • The existing system is working well for end users, but your team has been tasked with improving the information density of administrative interfaces. As you begin designing these interfaces, you realize that the preferences of this audience are distinct from others and require unique solutions. To minimize conflict, you create a new “Admin” namespace for these additions.
  • The foundations of the existing system do not overly contradict the needs of your users, team or project.
  • The system already accommodates namespaced subcategories of patterns, or would allow for it without substantial refactoring.
  • Your team is allowed to contribute and maintain your namespace’s patterns directly.
  • You’re able to participate in the ongoing governance of the system as a whole.

Your team builds atop the existing system, introducing your own additions and modifications while maintaining your own documentation. These contributions would exist as one or more independent plugins for the existing system, not unlike plugins for frameworks like Bootstrap or Foundation.

  • Your designs require an off-canvas menu, but none exists in the existing system’s component library. You create a plugin that adds this new navigation pattern while leveraging the system’s foundational styles and utilities where possible.
  • The existing patterns work well for your project, but they are not very accessible. Your team crafts an extension that enhances the accessibility features of the existing components.
  • The foundations and principles of the existing system are very nearly what your users, team or project needs.
  • The changes you want are mostly additive: You are primarily introducing features, not overriding existing ones.
  • Your organization regularly updates and shows commitment to the existing system, giving you confidence to build upon it.
  • Your team is unable to contribute directly to the existing system in a meaningful or sustainable way.

Your team adopts the existing system’s materials up to the point where they no longer make sense, or where there isn’t a path for you to meaningfully contribute. From that point, you would introduce your own implementation, taking care to emphasize in documentation and materials why and how this system meets your unique needs.

  • Your team’s been told to leverage the company’s design system for new projects, but this “system” consists only of Sketch files. Your team stays as true as they can to what’s illustrated there, but crafts a more useful library of front-end patterns and an accompanying style guide.
  • The system’s design principles and HTML/CSS patterns are solid, but they’ve been applied to a library of React components. After some testing, your team concludes that React isn’t a good fit for your project’s performance goals. You create a forked set of patterns using a competing solution.
  • You can clearly identify a point at which the existing system’s needs diverge from that of your users, team or project.
  • It is not feasible for your team to introduce meaningful change to the existing system within the desired timeline, technical stack or organizational reality.
  • The existing system is poorly maintained, lacks governance or has been abandoned by the organization.

Your team creates an independent system tailor-made to solve your unique problems. You don’t seek to actively contradict the existing system, and you may occasionally take inspiration from it, but you aren’t directly incorporating any tangible artifacts of it. Your documentation and materials clearly illustrate the unique goals of your system, perhaps linking to the other system as a potential solution for differing use cases.

  • For reasons that baffle your team, the organization’s new design system is not responsive or optimized for touch. Your team decides that it can’t build a modern experience on those foundations.
  • While the design system’s patterns seem visually attractive at first glance, all rely on a small base font size and few meet WCAG 2.0 contrast guidelines. Your team designs a separate set of patterns that prioritize legibility.
  • The existing system does not meet the needs of your users, team or project.
  • It would take almost as much effort to modify, override or extend the existing system as it would to make your own.
  • It is not feasible for your team to introduce meaningful change to the existing system within the desired timeline, technical stack or organizational reality.
  • The existing system is poorly maintained, lacks governance or has been abandoned by the organization.

Design systems are supposed to promote reusability, so diverging from an existing one is rarely the ideal scenario. New problems can be a golden opportunity for expansion, bringing together otherwise disparate collaborators and raising the bar for the organization as a whole.

But that process isn’t easy. People can be messy, organizations can be fickle. Hopefully, most of the challenges you encounter will be solvable without selling out the end user. When that isn’t the case, it can be helpful to know there are alternative approaches to consider.