This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
At a friend’s recommendation, I’ve been reading Donella Meadows’ Thinking in Systems: A Primer. In its first chapter, Meadows begins with her definition of exactly what constitutes a “system.” Specifically, she says that
A system isn’t just any old collection of things. A system is an interconnected set of elements that is coherently organized in a way that achieves something. If you look at that definition closely for a minute, you can see that a system must consist of three kinds of things: elements, interconnections, and a function or purpose.
In short, a system has parts; those parts are connected; and through their connection, those parts serve a purpose. If you do any work around design systems, you’re probably pretty accustomed to thinking this way: we classify, name, and organize useful parts of our visual language, and ensure everything we document provides value to the designers and businesses that interact with it. (Even, occasionally, when they provide limited value.)
This was all running through my head as I read Lindsay Grizzard’s essay on creating successful CSS systems during my morning coffee. From my reading, Lindsay’s describing a process that foregrounds implementation, research, and careful planning—and one that treats the actual CSS architecture as an artifact of that planning process. I thought it was a stellar approach, presented in one hell of an article. I thoroughly enjoyed it.
I was also struck by how novel that planning-first approach felt. Broad strokes here, but I feel our industry tends to invert Lindsay’s model: we often start by identifying a technical solution to a problem, before understanding its broader context. Put another way, I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
Research and consensus-building have been absolutely essential to the architectural projects I’ve worked on, and to the design systems I’ve contributed to—I’m sure you’ve found the same. Adopting a popular classification scheme for design patterns is great, but the value of that taxonomy sharply decreases if your team doesn’t share your understanding of its terms. It might seem sensible to default to a popular naming convention for your CSS but, as Lindsay rightly notes, “forcing people to use a naming convention they hate isn’t going to make your job any easier.”
The frameworks we build, the visual languages we formalize—they’re artifacts that ultimately live in a broader organizational context. (And in a context that’s even broader than that.) A successful design project understands that context before settling on a solution. I try to remind myself that in my work, I’m most effective when I’m a mapmaker first, a designer second.
This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
Ethan Marcotte | Sciencx (2018-08-10T04:00:00+00:00) Weft.. Retrieved from https://www.scien.cx/2018/08/10/weft/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.