Should library components come with prototyping interactions? Only sometimes...

Buttons, checkboxes, tabs, radio buttons, selects, modals, drawers...

All of these components do something when clicked or tapped. But should that “something”, that interaction, always be baked in at the library level?

Quick answer is “it depends on the component...”

And the longer answer... well, let's back up a bit for some perspective. The component library’s whole job is to reduce work for designers. Its purpose is to provide well-built, reliable, reusable bits of interface. So it’s natural to assume that the more the library is responsible for (like on-click interactions), the better life will be for designers!

Not always.

Figma is not sophisticated enough for that to be true (yet). Let’s use a radio button as an example:

We know that when a user clicks or taps a radio button, it goes from unselected to selected. This is a universal pattern of the web. But that doesn’t mean you should bake that on-click interaction into your <span class="figma-component">❖ Radio button</span> component.


Well, it has no awareness of other radio buttons that will surely neighbor it in a designer’s mockup or prototype. Radio buttons don’t get presented as single options, that would make for poor UX. Instead they get presented in groups, as multiple options.

Screenshot 2024-01-06 at 10.58.57 AM.png

So what happens if you bake in that click interaction at the library level is you’re giving designers unnatural radio button behavior in their prototypes:

To fix this, the designer must to remove the “on click” interaction on every single instance of <span class="figma-component">❖ Radio button</span>. Not fun, and not a good use of her time. Leaving this issue to fester risks eroading her trust and confidence in the library as a whole. And things like reputation and trust are a big deal in the world of design systems.

Instead of putting your consumers through this, refrain from adding the “on click” interaction on components like radio buttons to begin with! This is a list of everything I discourage folks from adding on-click interactions to.

Don’t add on-click interactions to

  • Individual radio button
  • Individual tab
  • Individual pagination item
  • Individual breadcrumb item
  • Individual menu item for single-select dropdown menus (like comboboxes, autocompletes, search boxes, or other inputs that reveal a menu of single-select)

All these elements have 2 things in common:

  1. They always show up in groups. If they didn’t, it wouldn’t make sense to use them. Imagine a single tab, a single pagination item, a single radio button... what’s the point?
  2. Only one can be selected within its group. You can’t select two radio buttons for the same question on a form. If it was multiple choice, the designer would use checkboxes! Same for tabs, breadcrumbs, pagination, and single-select dropdown menus

But just because they show up in groups, it still makes sense to build a single component for each in your library. That’s how you get consistent styling after all! Don’t despair though, you can still give your library consumers working radios, tabs, pagination, and menu items! But I’ll explain how to do that in a separate blog post.

You’re probably curious about the opposite end of things to: the things you should add on-click interactions to.

Do add on-click interactions to

  • Buttons
  • Checkboxes
  • Dismissible tags (like in a filtering experience)
  • Hyperlinks
  • Progress indicators that allow you to revisit prior sections
  • Formatting buttons inside of rich text editors
  • Stepper input
  • Menu items for multi-select dropdown menus

There’s also elements that open and close on click! That action is also safe to bake into the individual component at the library level:

  • Accordions
  • Drawers
  • Trays
  • Modals

And depending on whether you optimize for configuration or composition (or both!) in your library, the element above should have a slot, or swappable chunk of UI, for your consumers. More on that in my blog post about placeholders (a better name for “slots”).

Now, you’ll want to be careful with the following, because often where they open can change based on the trigger element’s placement in the viewport. And sometimes the trigger isn’t consistent! Like tooltips for example. Lots of things can trigger a tooltip: icons, spans, cards, anywhere you can put a link.

  • Tooltip
  • Popover
  • Date picker input (watch out for the calendar picker opening on top, right, bottom, or left)
  • Color picker input (watch out for the color wheel or field opening on top, right, bottom, or left)

What about while-hovering interactions?

That one is pretty safe. Always bake that into the library unless you’re doing something particularly fancy or weird.

<div class="horizontal-rule"></div>

In summary, don’t add on click interactions to your radio button, tab, pagination item, breadcrumb item, or menu item for single-select dropdown menus. You’ll just make more work for your consumers. They’ll have to remove those interactions, and then set up ones that are actually appropriate for their prototype. And stay tuned for my blog post on how to deliver “working” versions of all those components I listed for your consumers to save them even more time!