[HN Gopher] The Design System Ecosystem
___________________________________________________________________
The Design System Ecosystem
Author : skilled
Score : 49 points
Date : 2023-09-22 15:49 UTC (7 hours ago)
(HTM) web link (bradfrost.com)
(TXT) w3m dump (bradfrost.com)
| ProxCoques wrote:
| I know the "technology-specific implementation" is optional, but
| one thing that bugs me (as a designer) is that no design system
| I've ever used has had any ability to tell me where, how often,
| or even whether a particular component is in use in the
| production UI. So if I wanted to change it, what's the impact?
| Nor can I tell by looking at the production UI whether something
| that looks like a component is actually one, or just an
| "impostor" that won't change if the component I've changed is
| updated.
|
| A possible exception to this is some CMS systems I've dealt with
| that can sometimes tell you this, but they don't typically cover
| the whole of the product's UX. But I do wish the tech stacks
| would recognize this issue.
| danielvaughn wrote:
| This is a really interesting use case. Because the Figma
| components are not directly tied to the code, you'd need strict
| naming convention adherence if you wanted to build a tool that
| would support that.
| danielvaughn wrote:
| One thing I don't like is that design system conversations end up
| discussing javascript frameworks. I just don't see how that's
| relevant at all to DS, and seems like poor separation of
| concerns.
|
| I'm on the design systems slack channel, for instance, and I see
| designers asking all the time about react or whatever. The chosen
| technology stack should be an implementation detail from the
| perspective of the design team.
| gedy wrote:
| I agree, when I've worked with UX at a few companies, I (dev)
| found myself in the funny situation of encouraging designers to
| not be distracted by the technology ("oh we should use
| Tailwind, antd components are cool", etc) and talk about what
| the actual design system is. What are the primitives, patterns,
| needs, etc.
|
| 90% of the time it was basically a theme, and we implemented
| using Bootstrap and its primitives/components were fine.
| danielvaughn wrote:
| Yeah I've never been on a design system team (always wanted
| to), but I think it would require a technical lead to help
| keep the team focused. It's admittedly very hard for a non-
| technical designer to understand what is and is not a concern
| for engineering, so I get why they would find themselves
| distracted.
| amjnsx wrote:
| Yeah I agree - the design system should be a spec that
| engineers should adhere to - colors or spacing between elements
| and so forth.
|
| That leaves an engineering team to implement using the tools
| they are comfortable with and what works with their stack.
| bastawhiz wrote:
| It's very relevant. If your design system isn't reusable and
| composable, you don't have a design system, you have design
| guidelines (and the components won't be reused or composed).
| Without a framework (even one you roll yourself with web
| components or whatever you prefer), it's exceedingly hard to
| make a design system reusable and achieve organizational buy-
| in. If you can't enforce contracts with a defined interface,
| what you've built isn't a system at all.
|
| Yes, it's an implementation detail. But it's not an invisible
| detail. The choice of framework affects the capabilities of
| your design system. Choose poorly and you're stuck with an
| expensive bad decision.
| danielvaughn wrote:
| I can kind of see your point, but from my POV, every
| framework or library (even "none") enables the UI to be
| partitioned into logical groupings, whether they're called
| components or not. Some technical stacks might make that more
| or less difficult, but that's a decision for the engineers.
|
| I'm interested in seeing design and dev work closer together,
| but I think what will help them best is an interface that
| clearly defines the roles and responsibilities of both
| groups.
| eternityforest wrote:
| Any one framework lets you do reusable groupings.
|
| 29472 different frameworms mean nothing is cross compatible
| and you have to reimplement.
|
| It might not be design layer.... But I'm more than happy to
| learn a new technology(Within reason) to get more reuse.
| They're mostly all the same anyway, learning a new
| framework is easier than creating new code.
| danielvaughn wrote:
| Oh for sure, but again, it's an engineering decision and
| shouldn't be considered part of the design system.
| bastawhiz wrote:
| > every framework or library (even "none") enables the UI
| to be partitioned into logical groupings, whether they're
| called components or not.
|
| Here's the thing: nobody builds a design system for
| themselves--well, maybe they do, but it really doesn't
| matter what you choose if that's your prerogative.
|
| Design systems are about people. It's about getting your
| whole company on one page and making a broad set of UIs
| look good and consistent. Sure, you can build your design
| system with anything or nothing, but the point is making
| sure it's well-used, and the framework you use is an
| absolutely paramount part of that.
| danielvaughn wrote:
| I may be misunderstanding, let me take a step back.
|
| In my usage of the term "framework", I mean the UI
| technology used to implement the product UI. So if a
| design system is "built in React", it means that any
| usage of the DS must also be in React.
|
| If that definition holds true, then making consistent UI
| across a company basically requires that the DS be not
| only framework-agnostic but platform-agnostic as well.
|
| My favorite example for this problem is Netflix. You
| could restore a BlackBerry from 2005 that you found at a
| pawn shop and it would probably have a Netflix app on it.
| They might be the most ubiquitous technology on the
| planet. This means their UX has to be consistent between
| iOS, Android, TV, Web, PlayStation, Xbox, etc.
|
| Even on the web, you have the experience itself, as well
| as several backend/b2b and internal UIs.
|
| At that scale, the question of "react vs vue vs htmx" is
| waaaay out of scope, no?
___________________________________________________________________
(page generated 2023-09-22 23:00 UTC)