I believe every modern operating system allows you to set the key repeat rate and the delay before first repeat:

By default, on a Mac, the initial delay is 500ms, and the key repeat rate 1000ms. You can adjust both:

• Initial delay goes from 250ms, to as long as 2s.
• Repeat rate goes from 2000ms (once every two seconds) all the way to a whopping 33ms (30 times a second).

On a PC, the shortest values are exactly the same, but Windows 11 only allows up to 405ms between key presses, and 1000ms of initial delay.

My suggestion is to make them both as short as possible for testing.

Why would that be helpful? There are two reasons.

First, it’s good to test whether your keystrokes behave well when repeated. Occasionally you might want your interface to suppress repeating, or do something special if the key is held longer.

Second, it’s a good test not just of repeating, but also of a user pressing keys really fast. It’s very important for the UI to never make you wait for any animations or transition, and a lightning fast 30fps repeat rate is a good way to stress test your system this way.

Here’s me holding the Tab key in Figma at a standard key repeat speed:

It’s nice to see those transitions help you orient yourself as you’re thrown around the canvas. But look at what happens when I do the exact same thing with the key repeat cranked up:

The transitions are now slowing the UI so much that you can no longer see any canvas movement – the canvas only catches up when I release the Tab key.

The smooth movement assumed a certain minimum key rate, and perhaps wasn’t tested with a faster one.

There are of course ways about it, like speeding up the interactions, suppressing the transition smartly, or introducing a custom repeat rate if needed – I talked about it a bit in my essay about designing fast keyboard interfaces.

Here’s an example of an interface that suspends transitions at a fast keyboard rate and responds in real time:

This looks very chaotic especially since you’re not in a driver seat, but this interface is at least honest and doesn’t make the user wait. And it might not be pure madness – you would be surprised how fast people’s brains and fingers can react.

But first, you have to be aware of the problem, and I think setting up those key repeat values as short/​fast as possible will help you find more of those kinds of issues.

(And you might choose to keep those high speeds anyway in regular use, like I do.)

Go to Settings > Accessibility > Zoom, and then turn on “Use scroll gesture with modifier keys to zoom.”

Then, at any moment, you can hold Control and swipe with two fingers (or use a scroll wheel) up or down to zoom the entire screen.

I’d also recommend turning off “Smooth images” under “Advanced…” so you see individual pixels better:

Over the years, I found this feature very useful to inspect various misalignments, to check visual details, and occasionally simply to read text that’s too small.

Compared to other ways of zooming, this one has three benefits:

• it’s extremely motor-memory friendly and so my fingers do it without me even thinking
• it’s a system-wide thing, so it will work everywhere
• it’s safe, because it’s something that I call a peek gesture

Peek gestures are fast, but the main benefit is that they’re safe. In some apps, pressing ⌘+ a few times and then ⌘– the matching amount of times doesn’t guarantee you will end up back in the same situation. The window size might change, the scroll position might move, the cursor might end up in a different place. In contrast, the Ctrl gesture is 100% deterministic and reversible; it will always work the same and never mess anything up.

I treasure peek gestures in general. Here are a few other useful (and/or inspiring?) ones:

• previewing things in Finder by pressing (or, for power users, holding) the spacebar

• using ⌘⇧4 with the intention not to take a screenshot, but just to (roughly) measure a distance between two objects, and then pressing Esc to abort

• in tools like Figma and Sketch, using Ctrl+C just to quickly verify the color, and pressing Esc to cancel (rather than clicking to put the color into the clipboard or apply it elsewhere)

• I also previously mentioned Chrome typeahead and macOS menus that had a similar property

Many designers and engineers have Apple products with their flawless and praise-worthy trackpads. By default on macOS, trackpad means only “shy” (iPhone-like) scrollbars are shown. Shy scrollbars become half-visible when two-finger scrolling, and only fully visible when hovering over them.

To anyone working on front-end, I encourage you to toggle this setting to “Always,” and convince half of your team to do the same. Your macOS will now pretend you have a mouse connected, and show more traditional scrollbars, all the time.

Why? Because you might already be accidentally generating spurious scrollbars without realizing. Here’s something I just spotted in Coda today:

This scrollbar serves no purpose, so it will become visual noise for a lot of your users. But when you yourself use “shy” scrollbars, you might not even realize.

Of course, the scrollbar is just a symptom of a bigger problem – an accidentally scrolling surface that will be janky to everyone regardless of their scrollbar visibility status.

Always-visible scrollbars make it easier to spot these, not to mention also being helpful in spotting:

• scrollbars mismatched in theme (e.g. light scrollbars on dark-theme surfaces) or accidentally left unstyled
• scrollbars not fully nestled into their correct edge, accidentally being offset from the top or the right
• using a wrong CSS setting for overflow (or not knowing about the -x and -y variants), and consequently showing both scrollbars when one will suffice
• the loading state or skeletons not anticipating a scrollbar appearing later
• that most frustrating occasional math/​measurement issue where the appearance of vertical scrollbar reduces the horizontal space, and as a result also makes a horizontal scrollbar appear (see also: scrollbar-gutter)