4 ms·

I've been following the design system space for a while, and it's mildly entertaining to watch from the perspective of an engineer. Because you see designers fa

• 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 ago
    Yep. 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 ago
      There 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 ago
      You 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 ago
        Interesting, 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 ago
          Sounds cool! Anything you could share yet?
          • danielvaughn 3y ago
            I'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/
    • 3y ago
  • chrisweekly 3y ago
    Agreed. 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....
• xdennis 3y ago
  This is similar to linguistics. People often rank languages in terms of difficulty, but in reality complexity is just moved around. For example in English words are often uninflected. Languages like Hungarian/Turkish have a lot of prefixes/suffixes. You'd think that means they're a lot more complicated, but in reality their prefixes/suffixes are very predictable whereas English is all over the place. Is it noninflected, disinflected, deinflected, ininflected, flected?
  • solardev 3y ago
    Not being a linguist, what is a flec?
    • PeterisP 3y ago
      Having a set of related wordforms of a single word expressing various grammatical features by (usually systematic) modifications of the word, such as the English 'work'->'worked', but on a much larger scale for most languages worldwide. See https://en.wikipedia.org/wiki/Inflection https://en.wikipedia.org/wiki/Inflection
  • andrewflnr 3y ago
    Isn't that why English is usually the near the top of language difficulty rankings? I mean, your point is true, but I don't know of anyone actually confused about it.
    • duderific 3y ago
      See: through, rough, cough, bough, dough, all of which are pronounced differently. My 5-year-old daughter is learning to read, and trying to explain all this is...challenging.
      • taeric 3y ago
        Are you truly starting with those words for a 5-year-old? Curious why? Hands down, teaching phonics is far and away the fastest route to being able to decode words. Similarly, reading to your kids is the fastest way to get them interested in reading. Using the motivation to learn to get going on the phonics is more than adequate to teach reading. And don't expect things outside of spelling/reading to be any more "logical." Try explaining the rules of any sport in a way that isn't dominated by the exceptions.
• rohan_ 3y ago
  I was reading about the design decisions made when building the shadcn library. It's actually pretty fascinating: https://manupa.dev/blog/anatomy-of-shadcn-ui https://manupa.dev/blog/anatomy-of-shadcn-ui
• gchamonlive 3y ago
  There are approaches that try to get the best of both worlds. Interestingly, the micro-services architecture is just like that, but it gets a bad reputation for being easy to devolve into a distributed monolith anti-pattern. Another cool model is maybe the propagator model. The point is maybe to find a way that you don't have to opt either for generic or specific implementations, but have many models of the same domain through different lenses operating cooperatively.
  • theamk 3y ago
    Microservices are 100% in the "Optimize for flexibility and you'll end up with something that's way too complex" territory. (I am watching this right now at my workplace: team next to us has updated the microservice in repo A, and accidentally made incompatible change, so that integration tests in repo B which make calls to that microservice are now falling. Is it a solvable problem? Certainly. But back before we had microservices, this problem just could not occur, as client/server versions were always identical)
    • danielvaughn 3y ago
      Yeah, I've only seen microservices used in a couple of places, but in both cases I felt they were introduced far too early. The first time I saw them was for a 2 page note-taking web app, and it had something like 65 microservices.
    • gchamonlive 3y ago
      They are definitely not autonomous then. Seems like a distributed monolith. Micro-services are supposed to be simple and independent, but they get crammed with more and more features and complexity and suddenly they just can't be maintained without breaking other parts of the architecture.
• pcurve 3y ago
  Adoption is a big issue with design systems. More complex it is, the less adoption you're going to see (or incorrect usage). It's amusing to see deeply nested and abstracted components with fancy properties in a design system. Makes you wonder who they're building the system for. If you look at mature publicly available design systems, they have all evolved over the years towards more simplicity and flatter structure. Google, Atlassian, etc.
  • danielvaughn 3y ago
    Yeah someone else in this thread mentioned Tailwind, and I think a lot of design systems could take inspiration from it.
• detourdog 3y ago
  From a designer's perspective we are equally amused at watching engineers discovery the same system lessons designers have faced for years.
  • danielvaughn 3y ago
    I'd be curious to hear about those. To be clear, the intent of my comment was not to be condescending. It's not like engineers are any closer to resolving those problems. We've just suffered through them for a long time now.
    • detourdog 3y ago
      I think the examples you listed were fine examples. I see designers and engineers are in the Same field and one can get the same results from either profession. An engineer would most likely put more discipline into their deliverables. I couldn’t really tell if you were being snarky.
• moritzwarhier 3y ago
  > Optimize for flexibility and you'll end up with something that's way too complex. Optimize for speed and you'll regret it down the road. Everything's a tradeoff, but the only guarantee is that at some point, you'll feel a distinct urge to throw it all away and start over. Very well-put, quoteworthy!
• esafak 3y ago
  I think it's like designing an API. Create the wireframe components you need and use them for a while before codifying them into a design system (API). In other words, observe the function in order to allow form to follow it.
• no_wizard 3y ago
  The biggest problem I see with design systems implementations is too much variation, which I think stems from the fact designers have not actually thought out what the User Experience is going to be and how the design system is suppose to facilitate that, for the whole product line Yes, the whole product line. If you want consistency in a product, it has to start with deciding what UX modalities you want to adopt, and sticking to that. Less is more, usually. Don't add a new component until you have actually exhausted the ability to use the ones you started with, if you decide to pivot UX you need to pivot wholesale etc. Getting people to stay on the rails as it were, is seemingly impossible, but when you can, it works very well. I'm abridging a bit (its a iterative process, start with wireframes over full flesh designs and other things) however this does, in a nutshell, work and has a forcing function of actually focusing on the user and product rather than design in and of itself