In a design system, when should an action be a button and when should it be a link, and why does the difference matter?
answer
- does something versus goes somewhere
- semantics follow behaviour
- new tab, back, copy address
- announced differently
- appearance should match function
basics
~20 sA button does something in place: submits, opens a dialog, changes state. A link goes somewhere: another page, screen or resource. Semantics must follow behaviour, because users and assistive technology rely on it to predict what will happen.
solid answer
~50 sThe rule is behaviour: a **button** performs an action — send an agreement for signature, apply a signature, open a dialog, toggle a panel — while a **link** navigates to a location, such as the completed agreement's page in the archive. The WAI-ARIA Authoring Practices say the two are distinctly different and that both appearance and role should match the function. The choice matters because each carries expectations: links can be opened in a new tab, copied, bookmarked and returned from with back; buttons cannot. Screen readers and voice-control users hear and call them by their type, so a navigation control announced as a button, or an action announced as a link, misleads them. Visual emphasis is a separate decision; when a link is styled like a button for a prominent call to action, it must still behave and be exposed as a link.
go deeper
Recall the one-line rule: a button performs an action, a link navigates to a location. Give one example of each from a real product.
Explain what each choice gives the user: new-tab and back behaviour for links, how assistive technology announces and lists each, and how to decide grey areas.
Show how you would audit a product that mixes the two, prioritise the fixes by harm, and set a system rule for button-styled links.
Consider how the system's component set and documentation make the correct choice the easy one, so product teams stop choosing by appearance.
## The rule in one line In a design system, **a button acts; a link navigates**. The choice is made by what happens when the control is activated, not by how it looks. The WAI-ARIA Authoring Practices button pattern puts it directly: the actions buttons perform are "distinctly different from the function of a link", and "both the appearance and role of a widget" should "match the function it provides". ## What each one is for Take an e-signature product, where a sender prepares an agreement and signers complete it. | | Button | Link | |---|---|---| | **Purpose** | Performs an action on the current screen or data | Moves the user to another location | | **E-signature examples** | Send for signature, Apply signature, Decline to sign, Add signer | Open the completed agreement, View the signing history, Help article on legal validity | | **What users expect** | Something changes here; there may be a result or error | A new page or screen appears; back returns them | | **Extra affordances** | None beyond activation | Open in new tab or window, copy the address, bookmark, share | | **How assistive technology presents it** | Announced as a button | Announced as a link, listed in link lists | | **Native mobile** | An action control on the current screen | A row or control that pushes a new screen, often with a disclosure cue | ## Why the difference matters - **Predictability.** A signer who hears "link" expects to go somewhere. If the control instead sends the agreement, an irreversible action happens under a navigation label. - **Lost affordances.** A navigation built as a button cannot be opened in a new tab or copied, which breaks common workflows such as reviewing several agreements side by side. - **Screen-reader navigation.** Screen-reader users often jump through a list of links or a list of form controls. A control in the wrong list is effectively hidden from them. - **Voice control.** Users say "click link" or "click button"; the wrong type makes commands fail. - **Keyboard behaviour.** Links and buttons respond to different keys by convention; the keyboard-navigation guidance specifies which, and getting the type wrong breaks it. - **History and state.** Navigation should create a history entry the user can return to; an action should not quietly add one. ## Grey areas and how to decide them 1. **An action that ends by navigating.** "Finish signing" saves the signature and then shows a confirmation screen. The primary effect is the action, so it is a button; the navigation is a consequence. 2. **A link styled like a button.** A prominent "Start signing" call to action on an email landing screen that simply opens the signing screen is navigation. Many systems offer a button-styled link for this; it must still be a link underneath. The Authoring Practices favour visuals that match function, so this is a deliberate trade-off, not a free choice. 3. **A button styled like a link.** A text-only "Resend invitation" performs an action. It is a button, and the better fix is a low-emphasis button style rather than link styling. 4. **In-app navigation without full page loads.** Moving between screens inside a single application is still navigation, and still a link. ## The same distinction on native platforms A native app has no web addresses, yet the distinction holds. Pushing a new screen is navigation; changing something on the current screen is an action. Native accessibility layers also expose controls as buttons or links, and screen-reader users on mobile hear the difference just as desktop users do. ## How a system makes the right choice easy - Ship a **button** component and a **link** component that share visual styles, so teams never need the wrong element to get the right look. - Document a **button-styled link** variant with explicit when-to-use guidance, rather than leaving teams to improvise one. - Name the rule in each component's usage guidance, with the e-signature examples above as do and don't pairs. ## Common mistakes - Choosing by appearance: "it looks like text, so it is a link". - Making every clickable thing a button because it is easier to attach behaviour to. - Wrapping a whole card in a link that also contains buttons, so actions and navigation collide. - Letting a link perform a destructive action, such as voiding an agreement, with no confirmation.
- A marketing team wants a big filled 'Start signing' control that just opens the signing screen. Button or link?A link, because activating it navigates. The system can offer a button-styled link variant so it gets the emphasis the team wants, but it must still be exposed and behave as a link: openable in a new tab, announced as a link. The Authoring Practices prefer appearance to match function, so keep such variants for genuine calls to action.
- 'Save and continue' saves the form and moves to the next step. Which is it?A button. The defining effect is saving data, which can fail and needs an error path; moving to the next step is the result of a successful action. Making it a link would imply the user can open the next step directly, skipping the save.
saying these in an interview costs you the question
- Choose button or link by how the control looks, not by what it does.
- Buttons and links are interchangeable if the click handler does the right thing.
- Screen-reader users cannot tell a button from a link anyway.
- Navigating inside a single-page app is an action, so it should be a button.
- A native app has no links, so the distinction does not apply there.