Primary
buttons.
The button on the page that the learner is meant to click. Submit. Continue. Get started. Done well, it's the clearest part of the interface. Done badly, learners stall — or click the wrong thing.
The single most important action on the screen.
Every screen with an action should have exactly one primary button. It's the visual answer to "what does the learner do next?" — and it earns its weight by being the only one of its kind on the page.
- Submitting a quiz, form, or response.
- Continuing to the next module or scene.
- Confirming a decision in a scenario.
- Starting a course or beginning a section.
Every action on the page.
If everything looks important, nothing does. Multiple primary buttons on one screen split the learner's attention and slow the decision. For lower-priority actions, use a secondary or text-only style — see also navigation buttons and toggle buttons.
- Multiple competing CTAs on the same screen.
- Navigation between scenes — use navigation buttons instead.
- State changes like filter toggles — use toggle buttons.
- Inline references inside text — use links.
Three states, one purpose.
A primary button, a secondary button, and a disabled state — the three pieces that make hierarchy work. Click "Submit" to see the disabled-on-success pattern; click "Reset" to start over.
Awaiting input.
The Submit button is disabled until the input has content — this is the cleanest way to signal "you can't progress yet" without surprising the learner with an error after they click.
Get the visuals right.
Hierarchy through contrast, not size
The primary button doesn't need to be physically bigger than the secondary — it needs to be visually heavier. Solid fill versus outlined, dark versus mid-tone, brand colour versus neutral. Same size, different weight.
Generous padding and tap targets
Aim for at least 44×44 pixels of clickable area, with horizontal padding around 1.5× the vertical. Cramped buttons feel cheap and miss on touch — the cost is real.
Visible hover, focus, active states
Buttons need four states: default, hover, focus (keyboard), and active (mid-click). A button without distinct states feels broken — even when it's working perfectly. The focus state especially: a visible ring or outline that keyboard users can see.
A clear disabled state
The disabled state should look unavailable, not just inactive. Reduce opacity, mute the colour, change the cursor to not-allowed. Best practice: pair the disabled state with a tooltip or inline text explaining why it's disabled.
Accessibility — keyboard activation
Use <button> elements, not styled divs. Native buttons handle Tab, Enter, and Space activation for free. Custom buttons built on <div>s almost always miss one or more of these — frustrating for keyboard users and disqualifying for accessibility audits.
Accessibility — meaningful labels
Screen readers announce the button text. "Submit" is fine when the context is clear; "Click here" is not. If the button is icon-only, use an aria-label that describes the action, not the icon.
How to use primary buttons well.
One primary button per screen.
This is the rule. If you have two equally important actions, redesign — split into two screens, demote one to secondary, or merge them into a single action. Two primary buttons competing for attention forces the learner to decide which one is "the" action, and that decision shouldn't be theirs to make.
Label the outcome, not the mechanism.
"Submit my answer" beats "Submit". "Continue to next scene" beats "Next". "Save and exit" beats "Save". The label should describe what happens when the learner clicks, in their language. Generic labels work when the context makes the outcome obvious; specific labels work when it doesn't.
Verbs at the start.
"Start course", not "Course start". "Get a quote", not "Quote request". Verb-first labels read as commands the learner is about to issue, which is exactly the cognitive frame you want. The exception is single nouns that read fluently as actions: "Done", "Next", "Continue".
Disable, don't hide.
If the primary action isn't yet available — form not filled, quiz not answered — show the button in its disabled state, not absent. Hiding it makes the learner wonder where the action went; disabling it tells them what they need to do to unlock it. Pair with an inline message if the reason isn't obvious.
Loading states matter on slow actions.
Anything that takes more than 300ms — quiz submission, API call, file upload — needs a loading state. The button should change to indicate "thinking" (a spinner, "Submitting…", disabled). Without it, learners click twice, three times, more — and double-submissions are real problems.
Consistent position across the course.
Primary actions belong in the same place every time — usually bottom-right (for left-to-right languages) or centred near the bottom of the active content. Moving the primary button around the screen breaks muscle memory and slows progression.
Destructive actions need extra caution.
"Reset progress", "Delete answers", "Exit without saving" are all destructive. They should never be the primary button by default — and if they must be, pair them with a confirmation step. A primary button that loses the learner's work is a punishment for clicking the most prominent option.
When you'd reach for a primary button.
Quiz submission
"Submit my answers" at the end of a quiz. Disabled until all questions answered, with a small message indicating how many remain.
Course start screen
"Start course" or "Begin module" on the landing screen. Often paired with a secondary "View syllabus" or "Read intro" button.
Decision in a branching scenario
The chosen response in a branching scenario becomes the primary button once selected, with secondary options demoted visually.
Form submission
"Get a quote", "Submit application", "Send my feedback" — any form's final action. Disabled until valid input; loading state on submit.
Want a course
built well?
We apply these principles on every course we build. Three-week delivery, transparent pricing, zero drama.