4 ms·

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

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.

bastawhiz 3y ago
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 3y ago
  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.
  - bastawhiz 3y ago
    > 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 3y ago
      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?
      - bastawhiz 3y ago
        > 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.
        bobthepanda 3y ago
        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.
  - eternityforest 3y ago
    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 3y ago
      Oh for sure, but again, it’s an engineering decision and shouldn’t be considered part of the design system.
      - zacharycohn 3y ago
        Engineers are allowed to work with Designers, especially on the boundary between their work.
        danielvaughn 3y ago
        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.
        zacharycohn 3y ago
        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.
gedy 3y ago
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 3y ago
  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.
  - petepete 3y ago
    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 https://github.com/alphagov/govuk-design-system
    - danielvaughn 3y ago
      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?
      - petepete 3y ago
        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 https://github.com/alphagov/govuk-design-system-backlog [1] https://github.com/alphagov/govuk-frontend https://github.com/alphagov/govuk-frontend
amjnsx 3y ago
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.
madeofpalk 3y ago
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.
- danielvaughn 3y ago
  Okay that makes a lot more sense. I had this impression that designers were over there like "I think we should use React."

bastawhiz 3y ago

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 3y ago
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.
- bastawhiz 3y ago
  > 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 3y ago
    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?
    - bastawhiz 3y ago
      > 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.
      - bobthepanda 3y ago
        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.
- eternityforest 3y ago
  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 3y ago
    Oh for sure, but again, it’s an engineering decision and shouldn’t be considered part of the design system.
    - zacharycohn 3y ago
      Engineers are allowed to work with Designers, especially on the boundary between their work.
      - danielvaughn 3y ago
        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.
        zacharycohn 3y ago
        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.

gedy 3y ago

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 3y ago
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.
- petepete 3y ago
  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 https://github.com/alphagov/govuk-design-system
  - danielvaughn 3y ago
    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?
    - petepete 3y ago
      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 https://github.com/alphagov/govuk-design-system-backlog [1] https://github.com/alphagov/govuk-frontend https://github.com/alphagov/govuk-frontend

amjnsx 3y ago

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.

madeofpalk 3y ago

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.

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