The Design System Ecosystem | Hacker News Reader

The Design System Ecosystem

bradfrost.com

89 pointsskilled38 comments

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.

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.

Not necessarily. Figma outputs the appropriate CSS - I think you could probably pattern-match one to the other with a relatively simple model by looking at sizes, colors, shadow settings, defined states, and perhaps even by rendering it out and doing image matching.

This is something we’ve built internally and I’ve found it super useful, even though it basically just reports on occurrences, not exact usage (can easily say how many usages of Button, but not the green Button).

I think this is done by CSS Post-processors like PostCSS. Just as post-processors removed un-used classes; it would be to get a log or manually run it to get how often a class is used to tell you which components powered by that class is used in product/dev or wherever.

I’ve been away from development for quite a while but I remember using simpler tools before the days of easy-to-use post processors.

Here is how to use Grep to look for occurrences of specific classes, elements, etc to tweak/track or do something with it. https://brajeshwar.com/2013/hijacking-developer-tools-optimi...

Luro [0] by Dave Rupert has been developed to solve just this problem.

[0] https://luroapp.com/

Ah interesting - and endorsed I see by Brad Frost too (although it's interesting he doesn't identify the issue in this Ecosystem post, so perhaps he does't see it as quote the holy grail, but hey).

I'm skeptical this would work with crawling for anything other than the most basic toy websites. How can this identify components that use generated class names (any css-in-js, css modules, etc)? Can it pull prop usage out?

I gave it a try on just our public login page and it said "no pages found" - perhaps it doesn't work for single page apps?

> has had any ability to tell me where, how often, or even whether a particular component is in use in the production UI

I built a dashboard to display this for the design system I work on at my day job to give product designers better visibility into production, using a library called react-scanner[0] and some logic related to the way our different product repos are structured / places where the component names are different between figma and react. there are probably other libraries for this sort of thing in different ecosystems, and you can always build your own with a parser as well.

[0] https://github.com/moroshko/react-scanner

What I do is ctrl-f in the codebase to look for the name of the React component. This tells me how often it’s being used, and I can see exactly where and how.

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.

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.

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.

> 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.

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?

> This means their UX has to be consistent between iOS, Android, TV, Web, PlayStation, Xbox, etc.

Nobody expects all of these platforms implemented to be a single codebase (though you perhaps could). The intention of a design system is for all of the UIs to be consistent, not all of the underlying code. Zero people expect a button component for the PS5 to work on the Web. And of course they wouldn't! One is clicked and tapped and one is interacted with a controller.

Stripe is a great example of this. Their design system, SAIL, runs on every web surface (internal and external) at the company. And ignoring versioning, it's essentially one design system codebase. But that doesn't mean they aren't principled about using React. Their latest major version was originally going to be multi-framework but that plan was scrapped because it meant sacrificing composability. There's exactly one way to build UIs for the web.

I’ve seen design systems that preserve flexibility primarily by restricting to html, css classes and js, so that the only thing that really matters is that the developer’s chosen framework outputs said stuff.

Yeah this is the solution I'm imagining in my head. IMO the true separation between design and dev is that designers are responsible for pixels-on-screen. They manage visual behavior, whereas developers manage functional behavior.

> You could restore a BlackBerry from 2005 that you found at a pawn shop and it would probably have a Netflix app on it.

No, you could not. There were never any versions of Netflix that ran directly on any BlackBerry OS, unless you count the Android ports that some folks managed to port and get running on BlackBerry 10 devices as the platform was dying around 2014 or so…

It’ll never stop being funny how techies are so literal that they can’t recognize sarcasm and humor. My friend, it was a joke.

it’ll never stop being funny how people think their jokes still work when there are such glaring inaccuracies it detracts from the force and crux of the construction.

It wasn’t just a joke, you were trying to make a point about how it’s possible to have a design / UI that’s so ubiquitous it can run anywhere, which I disagree with, and your point isn’t helped by a false and exaggerated example.

The inaccuracy was the joke, did you really not get that?

And again with the literalism - you think I meant "run anywhere"? I said "consistent UI", as in the branding and UX, not literally the same code. That does need to be consistent, and it's a well-known problem when supporting lots of different platforms, as Netflix themselves point out:

https://netflixtechblog.com/hawkins-diving-into-the-reasonin....

Now you're the one being literal. Feel free to substitute "work anywhere" for "run anywhere" in my previous comment since we're referring to a bunch of design and branding and not literal code.

I understand it's a problem, I think it's quite hard, I appreciate that Netflix does a reasonable job, I still don't think your joke works the way you think it does.

Let me break it down further and attempt to fix it so I can perhaps disabuse you of the notion that I'm so far out on the spectrum I'm incapable of communicating effectively or understanding humor (way to slander "techies" by the way, your "design thinking" superiority complex is showing).

You said: "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."

A version that actually works as a "joke" - aside, I hate the use of that word here, since it's an insult to the craft (1): "Netflix has to work anywhere - their design is so consistent, flexible and ubiquitous it would have worked on on a BlackBerry from 2005... in screen reader mode."

(1) https://craftsmanship.net/the-art-of-the-joke/

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.

Oh for sure, but again, it’s an engineering decision and shouldn’t be considered part of the design system.

Engineers are allowed to work with Designers, especially on the boundary between their work.

Agree totally, I think all I'm saying is I don't want a situation where the design team (inadvertently or otherwise) decides the Javascript framework. In an ideal world they wouldn't care.

That's why they'd work in collaboration with the engineers. To enshrine engineering specific things - names of reusable complements, etc - into the design system. The designers aren't deciding on those, but they can still be included to make the most effective and useful design system possible.

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.

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.

The best design system around[0] operates entirely in the open. You can look through the history, discussions, PRs, framework-specific implementations and see why it's geared the way it is - and why it's incredibly successful.

[0] https://github.com/alphagov/govuk-design-system

For designers who wish to take part and contribute to this design system, does that mean they need to learn how to install nvm and all those requisite steps?

It depends on the level of contribution.

You can contribute by responding to the discussions in the backlog[0], by improving the actual distributed styles and code[1] or suggesting improvements to the documentation in the link I posted above.

Bigger changes need to be backed up with user research, evidence of user needs and accessibility reviews and checks.

[0] https://github.com/alphagov/govuk-design-system-backlog

[1] https://github.com/alphagov/govuk-frontend

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.

We try and be very deliberate to be clear about whether we’re talking about ‘design system’ or ‘component library’. The company library is a specific implementation, or conforms to, the design system.

Though often, it’s just incredibly pragmatic to conflate the two. You don’t ship figma files to users.

Okay that makes a lot more sense. I had this impression that designers were over there like "I think we should use React."

This framework might seem nice and organized but glosses over the extreme complexity and messiness in the "recipes" layer.

I work on a very large product that has 100+ product teams using my core team's design system. The number of "recipes" that are created is enormous. The number of duplicate recipes that are created is enormous (teams creating the same combination of components over and over and over). The number of recipes shared between product teams is enormous. It's a massive, chaotic web of componentry.

There's no way to control the chaos. And you wouldn't want to - that would stifle product team independence, creativity, and speed. The only thing you can do is try to have the right system and incentives in place to nudge people in the right direction to improve the overall health of the ecosystem. Oh and you also need to figure out how to measure the health of this ecosystem...

I was hoping this post would have a cute framework for that, but it doesn't.

A lot of Brad Forst's ideas seem to only consider an ideal situation, divorced of real-world experience.

They're great ideas; many very useful in practice, but I feel like it's easy to over-systematise design... your observation about the "recipes" being a great example.

Reply on news.ycombinator.com