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)
During my first year at Figma, I designed and printed a run of posters for the office titled “Design is more.” The idea was to highlight that UX design is more than people expect, and connected in interesting ways to other domains. Today, they feel like a spiritual predecessor to this blog.
The first series was three posters:
I still (mostly) like them. I do believe that software can learn more about conveyance from video games; a lot of first-run experiences and particularly new feature onboarding still feel like a series of random pop-ups floating around the screen without much understanding of me as a user.
I would rewrite these posters, however, and particularly the Fitts’s Law examples: they’re generic and probably not as relevant to today’s applications.
After series one, we also collaboratively started working on series two, but the pandemic put a halt to the effort, and these posters were never finished/printed. But the two below were perhaps closest to ready, and they seem fun today; I particularly liked the joke on the Hick’s Law one.
Jon Yablonski, the author of “Laws of UX,” made some posters in a similar vein and they’re available for purchase. His are slightly more on the visual side, but I was delighted to discover today that we both chose a rather similar approach to visualizing the Zeigarnik Effect.
There are fun things you can do in software when it is aware of the dimensions and features of its hardware.
iPhone does a cute Siri animation that emanates precisely from the side button:
A bunch of Android phones visualize the charge flowing to the phone from the USB port…
…and even the whole concept of iPhone’s Dynamic Island is software cleverly camouflaging missing pixels as a background of a carefully designed, ever morphing pill.
But this idea has value beyond fun visuals. iPhone telling you where exactly to tap twice for confirming payment helps you do that without fumbling with your phone to locate the side button:
Same with the iPad pointing to the otherwise invisible camera when it cannot see you:
Even the maligned Touch Bar also did something similar for its fingerprint reader:
The rule here would be, perhaps, a version of “show, don’t tell.” We could call it “point to, don’t describe.” (Describing what to do means cognitive effort to read the words and understand them. An arrow pointing to something should be easier to process.)
You could even argue the cute MagSafe animation is not entirely superfluous, as over time it helps you internalize the position of the otherwise invisible magnets on the other side of your phone:
In a similar way, as it moved away from the home button, iPhone X introduced light bars at two edges of the screen – one very aware of the notch – as swiping affordances:
And under-the-screen fingerprint readers basically need asoftware/hardware collab to function:
One of my favourite versions of this kind of integration is from much earlier, where various computers helped you map the “soft” function keys to their actual functions, which varied per app…
…and the famous Model M keyboard moving its keys to the top row helped PC software do stuff like this more easily:
(And now I’m going to ruin this magical moment by telling you the cheap ATM machine that you hate does the same thing.)
The last example I can think of (but please send me your nominations!) is the much more sophisticated and subtle way Apple’s device simulator incorporates awareness of the screen’s physical size and awareness of the dimensions of the simulated device. Here’s me using the iPhone Simulator on my 27″ Apple display. If I choose the Physical Size zoom option, it matches the dimensions of my phone precisely. The way I know this is not an accident is that it remains perfectly sized if I change the density of the whole UI in the settings.
Why am I thinking about it all this week?
The new MacBook Neo was released with two USB-C ports. Only one of the ports is USB 3, suitable for connecting a display, an SSD, and so on. The other port’s speeds are lower, appropriate only for low-throughput devices like keyboards and mice.
To Apple’s credit, macOS helps you understand the limitations – since the ports look the same and the USB-C cables are a hot mess, I think it is correct and welcome to try to remedy this in software. It looks like this, appearing in the upper right corner like all the other notifications:
I think this is nice! But it’s also just words. It feels a bit cheap. macOS knows exactly where the ports are, and could have thrown a little warning in the lower left corner of the screen, complete with an onscreen animation of swapping the plug to the other port – similar to what “double clicking to pay” does, so you wouldn’t have to look to the side to locate the socket first.
“Point to, don’t describe” – this feels like a perfect opportunity for it.
In my head, some bugs belong to categories that feel important, and yet remain hard to define and quantify: embarrassing bugs, dumb bugs, flow killers.
Somewhere in the hard-to-explain space is another tricky category: UI decisions that feel cheap.
The examples of cheapness that come to my mind readily will, I bet, be different for each one of you reading this:
using emoji instead of iconography
using text and typography instead of graphic design elements as UI (except in terminal/text-based interfaces)
excessive centering
obvious misalignments and overflows
accidentally mismatched fonts and unspecified fallback fonts
reflow and bad loading states that do not match the eventual UI
selectable user interface element that betray “bad webiness” of the UI
typos
But my absolute #1 go-to example is definitely this:
Computers could pluralize nouns basically for free already in the 1970s, and sure, there are objective arguments of why this is bad, but there’s also this: I wince so hard every time I see something like this.
I think it’s important for every designer to notice when they wince, and teach others how to wince and notice, too.
(I stole the brilliant title from this short post by Joe Leech in 2018, in which Leech uses the word “lazy” rather than “cheap” – they’re related!)
Those terms confused me back in the day, and occasionally they still do, so I thought it might be nice to write it all out. This is how I understand them:
deterministic: whenever you do something, it gives you identical results as any previous or next time you do it
idempotent: if you do something twice, or thrice, or more times, it will be the same as doing it once
But “deterministic” in UI design might mean something more specific. Let’s take pressing ⌘B to bold, for example:
Every time you press ⌘B on an identical selection, it will behave the same. But, pressing ⌘B doesn’t guarantee something will get bold. If it already is bold, the command will reverse its meaning. In this sense, ⌘B is non-deterministic.
It’s not hard to imagine a determistic version of bolding. Make ⌘B bold the text, and make another shortcut – say, ⌘U – unbold it. This way, you can always press either and be absolutely confident you will get a predetermined result without worrying about anything else. It’s a boon for motor memory, but it is more complex to explain, and it adds more UI surface.
There is also another, more interesting way: you can make ⌘B always bold first, and unbold second. This way, your fingers can remember ⌘B is for bolding, and ⌘BB is for unbolding. But this also gets tricky: for already fully bolded text, it might seem the feature is broken, because the first keystroke does nothing!
Only the second of these three approaches is idempotent,meaning you can invoke it many times and it will always give the same result:
⌘B toggles bolding from current state: non-deterministic, non-idempotent
⌘B bolds, ⌘U unbolds: deterministic, idempotent
⌘B toggles bolding, always starts from bold: deterministic, non-idempotent
One of my favorite idempotent concepts is the Clear key present on many calculators, and still on some larger Mac keyboards.
The idea behind Clear is simple. Let’s say you’re a professional keypad user – maybe an accountant? – typing in numbers for hours a day. You just made a mistake. Pressing Backspace will remove the last digit, but are you sure you only made a mistake on that last digit? What if your fingers brushed another key and you typed in two digits by accident?
Instead of using the non-idempotent Backspace key where you’d have to look at the screen to confirm, it’s easier just to press the idempotent Clear which will always remove the entire number, and then start from scratch without even having to look anywhere (as gamers would say, “no scope!”).
And, for people who are moving fast, it feels safe just to press the shortcut or a button instinctively, for ease of their mind, even if nothing has to be done. Some people might choose to press it a few times, just in case. The Esc key often has that property – isn’t it just nice to slam Esc many times? – and Jeff Jarvis in his 2014 essay talked about another shortcut that felt that way:
Since I don’t need ⌘S anymore, I can now appreciate how much it had become a part of my ritual of writing and even of thinking. I used to hit ⌘S not just as data insurance — hell, I’d often hit it after having not made a single change in my text since the last time I’d hit it. I hit ⌘S as a break, a psychic, semiotic semicolon. It gave me a moment to search for the right word, to plan the structure of where I would go next, to commit to what I’d written, or to wonder whether I had the courage to erase what I’d written and try again.
(In Figma, where ⌘S wasn’t necessary, we used to show this – but we only showed it once every fortnight, since some people would press the shortcut instinctively like Jarvis, and find the message distracting and maybe even patronizing.)
All of these options have pros and cons. The beauty of determinism and idempotence is that they free you from paying attention. I always get a bit nervous when someone tells me that in their country, you can press the elevator button again to unset it. Even if you don’t make a button a toggle, visually disabling it or showing a message (“Nothing to delete!”) when it has nothing to do could feel like a friendly gesture toward newcomers, but its non-idempotence will grate people who know what they’re doing. Determinism and idempotence are good for motor memory to develop, but – just like the above bolding example – might be initially more confusing.
The approaches can coexist; browsers give you ⌘⌥←→ to move between tabs (non-deterministic, non-idempotent) and ⌘1/2/3 to switch to a specific tab (deterministic, idempotent). Some places even offer a choice. In macOS, you can say whether you want clicking on a scrollbar chute to be deterministic or not:
…although usual choice-giving caveats should apply.
I think it’s good to think about those things, especially for interfaces used professionally. Magical things happen if you can trust your fingers and sometimes, if you worry too much about novice users, that might make it hard for pro users to emerge.
This was a fun 15-minute architectural video from Stewart Hicks (absolutely worth a follow otherwise) that mapped precisely into the same kind of tension and internal debate I sometimes feel when talking about minimalism in UX design: Minimalism is good! Until it’s not!
One interesting lesson here is that the famous “less is more” was actually – surprise! – perverted from the original poem, where it meant “less technical perfection means more emotional impact.”
I wasn’t fully sure why Hicks decided to incorporate a commentary to his own story this way – maybe he was afraid that the sarcasm of “steel wanting to share its joy” and “lessness” and “simplificity” wouldn’t land well? Or perhaps it was just the introduction that didn’t quite work for me, as it confused the entire joke.
But it was fun to watch it twice anyway. Those stories are never easy. I am not ready to draw too many parallels between architecture and UX design, even if Hicks lightly does so at the end. There’s no gentrification and displacement when Liquid Glass takes over Aqua, although I think a lot of people would love to see a Apple’s recent design decisions meeting the business end of a wrecking ball.
My favourite recent saying to replace “less is more” is this, by Paul Valéry (another poet!):
Everything simple is false. Everything complex is unusable.
You can see it as unsolvable, cynical, maybe even nihilistic. I do too, on a dark day. But more often, I see it as a great challenge. “Less is more” has this simplistic seductiveness that feels naïve. “More” is not an option, but often in my work on complex systems “less” is neither, and a lot of UX design is finding the perfect shade of gray.
I think a lot about bugs or design decisions that make software appear dumb.
At some point in my career I started fitting everything against two principles: “don’t make your app treat your user as if they’re dumb” and “don’t make your app itself feel dumb.”
To wit:
This is, very obviously, my website. I have made it from scratch. I have visited it a million times. And yet, at some point my friend Noah shared a link of it with me, so now Safari occasionally announces that with glee when I check it out.
Me having visited something many times should outweigh someone sharing it with me once.
There is a close box here, although you have to hover over the bar to see it. (And, after closing, it seems to come back after a few days!) I can also right click and choose Remove which does… absolutely nothing.
I believe this whole feature is called Shared With You. Elsewhere, on occasion, I find it useful. But its tentacle right here makes Safari appear just… kinda obtuse.
Also, speaking of obtuse: Can you spot a grave typographical mistake I made on this screenshot? (I already fixed it in production.)
I was embarrassed for Apple when I saw the recent bug fix for columns introduce a new bug, explained in this post by Jeff Johnson:
Without the path bar, the columns are now taller, but the vertical scrollers remain the same height as before, leaving vertical gaps, a ridiculous amount of space between the bottom of the scrollers and the bottom of the columns, looking silly and amateurish.
It’s impossible to talk about craft without talking about embarrassment, and pride, and shame, and lust, and a lot of other words – all tricky to describe, all fluffy. So, I tried to interrogate my feelings.
First, it was embarrassing that it broke. I’ve been there: you build a complex system, and forget about some lesser-known state. That’s why it’s important to invest in whatever it takes to shine a light on those states: quality assurance, automatic screenshotting, tests, and so on. Sometimes it’s simple hacks – like half of your team having scrollbars visible. And when you notice a bug, you try not to just fix it, but to rebuild it to be stronger (“leave the campsite in a better place you found it”) – be it by fixing the cause and not just the symptom, adding unit tests, changing practices, and so on.
But it also felt embarrassing how it broke. It feels clear there’s some manual calculation going on somewhere, and someone forgot to add this new change to it. One of the tricks I learned over time is that a well-designed system designs itself, but it takes effort and imagination to make a system resilient in this way. Here, if there was some abstraction of “adding stuff to the bottom,” then you wouldn’t have to worry about adding extra math. The system would take care of itself in many of these corner cases you will forget about.
I don’t want to shame (see, that word again!) individual people at Apple because I don’t know if it’s the lack of talent, or the whole system being wired in a way that doesn’t reward forward thinking or the kind of invisible work that needs to happen in those spaces. But the embarrassment should be there – if it doesn’t exist inside Apple, then that’s perhaps the sign of a real problem.
Old-school computing has a term “molly guard”: it’s the little plastic safety cover you have to move out of the way before you press some button of significance.
Anecdotally, this is named after Molly, an engineer’s daughter who was invited to a datacenter and promptly pressed a big red button, as one would.
Then she did it again later the same day.
You might recognize molly guards from any aerial combat movie you ever watched:
And some vestigial forms of molly guards exist everywhere in civilian hardware, too: from recessed buttons, through plastic ridges around keys, to something like a SIM card ejection hole.
Of course, molly guards happen in software, too: from the cheapest “are you sure?” dialogs (which sometimes move buttons around or disable keyboard activation to slow you down), through extra modifier keys (in Ctrl+Alt+Del, the Ctrl and Alt keys are the guards), to more elaborate interactions that introduce friction in places where it’s needed:
But it’s also worth thinking of reverse molly guards: buttons that will press themselves if you don’t do anything after a while.
I see them sometimes, and always consider them very thoughtful. This is the first example that comes to my mind:
Here’s what became a standard mobile pattern:
These feel important to remember, particularly if your computer is about to embark on a long process to do something complex – like an OS update or a long render.
There is no worse feeling than waking up, walking up to the machine that was supposed to work through the night, and seeing it did absolutely nothing, stupidly waiting for hours for a response to a question that didn’t even matter.
It’s good to think about designing and signposting those flows so people know when they can walk away with confidence, and I sometimes think a reverse molly guard could serve an important purpose: in a well-designed flow, once you see it, you know things will now proceed to completion.
After James Moylan’s death in December, we were reminded again of the Moylan Arrow, the little arrow telling you which side of your car has the little fuel door:
I started wondering: what would be the conceptual equivalent of this in software? My best guess would be iOS offering to fill the one-time code from a recent SMS:
This is what it has in common with the Moylan Arrow:
everyone benefits from it
it happens all the time
it solves an actual little (but not too little) frustration
it’s there at the right place at the right time
it is relatively low-tech (it’s not an overdesigned or an overengineered solution)
once you know it’s there, you will love it forever
Curtosis on Mastodon unearthed the original 2019 Twitter thread from one the creator of the iOS feature, Ricky Mondello (link to XCancel), which I‘m reproducing here:
The idea for Security Code AutoFill came out of a small group of software engineers working on what we thought was a much more ambitious project. It wasn’t a PM, it wasn’t just one person, and it wasn’t what we set out to do initially.
It started as a small side idea we had while designing something very different. We jotted it down, tabled it for weeks, and then picked it up after the “more ambitious” project wasn’t panning out. It was hard, but I’m so glad we changed focus.
Even with a gem of an idea, it was still just an idea. Ideas are obviously super important — they’re necessary, but not sufficient. Here, the end result came from the idea, teamwork, and execution.
Years later, I’m still so proud of the team for making this feature happen. The team combined expertise from several areas to ship magic that worked on day 1, while asking nothing of app and website developers, without giving anyone your text messages. This still inspires me!
To every one of the folks who made this happen, I’m still in awe. Y’all are the best. <3
Addendum: FAQs
- “SMS is bad.”
↪ I know.
- “MITM.”
↪ I know.
- “FIDO is better.”
↪ It’s complicated, but acknowledged; I totally get it.
- “Android did it first.”
↪ Nah. Details matter. Privacy matters. And clipboard != AutoFill.
- *negativity*
↪ Not now. :)
I asked others on social and here are some other contenders I liked:
The indicator that alerts you of Caps Lock when typing passwords
Start spending time in the online photography sphere and you’ll start to notice a small but undeniable undercurrent of lament of its loss to this day. Find an article about Adobe hiking their subscription prices because they added AI for some reason, and amongst the complaining in the comments you’ll invariably find it: “I miss Aperture.”
Kennett goes deep into two specific details: the HUD-like UI that travels to the photo, and the technically impressive loupe. It’s worth checking it out just to reflect on the importance of execution; ostensibly those features exist in Adobe’s Lightroom (Aperture’s main competitor), Photos, etc. But Aperture designed them in particularly memorable and impressive ways.
Back in the early 2010s I used Aperture, too. I was rooting for it. I felt like it was designed, and Lightroom merely existed.
It reminded me of the 1990s when I felt the same about Netscape 4 over Internet Explorer 4. There was something about Netscape’s feel that appealed to me more. The way buttons were designed. The way they responded to clicks. The way pages loaded. All these little nuances. This was perhaps the first time I appreciated one app over another for things I didn’t know how to measure, or perhaps even describe.
Aperture vs. Lightroom feels like a similar story, because for all my appreciation for Aperture, I remember it being slower than Lightroom, and the noise reduction (much more important 10+ years ago) was worse, too. In a small way, it was a relief that Aperture was discontinued, because it saved me from a tricky choice: better designed vs. technically superior.
But: I miss Aperture, also. Maybe it would’ve caught up technically today and it would’ve been the best of both worlds. To this day, I use Lightroom (now Lightroom Classic). If it’s filled with UI quirks, it’s mostly bad ones. If there is beauty in it, I no longer know how to see it. It’s a tool in the most reductive sense of the word. My photos deserve more.
Also something I learned from Kennett:
“Shoebox” apps are apps that contain the content you use with them, as opposed to document-based apps which work with content you manage as a user. It’s an extremely common design nowadays, but less so back then — early pioneers of the shoebox app were iPhoto, iMovie, etc.
