Category: Link

Ethan Marcotte: “The design systems between us”

Ethan Marcotte has written about seams and edges being a defining part of his work, and in his latest post1 he applies that same lens to the theme of organizational structure and collaboration, and how design system success stories haven’t been easily replicated. He writes:

[I]n my experience, design systems haven’t brought this kind of rich, cross-functional collaboration to most organizations. Instead, the existing divisions between design and implementation have become entrenched, and massively so.

Ethan breaks out a few specific reasons why we haven’t seen a direct improvement in collaboration as a result of design systems: limited resources, front-end complexity, and costs of collaboration. At the risk of repeating myself, I’m really convinced that organizations should start with the last item on the list. Otherwise we’ll treat design systems as a self-contained solution — instead of as a byproduct of deep organizational work.

Why do we often invert the order? One thing I’ve observed when working with clients is that cross-team collaboration needs a champion with enough authority to make that work happen, coupled with support from within the organization. (You also see this play out in diversity, equity, and inclusion work, but that’s another blog post for another time.) Without that external force, it isn’t surprising that teams will often iterate fast and hard, and create things that are tightly coupled to their immediate needs — because that’s where they have control. These teams often don’t have the authority to officially collaborate with other teams, or they lack the incentives to do so because collaboration is not a top-level priority for the organization.

Retail therapy

Another way of looking at this is to appreciate how quickly design systems went from a tool that teams used to create products, to a product itself that could be sold to organizations hungry for the same results. You might compare it to the appeal of a capsule wardrobe: it’s easier, perhaps, to imagine all the ways a well-considered, interchangeable clothing system can make your life instantly better, instead of addressing deeper issues at the intersection of materialism and identity.

Adopting or creating a design system could address some issues (especially at the final level of assembling content or product) but leave deeper issues untouched. Those deeper issues are often what lead to the design system falling into dysfunction or misuse. It can also lead organizations to mis-identify their problems — they are likely not the exact same ones that Facebook/AirBnB/Saleforce were trying to solve with their design systems.

Bridging the gap

Ethan’s observation about the missed opportunities between design and implementation rings very, very true to me:

[T]here are surprisingly few products focused on the space between design and implementation—on bringing design workspaces and engineering workspaces closer together. This means that if your organization wants to close that gap, you’re going to have to take on a fair amount of custom development.

At Bluecadet our work tends to be more project-based instead of iterative product work. We’ve tried out a couple of things like InVision’s DSM — like Figma, you can pull tokens into your front end system with a little bit of elbow grease. It still requires coordination, though, and tight collaboration. When it’s worked well, it’s been the result of a designer and developer paired closely together.

I’m not convinced that there can be a universal product that addresses that design/implementation gap — it would likely be so specific that it would require a lot of work to modify. Perhaps the best we can do is focus on friendly API design that clearly defines the boundaries where human collaboration needs to happen.

Gardening, again

Garden metaphors abound in web design circles, and I’ll risk adding one more to the mix: perhaps high-profile design system success stories can be compared to walking through someone else’s finished2 garden. We see that garden in bloom, and we are instantly inspired — and then tempted to replicate it. But maybe it’s better to accept that creating our own garden will result in something very, very different — a reflection of our own plot of land, emerging from work done slowly over time.


  1. You know a blog post has struck a chord when you draft a quick tweet about it, and that tweet turns into six, and then you finally decide to do what you should’ve done in the first place and write a blog post in response. 
  2. Gardens are never finished, but you get the point. 

NYT: “‘Mad Max: Fury Road’: The Oral History of a Modern Action Classic”

This retelling of the Fury Road production has been making the rounds in my various friend circles; has it really been five years? It’s wild to hear how the film almost didn’t have the Citadel scenes:

He [Jeff Robinov] said, “The camera will stop on Dec. 8, no matter what you’ve got, and that’s the end of it.” We hadn’t shot any of the scenes in the Citadel yet, where the opening and closing book ends of the film are set, and we had to go into postproduction without them. It was almost incomprehensible.

I’m not sure how I feel about the just-announced prequel plans — it sounds like they’re recasting the Furiosa role, and I feel like that’s an even tougher casting choice than Tom Hardy stepping into Mel Gibson’s role.

Emily VanDerWerff: “On editing”

I really enjoyed this piece from Emily VanDerWerff’s Episodes newsletter, describing the editing process from her experiences as a writer. This bit, especially, echoes my own feelings every time I sit down to write a blog post, an article, a talk — anything, really:

The trick of rewriting isn’t really about writing, actually. It’s about emotion. The second you realize something doesn’t work in your writing, it’s tempting to fall down a spiral of self-loathing — if your writing isn’t good enough, does that mean you aren’t good enough? The best writers are the people who’ve brute forced their way through this natural emotional process to realize that their work isn’t them. But even they will have that brief twinge of, “Am I worthless??” that so often strikes when somebody says, “So, I have some notes…”

After starting out with that common writer’s struggle, however, Emily then proceeds to discuss/review Susan Choi’s recent novel Trust Exercise, and how it deals with the malleability of memory. Emily connects that to her own experiences coming out as trans and how that has provided a very different lens through which to view her childhood memories.

I loved this essay — it starts out with a common writer’s lament, rushes headlong into a book that I’d read but only vaguely remember, and connects it to a deeply personal story of understanding, accepting, and celebrating one’s self. It’s not neat or tidy in any way, but you can feel the life and heat coming off of it.

Ethan Marcotte: “Through a design system, darkly.”

I appreciated this post by Ethan Marcotte, with his observations on the emergence and usage of design systems:

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 an incomplete thought, but: the work that goes into making artifacts, deliverables — and, yes, patterns — is where the value lies, more than in the artifact itself. In other words, the process-led approach that Ethan advocates for here could be a way to recognize that the design system is less of a fixed entity, and more of an evolving organism:

Rather than starting with design patterns, we need to looking at the ways our teams currently work, and then identifying how a design system would function within that broader organizational context.

The process-led approach strikes me as descriptivist, the pattern-led approach as prescriptivist. That’s too simplistic, perhaps — you need a bit of both — but identifying those two overlapping approaches would serve all of us well.