When developers say hover, disabled, and loading states can wait until launch, should you listen?

A button's hover, disabled, and loading states cannot wait until just before launch. At minimum, define four states: default, pressed, disabled, and loading. The reason is not aesthetics but to prevent misclicks, provide feedback, and ensure usability. In 2026 project delivery conventions, developers typically reserve state slots in the component library or code. If the design mockups lack these states, developers will 'fill in the gaps themselves'—and the deviations usually surface all at once during acceptance. So you shouldn't fully go along with the suggestion to 'add it before launch.'

First, distinguish between states and variants

Much of the confusion comes from mixing button "states" with "variants." A state is the button's response to user interaction, such as default, hover, pressed, disabled, or loading. A variant is the visual hierarchy, such as primary, secondary, or danger buttons. These are often conflated, resulting in dozens of styles in the mockups while the actually missing disabled and loading states get ignored.

Per common delivery habits, a business interface should at least consider the matrix of "primary button × default/pressed/disabled/loading." Add hover and focus for desktop. For example, primary and secondary buttons are variant differences, while default, hover, and disabled are state differences. A quick tip: if the only difference between two states is opacity or shade, merge them into a single rule; if the difference comes from distinct interaction scenarios, mark them separately.

The cost of missing states: Don't let developers improvise

Missing states directly lead to two outcomes: first, users misoperate—clicking a button that gives no feedback repeatedly, thinking the system is stuck; second, developers fill in styles on their own, often using "gray + default cursor," with no explanation of the disabled reason and no loading indicator.

At one project site, the design mockups only specified "default" and "pressed." The developer used gray for the disabled logic and kept the default cursor, so users clicked and got no response, thinking the system had crashed. Later, rework added disabled explanations and a loading state, which took two extra rounds and most of a week. The constraint was a three-week project cycle with no dedicated design review; the fix was to list states first and have developers confirm. This rework cost, in common projects, accounts for roughly 10%–20% of the entire design phase (experience range).

States that developers improvise typically don't consider the focus state, so keyboard users are completely lost; nor do they explain why a button is disabled, so users only see a gray button. Missing button states are not "incomplete styles"—they represent a missing interaction contract. When developers fill in the gaps, they're adding their understanding, not the design intent.

The three-step checklist: Nail down the state list

Rather than relying on a gut feeling of "cut corners where possible," use the three-step checklist to define the state list. It suits projects with many pages and tight delivery deadlines.

1. List types: break down the current page's buttons into categories such as primary, secondary, text, and icon—usually no more than five.
2. Map states: for each type, identify three scenarios—'clickable,' 'not clickable,' and 'processing'—and map the corresponding states.
3. Check against the list: compare each mapped state with the existing states in your team's component library. Add what's missing in the mockups, and for anything the component library already standardizes, simply write "reuse component library."

Why this division? Because "not clickable" and "processing" are where users are more likely to get stuck, causing more complaints than "hover" ever will. Meeting the bar means every key button has disabled, loading, and pressed feedback; if the component library already has consistent defaults, at least note "reuse component library" in the design mockup—leaving it blank isn't acceptable. If more than one-third of the buttons on a page need custom states, the design system foundation is too weak; fix base colors and radius first, then talk states. The key is to get developers and designers using the same vocabulary, so "disabled" and "grayed out" aren't treated as two separate things.

Choosing among three approaches: Draw everything, draw only core states, or leave it to developers

Many people agonize over "should I draw everything?" but that's confusing the cost. Based on 2026 project delivery conventions, the approach that works for small and mid-sized projects is not "draw everything" or "draw nothing," but "fully define core states and reuse the component library for the rest."

• Option A: Draw everything—every button type × every state. High cost and long cycle; suited for large B2B systems or transactional flows, providing a visual regression baseline—but a burden for small projects. Drawing everything for a moderate module takes half a day to a full day more than drawing only core states (experience range).
• Option B: Draw only the core four states—default, pressed, disabled, and loading for primary and secondary buttons; hover and focus are handled uniformly by the component library. Cost is manageable, saving roughly one-third of annotation time compared to Option A (experience range).
• Option C: Don't draw—developers fill in. This is only acceptable for one-off internal prototype validation; for launch, acceptance phase tends to bring cognitive bias and rework.

Comparing the options, most small and mid-sized teams fit Option B—but only if the component library exists and actually covers hover and focus; otherwise "reuse the component library" is empty talk. Option C seems fast, but in practice the time is recovered through verbal communication and design revisions in the "developer self-check" and "design review" phases. These comparisons are based on experience ranges from small and mid-sized projects; adjust to your team's specifics.

Common pitfalls and the acceptance bar

State design has several frequent pitfalls that show up with high occurrence:

• Graying out without explaining why—users think the feature is broken and even click repeatedly.
• Loading that only spins without text—after 2–3 seconds, users want to leave.
• Copying hover states to mobile—touchscreens have no hover.
• Relying on color alone—users with color vision deficiency or using screen readers can't tell the difference.
• No pressed state—mobile taps lack physical feedback.

The acceptance bar: state differences are clear, and each state specifies its trigger condition and duration. For example, disabled states should state the reason, and loading states should state expected wait time. That way developers don't have to ask "how long does loading take?" or "should disabled show a tooltip?"

Where this applies and where it doesn't

This approach—"list the state list first, then decide what to cut"—fits small to mid-sized websites, admin systems, mobile apps, and iterative projects that need quick delivery. There's no hard requirement that the dev team already has a component library, but if they do, efficiency improves. For outsourced projects, clarify the state list at the quotation stage to avoid later disputes over "incomplete design mockups."

Where it doesn't apply: one-off landing pages, pure showcase pages, and prototype validations without key actions—there's genuinely no need to draw all states. If the design system hasn't even established base styles, don't chase exhaustive states first; settle the default/pressed states and the color spec first.

Boundary statement: If the project lifecycle is short, or the user journey lacks critical tasks, you can skip full states—but buttons involving payment, delete, save, or submit must have every state present.

FAQ

Can hover states be omitted on mobile?

Yes. Touchscreens have no hover concept; on mobile, design default, pressed, disabled, and loading only. Hover is mainly for desktop browsers and can follow the component library defaults.

Should disabled buttons include explanatory text?

Yes. Gray alone isn't enough. The disabled duration or reason should be written in a note, tooltip, or adjacent text, so users don't think the feature is broken.

How long should a loading state typically spin?

A common experience range is: within 1.5 seconds, use a spinner; beyond 3 seconds, consider a progress bar or step-by-step feedback. But set it based on your business and context—there's no fixed number.

If the developer says the component library already has these states, should the design mockup still repeat them?

Yes. At least write "reuse component library default states" in the notes, and give examples of key abnormal states; otherwise the developer can't confirm which layer of styles you intend.

How do we keep button states consistent when there's no dedicated design resource?

Start by defining only one core set of four states, pair them with a color palette and light/dark shades, then reuse the component library. If the library lacks them, prioritize the disabled, loading, and pressed states first; deprioritize the rest.