Link tags: systems



A walkthrough of our design system and how we got here | Kyan

It all started at Patterns Day…

(Note: you’ll probably need to use Reader mode to avoid taxing your eyes reading this—the colour contrast …doesn’t.)

The design systems between us. — Ethan Marcotte

Smart thoughts from Ethan on how design systems can cement your existing ways of working, but can’t magically change how collaboration works at your organisation.

Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.

Global and Component Style Settings with CSS Variables — Sara Soueidan

Sara shares how she programmes with custom properties in CSS. It sounds like her sensible approach aligns quite nicely with Andy’s CUBE CSS methodology.

Oh, and she’s using Fractal to organise her components:

I’ve been using Fractal for a couple of years now. I chose it over other pattern library tools because it fit my needs perfectly — I wanted a tool that was unopinionated and flexible enough to allow me to set up and structure my project the way I wanted to. Fractal fit the description perfectly because it is agnostic as to the way I develop or the tools I use.

CUBE CSS - Piccalilli

I really, really like Andy’s approach here:

The focus of the methodology is utilising the power of CSS and the web platform as a whole, with some added controls and structures that help to keep things a bit more maintainable and predictable. The end-goal is shipping as little CSS as possible—leaning heavily into progressive enhancement and modern techniques.

If you use the cascade for everything, you’re going to run into trouble. But equally, micro-managing styles on every element will also get you into trouble. I think Andy’s found a really great sweet spot here that gets the balance just right.

CUBE CSS in essence, is a progressive enhancement approach, vs a fight against the grain of CSS or a pixel-pushing your project to within an inch of its life approach.

Yes! It feels very “webby” to me.

Five Key Milestones in the Life of a Design System -

Five moments in the lifecycle of a design system. They grow up so fast!

  1. Formation of the Design System Team
  2. First Page Shipped
  3. Consumable Outside the Main Product
  4. First Non-System Team Consumer
  5. First Breaking Change

Dave makes the observation that design systems are less like open source software and more like enterprise software—software you didn’t choose to use:

Often, in my experience, for an internal Design System to have widespread adoption it requires a literal executive mandate from the top floor of the building.

Also: apparently design systems have achieved personhood now and we’re capitalising them as proper names. First name Design, last name System.

“Please, call me Design. Mr. System was my father.”

Design Systems Podcast 10. Jeremy Keith: Overcoming Entropy and Turning Chaos Into Order

I enjoyed talking with Chris about design systems (and more). The episode is now available for your huffduffing pleasure.

How to build a bad design system | CSS-Tricks

Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.

Who hurt you, Robin?

Through a design system, darkly. — Ethan Marcotte

  1. Design systems haven’t “solved” inconsistency. Rather, they’ve shifted how and when it manifests.
  2. Many design systems have introduced another, deeper issue: a problem of visibility.

Ethan makes the case that it’s time we stopped taking a pattern-led approach to design systems and start taking a process-led approach. I agree. I think there’s often more emphasis on the “design” than the “system”.

“Making Design Systems Public,” an article from SuperFriendly

Is making your design system public worth the effort? In short: yes, it is.

I agree with Dan. But I wish that more people would make their design system mistakes and misteps public, like Robin talked about.

Le Corbusier: How A Utopic Vision Became Pathological In Practice | Orange Ticker

Through planning and architectural design, Le Corbusier hoped to create a scientifically rational and comprehensive solution to urban problems in a way that would both promote democracy and quality of life. For him, the factory production process applied to high-rise buildings with prefabricated and standardized components is the most modern and egalitarian of urban forms.

Something something top-down design systems.

On design systems and agency | Andrew Travers

Design systems can often ‘read’ as very top down, but need to be bottom up to reflect the needs of different users of different services in different contexts.

I’ve yet to be involved in a design system that hasn’t struggled to some extent for participation and contribution from the whole of its design community.

Design System Won’t Fix Your Problems | Viljami Salminen

This is something we’ve learned at Clearleft—you can’t create a design system for an organisation, hand it over to them, and expect it to be maintained.

You can’t just hire an agency to create a design system and expect that the system alone will solve something. It won’t do much before the people in the organization align on this idea as well, believe in it, invest in it, and create a culture of collaboration around it.

The people who will be living with the design system must be (co-)creators of it. That’s very much the area we work in now.

Frank Chimero · Who cares?

Aaaaaand the circle is now complete.

Frank—whose post on architects and gardeners inspired my post on design systems and automation—has now written his follow-on post about all of this. His position?

It is a crisis of care.

As with anything, it’s not about the technology itself:

A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.

Breaking looms by Matthew Ström

Another follow-on to my post about design systems and automation. Here, Matthew invokes the spirit of the much-misunderstood Luddite martyrs. It’s good stuff.

Design systems are used by greedy software companies to fatten their bottom line. UI kits replace skilled designers with cheap commoditized labor.

Agile practices pressure teams to deliver more and faster. Scrum underscores soulless feature factories that suck the joy from the craft of software development.

But progress requires more than breaking looms.

Design Systems, Agile, and Industrialization | Brad Frost

Brad weighs in on what I wrote about design systems and automation. He rightly points out that the issue isn’t with any particular tool—and a design system is, after all, a tool—but rather with the culture and processes of the organisation.

Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.

There’s a full-on rant here about the dehumanising effects of what’s called “agile” at scale:

I’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.

The design systems we swim in. — Ethan Marcotte

But a design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.

Ethan shares his thoughts on what I wrote about design systems and automation. He offers this test on whether a design system is empowering or disempowering:

Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?

The Web is Industrialized and I helped industrialize it -

We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it.

Dave follows on from my post about design systems and automation.

At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.

Listen To Me And Not Google: HeydonWorks

We have to stop confusing the excesses of capitalism with the hallmarks of quality. Sometimes Google aren’t better, they’re just more pervasive.

cough AMP cough

Systems, Mistakes, and the Sea › Robin Rendle

Robin contemplates design systems as hyperobjects.

He also makes the uncomfortable observation that design systems work is not just hard, it’s inherently demoralising and soul-crushing.

My hunch is this: folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them. But hiding those mistakes and shortcomings by glossing over everything doesn’t just make it harder for us personally, it hinders progress within the field itself.

Design APIs: The Evolution of Design Systems by Matthew Ström

This is an interesting comparison: design systems as APIs. It makes sense. A design system—like an API—is a contract. Also, an API without documentation is of little use …much like a design system without documentation.