3 ms·
Agreed. I think part of the challenge is that design systems are inherently owned across design and engineering (not just the design team), but the overall unde
by qkeast 3y ago
Agreed. I think part of the challenge is that design systems are inherently owned across design and engineering (not just the design team), but the overall understanding of what a design system is means that few folks involved really understand where and how to make decisions about those tradeoffs.
- danielvaughn 3y agoYep. As for what a design system "is", one thing I've always disagreed with is that it's referred to as a thing, like it's an artifact or output. I like to think of it as a process, as in designing systematically. I also think that the notion of systematic design comes into play even at very small scale - it's not something that's only relevant to large teams. I call it vertical vs horizontal design. Before the digital era, designers typically worked on things like posters, advertisements, book covers, etc - scenarios where you have a single context and multiple graphical elements that need to co-exist in harmony. This is vertical design - one context with multiple elements. For digital applications, another dimension is introduced. Because now you'll have multiple pages, views, etc, with some repeating elements. So like a button that exists on both the signup page as well as a checkout page. You may not need the buttons to look exactly the same, but they need to co-exist in harmony with one another just as they do in their surrounding context. So now you have one element with multiple contexts - what I call horizontal design. This second dimension is what requires a shift in thinking from designers to an approach I would call "systematic." Figma is the first product that takes horizontal design seriously, with the introduction of variants and variables and all that. But there hasn't really been a tool that bakes it in from the beginning.
- bobthepanda 3y agoThere is a bit of history in this; Pantone made a whole business out of color consistency across media for branding, coming out of any possible print shop or factory or whatever. And fonts have a similar history. Now, the brand is so much more than that.
- waldothedog 3y agoYou might be interested in “Integrated branding” and/or visual identity systems, including the use of “parametric” design, grids, and variables, going back at least 50 years. You’re 100% right that there is a tension between the outputs/artifacts and the generator (process/logic). This often is a challenging aspect of design education programs. Figma’s explicit structure, and certainly their community as well as the rise of design within software, have made this more visible and tangible. But this is an old tension rather than a new one.
- danielvaughn 3y agoInteresting, will check it out. I've done some research on parametric design, but from what I've read, it's mostly been applied to architecture and some aspects of 3D modeling. Which is kind of a shame, because it's really neat. I'm actually building a "programming language" for designers that is essentially a parametric design language.
- waldothedog 3y agoSounds cool! Anything you could share yet?
- danielvaughn 3y agoI'm building a documentation site, but nothing is usable yet. I'm probably 5-10% of the way towards being ready to really showcase anything. But there's some introductory material you can read here: https://matry.design/ https://matry.design/
- schkolne 3y agoNah nah gotta disagree (well I heartily agree with the basic characterization vertical vs horizontal here) but disagree that designers have not historically done both. 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.
- chrisweekly 3y agoAgreed. I'd take it even further, framing it as more of a 3-way venn intersection of design/ux + engineering + product. I have lots of related experience and many more thoughts to share, if others are interested....