Interaction & states

States are the single most commonly missing thing in design mockups. Hand over only the resting state and the developer invents the rest. Define at least these six: default, hover, focus, active, selected, disabled.

There is no hover on mobile. A finger is either touching the screen or not. So anything shown only on hover is permanently invisible on a phone. Open a dropdown on hover only and it never opens on mobile — an accident that happens constantly.

Never delete the focus ring because it looks ugly. Anyone who cannot use a mouse is lost on the screen the moment it goes. If you dislike the design, do not remove it — draw a nicer focus style.

Without this feedback on mobile, people think "did that register?" and press again — sometimes ordering twice. Press feedback is not decoration; it prevents misfires.

Different from active (the instant of pressing). Tabs, filter chips and checkboxes need a selected state for anyone to know what is on. Marking selection by colour alone excludes colour-blind users, so change weight or add an icon as well.

Without saying why it is disabled, people simply get stuck. Put an explanation beside it — "you must accept the terms to sign up" — or often better, leave the button enabled and, on press, point out what is missing.

Different from disabled. Read-only values are submitted; disabled values are not. For something like a name pulled from the account into an order form — editing blocked but the value still needed — read-only is required. Get this wrong and data goes missing.

Duration matters. 150–300ms feels natural; past 500ms it starts to drag. Write "smooth" in a mockup and the developer picks a number, so give the number.

For people sensitive to motion (vertigo, vestibular conditions) operating systems offer a "reduce motion" setting. If you are using large animations, ask development to respect it.

ease-out — quick to start, slow to stop — is the safest choice for UI. Constant speed (linear) feels mechanical and belongs to things like loading spinners.

It changes nothing functionally but creates the impression of a well-made product. Put it everywhere, though, and the screen turns restless. Save it for moments that should feel like an accomplishment.

Harder to build than it looks, so the quote goes up. On touch it also collides with scrolling and needs separate handling. Accessibility requires an alternative (up/down buttons) alongside dragging.

It is a hidden gesture, so discoverability is poor. Anything reachable only by swiping is invisible to first-time users. Always provide another route — a button or a menu.

Like swipe, discoverability is very low. Use it for secondary functions only; never hide a core feature behind it. There is no real desktop equivalent (right-click is closest), so it is rare on the web.

On the mobile web it collides with the browser's own refresh gesture. Asked for this on a web project, explain the difficulty and the side effects first.

Striking on a brand site, but heavy on performance and capable of causing motion sickness. It suits products built to deliver information poorly. It affects the quote too, so agree it early.

Without debounce on autocomplete, every keystroke hits the server — four characters, four requests. Writing "search 0.3 seconds after typing stops" into the spec removes the ambiguity.

This is why like buttons feel instant. It improves perceived speed a lot, but you must design how it rolls back on failure. Never use it for things that cannot be undone, such as payment.

It improves first-load speed considerably on image-heavy pages. But scroll fast and you see images arriving late, so ask for the space to be reserved in advance or the layout will jump.