(no title)
schkolne | 2 years ago
A magazine has multiple pages, views, etc., some with repeating elements. This craft has been honed for the past 100+ years. Read Bringhurst (The Elements of Typographic Style) and you'll see that book design has had both for even longer. Systematic thinking is part of any design education. Can't make a brand's various treatments congeal into a solid brand without it.
In 20th century print design, the grid emerged as a way for designers to systematize their work. And there's something interesting about working with the grid which is extremely relevant for design systems. Here's the thing -- the grid doesn't quite work.
Most designers know that, when you set up a grid, you end up making all these exceptions to make things actually look good. The one most people encounter first this issue: what happens when you put your text in a colored box? If the colored box aligns with the grid, the text doesn't (and vice versa). So people are like ¯\_(ツ)_/¯ and let one of the rules slide. And this kind of thing keeps happening as you work on a big design.
Curiously enough, the best way to see this viscerally is to read the bible on the grid in design -- Grid Systems by Müller-Brockmann. The grid is followed religiously and the book's design is stilted as a result.
Anyway in apps we have the same problem. We have a design system say in Figma. We try to design with it. We find.... exceptions. But we try to make it all work within the system. When we turn to building the app, there are yet more exceptions.
And we've all seen this in the code. These pristine components, over time, get filled with more and more little switches and settings, to gracefully handle the exceptions. And then someone comes around and says "let's refactor all of this", it ends up being quite bulky.
It seems we've reached "peak design systems", they are widely adopted, we love the benefits but are seeing hard limitations and perhaps it's time for the pendulum to swing another direction.
Designers feel more and more limited by working with a DS. They can't make exceptions so their work ends up being stilted. Or they expand the DS (requiring meetings). On the code level, there are more and more variations to manage, and also the exceptions that design-oriented devs add. Things get to be a mess. And the managers are saying "where's the ROI" so we spend time developing tools to measure DS ROI.
And so we apply more and more process, organization, more meetings, and more documentation, to make the design system work. It all gets kinda bureaucratic, against the spirit of agile. And the kicker is, the design isn't necessarily better as a result.
And so even though I kinda disagree I also agree when you say a design system should not be a thing. We treat it as a thing, try to force it to be an artifact, but it's not healthy for the set of design choices to be forced into this kind of form.
danielvaughn|2 years ago
Also I think you're spot on about the current state of design systems. I believe the solution is to create some kind of design toolchain that shepherds designers into the pit of success[1], where the "system" simply reveals itself over time as the design is created. That way it isn't thought of as some external artifact, but the byproduct of the process itself. But this requires a complete rethinking, from first principles, what a design tool even is. Figma, for all its impressive technology, is really a traditional design tool with some modern features bolted on (collaboration, variants, variables, etc).
[1] https://blog.codinghorror.com/falling-into-the-pit-of-succes...
schkolne|2 years ago
I agree with you -- a complete rethinking -- I've actually spent the past couple years thinking a lot a lot a lot about this. And it seems that it's not just a matter of a better design tool, but also a way of how design works in relation to code, and perhaps how the code itself changes!
Sometimes I think that Design Systems, which feel like they came from the design side of the divide, actually was a motion that started with engineering. All the componentization of React etc under the hood really powered the process where designers make components. Before that it was more typical for designers to provide these 1-page sheets with the colors, margins, etc that were more like a style guide than a system. And perhaps the strict component-based approach is part of what's throwing us into the pit of despair from time to time.