Cory LaViska of Shoelace fame posted this a few days ago:
— Cory LaViskawhen building a component library, what component do you build first and why is it always button?
It’s a similar question that starts Dan Mall’s talk he first performed at Clarity 2022. Dan argues that the button doesn’t provide impact to teams; buttons are easy and obvious. It would be more useful to determine what component would be the most impactful and then contribute that to the business. In Dan’s talk, he uses the example of a map component for Uber which is essential to the experience and wildly complex. I disagree that the map is a good choice for the design systems team to tackle, but I agree with the sentiment of prioritizing impact.
However, for folks that are dipping their toes into design systems, Cory’s question is interesting. Why is the button the first thing most folks build?
Popularity
I was having a dinner conversation with Adekunle Oduye one evening where I was asking him a similar question; how do we choose what components belong in a design system? For many folks, we’d look at existing systems and inventory what the most popular components are. Looking at component.gallery, Button is the most popular component with 141 examples at the time of this writing. It would make sense that because it is the most popular component, it probably belongs in your system too.
But this should introduce a new question. When the first design systems were starting, how did they know they needed these components? The answer is doing their own inventory local to their companies’ needs. In fact, that’s ultimately what Dan is suggesting in his talk. The design system should be a reflection of the people it is made for. So what components you maintain should be determined by an internal inventory of usage.
It is easy to tie impact to how often something is needed. The more it is needed, the more it impacts the final result. Therefore, because the button tends to be the most popular, we tend to want to build it first.
Necessity
Since we want interactive websites, we expect that we will need a button at the very least, even if that button operates as a link. Without interactivity, a website is a one-sided conversation. There’s no navigation, no feedback. It might as well be a piece of paper to be read once and maybe bookmarked for later. To begin turning a web page into something a little more, that interactivity is needed.
Importantly, I don’t believe small sites need design systems. In fact, most of the personal websites I’ve created don’t have a design system; just some reusable styles. Larger sites beget interactivity to traverse between the homepage, dashboard, products, checkout, and beyond. Each one of those pages is expecting a user to achieve some goal. To do that, the user needs to make choices, and those choices are coded as moments of interactivity within buttons, among other controls.
Complexity
So far, I’ve been making a case for why you’ll probably need a button in your system. I haven’t yet touched upon why it’s most likely first.
The button component is deviously complex in the number of states and priorities it could be meant to convey. When we alter a single presentational attribute, it could convey a whole new meaning to the user. This is especially apparent by the way we’ve landed on our common naming system for buttons. In other words, the button is the only interactive control that can convey priority. There is no such thing as a “primary” text field. As an example, the primary button is meant to guide the user to the most likely direction they should take.
Getting all the visual treatments right such that they convey the correct information can be a daunting exercise for folks unfamilar with the permutations. However, this is also the only hard part about the button. There’s really only one thing the button can do, accept a click. So we can focus our attention on the visual treatment alone. Which leads to the next reason.
Containment
The button is mostly often considerd an “atomic” component, meaning it is commonly not broken down to further elements. Many other components are composed of other pieces and with each additional piece added to a component, more complexity is added. So not only would a person need to make decisions on the visual treatment of each part, you’d also need to make decisions on how these pieces work between themselves and in some cases within the larger composition they’ll be set within.
Since the button is self-contained and has no real complexity past the various visual treatments, we tend to tackle this low-hanging fruit first as a quick win.
Tokens
The final note to mention is that we often spend a great deal of time curating tokens, either by choosing names or their values. In order to test our architectures, it would be most helpful to assign these tokens to something that can show coverage easily. The button having lots of potential in visual complexity and customization, while being a small self-contained component, makes it a excellent “test” component to build where you can curate your token architectures and check the visual result in something you have confidence will appear on any page.
So all of these things contribute to the reason why I believe the button tends to be first in our libraries. In my system playground, it was probably the first “non-primitive” component.