This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
The early discussion around design systems often focused on them as a solution to a problem of inconsistency: that due to a lack of documentation, standards, and governance, a product’s interfaces were often built and designed in inconsistent, confusing ways. As a result, a system of clearly-defined design patterns and practices was needed. Once that design system was in place, so the thinking went, it would help ensure teams were better aligned. And that would lead to more consistent experiences, which would benefit our companies, their products, and their users.
In this post, I’d like to share two thoughts with you:
- Design systems haven’t “solved” inconsistency. Rather, they’ve shifted how and when it manifests.
- Many design systems have introduced another, deeper issue: a problem of visibility.
Both of these items are tightly, intricately linked. Let’s start with an example scenario, one I’ve seen manifest on every design system I’ve encountered over the last few years. It starts with a single design pattern: say, a newsletter.
And as it happens, your newsletter pattern’s a real beauty. Thanks to your systems team, it’s been thoroughly researched, exquisitely designed and built, and tested as thoroughly as it can be. After some time, it’s released, and rolled out across your organization.
But then, something interesting happens: a product team modifies the pattern. It’s worth noting their reasons for modifying it are probably driven by a very valid business need. The changes may be small, or maybe they’re drastic—but the scale of the modifications are irrelevant. Because now your design system has two newsletter patterns.
In my experience, this almost always happens when a design system is put to actual, real-world use. Users of a design system frequently uncover new needs that weren’t originally anticipated. The result is that there’s now a gap: between the standard and the use. The design system falls out of sync with real-world application. And we’re back dealing with a fancier version of the old problem we used to have: our interfaces are no longer consistent.
This is not an insurmountable problem. Stronger lines of communication between designers of the system and its stakeholders; more frequent, cross-team reviews; a more collaborative contribution model; component-level versioning—there are many, many approaches that can help close these gaps. But as I’ve worked with more design systems over the years, especially at scale, I’ve realized just how difficult it is for organizations to even perceive the gaps in their systems, much less to repair them.
This is where the visibility problem frequently manifests itself. It can be incredibly difficult for organizations to speak with a high degree of confidence about where and how their system is used. For example, take our hypothetical little newsletter pattern. Whether you’re a product owner, a designer, or an engineer, how easily can you view that pattern in a variety of contexts? What kinds of content feed into that pattern, and from where? Are you able to pull up a list of pages or products that include that pattern? How many teams are using it? Has the newsletter pattern been forked in any way?
For most of the larger design systems I’ve worked with, these aren’t easy questions to answer. And as before, there are solutions available here—some technical, some less so.
But as I’ve had more of these conversations with clients, I’ve realized that most organizations have taken a pattern-led approach to creating their design systems. And given the early emphasis on solving the consistency problem, that makes sense: after all, when your interfaces are in disarray, it makes sense to document your brand’s visual patterns and front-end code, and identify opportunities for reuse.
That said, I think it’s high time organizations start creating their design systems with a more process-led approach. Rather than starting with design patterns, we need to look at the ways our teams currently work, and then identifying how a design system would function within that broader organizational context. Given that our industry’s only just started to understand the scale of the systems we’re designing, I think this might be our best hope for designing systems that support the way we want to work.
This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
Ethan Marcotte | Sciencx (2020-03-16T04:00:00+00:00) Through a design system, darkly.. Retrieved from https://www.scien.cx/2020/03/16/through-a-design-system-darkly/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.