14

How do you guys handle multiple variants of a component in a design system?

29 days ago from , I design stuff

I'm struggling with this at my current place. I'm kind of reverse engineering a design library in place based on existing designs. The issue I have is for example a modal overlay will have loads of variations and states based on the context of the flow/process the user is in.

So, do I create a unique component based on the process its being used in or do I create an overall modal component with sub options based on those scenarios.

Really interested on how you guys deal with this.

Edit:

Thanks for all the great suggestions!

18 comments

  • Bart S, 28 days ago

    If you're making every possible modal a seperate component the system isn't going to scale that well. I'd only recommend that for very small projects. The answer to your question also kinda depends on if you're building a actual component library or a sketch file containing all your components. I prefer using something like BEM naming.

    7 points
  • Sander SmeekesSander Smeekes, 28 days ago

    We are currently setting up our component library (part of the design system) in Figma. We try to make 1 main component with all the variations of the element placed as flexible as possible. From this component we make Instances and start making the variations by hiding the elements. Those variations than sometimes become part of the library depending on the overall usage.

    So for example:

    Main component: Input field

    Placeholder text, Optional text, Label text, Clear icon, Validation/error icon, validation/error text

    Instance: Default state for input field

    Showing only the: Placeholder text + Label text

    Btw. What's up with the text colour of the comment section input field here at DN? It's like i'm typing in the placeholder text.

    Anyway hope this gives a clear idea about our workflow!

    4 points
  • Nathan NNathan N, 28 days ago

    You're current approach may be too verbose. Try thinking of modals as having three parts; header, body, footer. In the body section of the modal you can have any combination of form or other page elements. While in the header you have the main title, and in the footer you have your CTA buttons. Don't account for every use case, just build a flexible template that allows you to dump any kind of information into the modal.

    3 points
    • Hamish TaplinHamish Taplin, 28 days ago

      Agree with this 100%. In programming terms, this is known as 'composition' and it translates very well to design, especially within a design system based on components.

      2 points
  • Joshua HynesJoshua Hynes, 28 days ago

    At Stack Overflow, we created a base modal style that had minimal styles applied by default. Then other components were placed within it as needed. Most of the time, most modals were composed of a headline, copy, maybe some inputs, and couple action buttons.

    3 points
  • Josh Rio, 29 days ago

    For Modals specifically, I tend to make layer styles for the modal (container) and overlay (background). Depending on if they're themed i'll typically name them something like theme/dark/modal/container or something like that.

    Then I keep the components within the modal as symbols and text styles (you might have headlines and descriptions in some or just headlines in others).

    I found this to work best because you get the benefits of the design system without having to "Detach from symbol" all the time.

    3 points
  • Matt WalkerMatt Walker, 27 days ago

    Instead of thinking as every instance of a modal as a separate component, think about a single modal component with attributes that you can modify.

    A list of attributes a modal can have: - Header - Body - Footer

    I'd consider the header and footer to be mostly defined where the body gives the flexibility to add whatever content necessary.

    2 points
  • Harper Lieblich, 28 days ago

    My team creates separate symbols for each state of a component, but only for the simple elements like text fields and buttons.

    For more complex organisms, we build example symbols that we expect to break apart as soon as we place them in a new design. These example symbols are more intended to give guidance rather than being unchangeable objects.

    1 point
  • Andrew C, 25 days ago

    Atomic design helps somewhat with things like this. The header bar, bottom bar (if any) and general sizing of the modal body (including scroll) are atoms and molecules. The modal frame is an organism based on these constituent component. The form you'll nest inside the modal is ALSO an organism (comprised of buttons, inputs, labels, errors, etc). Together they create a general template (or pattern). And the final piece with real elements is a page.

    You can have multiple modal organisms if your app calls for that. That's OK... but question why you need two instead of one. Atomic design isn't perfect by any means (it's taxonomy is quite clumsy) but it's a common language to help talk through front-end hierarchy like this.

    1 point
  • Jan SemlerJan Semler, 27 days ago

    I use the principle of atomic design and break down the design to little parts. The little parts will be put together as molecules and so on till i have my component. My smallest parts are objects like a circle or pill which i use to create buttons for example. Whenever i need a circle i will place that symbol color it with a layer style and move on and put other symbols together. I don‘t build states most of them are only need color adjustments i do that via layerstyles or switch symbols.

    It is just more clever to break it down as little as possible instead of having multiple symbols of the same thing. It helps me keeping a organized structure.

    0 points
  • olivia davisolivia davis, 20 days ago

    I am actually planning to build an app to solve this problem but stuck and can not find a developer with reasonable prices. Friends advise https://idapgroup.com/ Some of them these guys already helped but I need to rely on more reviews

    0 points