Buttons

Buttons are used as a part of a flow, and is the component which the user clicks to make progress in said flow.

How to use

Buttons are in their essence a form of link which helps the user through a specific flow, typical examples are progressing to the next page and to submit something. They are also used as a way of entering a specific flow. Through their visual presence they give the users queues on what expected actions exist.

The responsive rules for our buttons transform them the full row-width in smaller screens. This should be your default design, but feel free to put two buttons next to each other even in smaller screens if the context makes it a better choice.

Example of button in desktop and responsive web-states
Example of button in desktop and responsive web-states

The button copy should make it clear what happens after clicking it, meaning copy like "Next" or "Proceed" shouldn't be used. Go to the copy-tab for more details and examples.

Don't use disabled buttons!

For accessibility reasons LFUI strongly discourages from using disabled buttons. Please read more in "Design rationale" at the bottom of the page to learn more.

Variations

We have three main variations of buttons, but other versions exist as part of another component (such as in alerts):

  • Primary button
  • Secondary button
  • Log in button

Primary buttons

As their name suggests, primary buttons are used to identify the most likely action the user might take in a specific view. As nothing is primary if several things are primary you should limit the use to one per section (even better if you can keep it to one per page) - make any other buttons secondary. or use regular links.

Modifier for primary buttons

On top of the general modifiers for buttons, the primary button has two distinct modifiers not available for the other types of buttons: two-rowed button and with BankID-icon.

The two-rowed button is used in flows where the user buys/signs up for something (köptjänster). The two-rowed button is used to continue between pages. Both rows have text in them, with the first one being in a larger font. The first row signals what will happen ("Gå vidare", "Godkänn") and the second gives more detail ("Ange uppgifter", "Köp försäkring"); see under copy for more information.

With BankID-icon is used as part of our pattern for using BankID. The modifier adds a white BankID-icon to the left of the text in the button. Note that the pattern states that you also should add an explanatory text on why we need BankID next to the button.

Secondary buttons

Perhaps the secondary button would be better named as "standard button". This is the button to use when you want a button and it isn't primary. You may use how many secondary buttons as you wish in a view. It is rare, but acceptable, to see secondary buttons next to primary - a more common pattern is the use links in cases with multiple actions next to each other.

Modifier for secondary buttons

On top of the general modifiers for buttons, the secondary button has a distinct modifier not available for the other types of buttons: button with icon. The icon is added to the left of the button text. Typical examples of use of this modifier in line with web standards) are with a clip for attaching files or a plus for adding items (like another fund or employee), but it has also been used for a more decorative purposes (like after selecting items in Fondkurser).

Log in button

To support the user in easily finding their way into Mina Sidor (and not having several primary buttons on a page) our log-in button has a unique colour (#007DB0) which is only used for logging in-purposes. The button is used for directing users to our log-in page as well as doing the actual logging in on the log-in page. It is also used for logging out from Mina Sidor.

The log-in button is always available in the top right corner of our public web pages, but can also be repeated in-page if relevant. The copy should however always only be "Logga in" (or "Logga ut" if in a logged in-view).

Only for logging in/out!

This button should never be used for any other purposes than signing in or out-purposes!

Modifiers

On top of the specific modifiers for primary and secondary buttons there are three modifiers which are available for all three types of buttons:

  • Different sizes
  • With an arrow
  • With loading state

Different sizes

Our buttons come in three sizes: default, smaller and larger.

  • The default is as the name suggests the default version.
  • The smaller button is used where space is more limited, as in forms or in the radio card.
  • The larger is used when we want to give extra attention to the button, like in campaigns.

With an arrow

If the user enters a new service/technical environment (which normally renders a change in the visual framework) this is conveyed by using a version of our buttons with an arrow appended on the right side of the button and text of the button is aligned to the left.

With loading state

A modifier which we wish we there was no need to have. Add a loading state to your button if you expect that the user might have to wait for a response (like the next page) after clicking on the button. The loading state is our spinner adapted to buttons.

Please consider

We don't use buttons which are disabled by default in LFUI. However rare use cases exist in which the user's choices lead to options being unavailable which can be identified by the selection (usually not a button) becoming disabled. Read more on why in Design rationale.

Design rationale

As the question of disabled buttons is one which regularly pops up, our design rationale from discouraging from the use of disabled buttons can be found below.

In designing our general patterns for form validation and required fields we have been informed by academic research as well as our own user testing (we have even had a bachelor thesis looking at our error message handling!). What we found is that as disabled buttons can't give users feedback on what is missing for them to become enabled, it is from a user perspective much better to have buttons which are enabled and when clicked can give users feedback on what has to be corrected before they can progress in the flow.

For users who have missed some part of a form, a disabled button forces the user to search for the error themselves (leading to longer completion times and frustration). In comparison an enabled button can provide an error message and in our pattern also auto-scrolls the user to the (first) error, making the completion of the form an easier task.

If you are designing a button which is never meant to be enabled, you shouldn't have the button there at all.

Live example: Loan product page have primary button for the "Calculate mortgages" and you have always the login button on the top right: https://www.lansforsakringar.se/privat/bank/lana/bolan/