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.
It was fun to see one of the most well-crafted of early arcade games, Tempest, in this kind of a view, with the stud reimagined as a paddle controller:
The M2x2 is a functional homage to the classic Lego computer brick, upscaled and re-imagined as a high-performance workstation. […]
If our tools could look as playful as the things we built as kids, would we approach our work with more joy? The M2x2 is just the beginning of a workspace that feels less like an office and more like a laboratory for breakthroughs.
But both of these are enlarged Lego bricks. Three years ago, James Brown a.k.a. Ancient made an effort to embed an LCD screen in a regular-size Lego brick. It’s a fun 12-minute video of the construction process:
But the most amazing to me outcome was this video, called “Busy little screens”:
A lot of diversity of the original bricks is gone, but it’s hard to expect Brown to recreate and animate them all. It’s a mesmerizing thing to watch nonetheless; one can almost taste a future where the technology will allow for Lego bricks to be animated, but look exactly as they originally did.
Nice, clear, simple copy in ClarisWorks from 1997:
No “Maybe later.” No “Not now.” Thirteen characters. Now, Later, Never.
(Can’t help but notice that Esc and ⌘. – the classic Mac’s equivalent of Esc – still map to Later, however. Also, this breaks the rule of button copy being fully comprehensible without having to read the surrounding strings first, perhaps most well-known as the “avoid «click here»” rule. Never Register/Register Later/Register Now would solve that problem, but wouldn’t look so neat.)
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.
I’ve learned recently that “rubber banding” can mean at least three different things in the context of UI/UX design:
whatever happens at the edges of your scroll container when you’re using elastic scrolling, which started on the first iPhone and have spread more widely since
in videogames, balancing the difficulty in real-time so that inexperienced players stand a chance and good players are not bored (a classic example in any racing game is computer-controlled cars slowing down if they are running too far ahead, as if held by a rubber band, to give you a chance to catch up)
in multiplayer experiences (mostly videogames, too), the experience of snapping back and forth (example) during gameplay when your connection speed is low and the game has to reconcile your predicted position with your real one
Each one is interesting in its own way. (Each one is also controversial, although for a different reason!) But what I understand they all have in common is – well, obviously – the specific mechanics of rubber banding.
I imagine many reading this are familiar with basic interpolation between A and B using curves like ease in, ease out, and so on. But in gaming and I think increasingly in UI design, that’s not enough. When coding stuff related to movement – imagine dragging an elastic scrolling view near its edge – the challenges compound:
the object might already be in motion
its destination might also be in motion
the load or framerate can vary, so calculations have to take that into account
With that in mind, I found these two videos helpful and informative:
The videos together start with basic lerp (linear interpolation), then move to lerp smoothing, and then arrive at frame-independent lerp smoothing. There’s light math/physics here, but that’s to be expected, as all these experiences are meant to feel like real-life objects would.
I found especially lerp smoothing where you feed a lerp into itself particularly conceptually beautiful.
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.
Let’s say you are in Reeder (an RSS reader for iOS), looking at the list of posts, and already from the title you know you don’t care, and you want to mark it as read.
You can tap to see it and then swipe back the moment it shows. This is the slow path.
There is a faster path. Reeder enables you to slide right or left on the item. You get nice haptic feedback, and many apps support this kind of an interaction.
But there is an even faster path.
You can tap to see it and immediately swipe back. Your thumb is already there on the left anyway, and the distance is a lot shorter now.
Like every advanced gesture this takes a bit of practice, but I noticed I started doing it instinctively, without even thinking.
This happening required two small design details: The original slide transition to be interruptible at any moment, and the app to support swatting/draging the incoming item away even if my finger was nowhere near it. Both are clever, and both feel very welcome, because they enabled this emerging (to me) behaviour that made going through the list snappy without me even realizing.
This might be a good modus operandi: Think of the slow interaction. Think of its fast version. Then, think some more.
Nicely done, Reeder team. (Or, if this is a default iOS behaviour, nicely done, Apple!)
I was delighted by the Laws of UX website when it came out. The site was beautiful (it still is!) and it felt important to bring some of this stuff to designers earlier in their careers.
But the book based on the website was largely a disappointment, and seems like a good case study of an unsuccessful adaptation – it felt this was pushed to become a book without editorial help and without thinking too much about what makes for a good book.
The book lost a lot of what made the site great – it’s a pretty generic-looking production with flawed typesetting, an uninspired cover, and poorly sized and reproduced images. But chiefly, I also feel the book showed there is limited rigor behind the whole premise; the writing feels academic in the sense that it’s a little boring, but academic writing at least can be precise and follow process. Not here. The laws of UX are not “laws” in the traditional sense and the combination of “laws” presented, as well as examples of them in use, feel really arbitrary and sometimes at odds with the entire premise.
I felt disagreeing with the book often. For example, I feel the chapter about Doherty Threshold feels is teaching the wrong lessons (100ms is not enough for a bunch of things!). Or the advice on gradually deploying changes (Jakob’s Law) is missing a core component of maintenance and how to approach the contingent of users who will never graduate to the new interface if given a chance to stick with the old one.
I also started worrying that the book doesn’t fully understand how design works. From the very first page:
This project was somewhat unique in one specific way: I was being asked to justify a number of design decisions to project stakeholders, without any data to support them. Normally, when you have quantitative or qualitative data available to draw upon, this is pretty straightforward task – but in this case the data wasn’t available, so the process of justifying the decisions would have to be a little different.
This is… This is not what design is. This is never true. You rarely have the data – and if there’s data, it’s never netural, always at the mercy of people collecting it and people interpreting it.
My friend summarized it well – “design is not mathematical” – but at various moments the book suggests it’s as simple as knowing a certain “law” and applying it. This is perhaps most visible in the Aesthetic-Usability Effect chapter, which touches upon craft without really understanding it.
On the positive side: I think what the book is trying to do feels important and appreciated. Some of the stuff like Fitts’s Law or Doherty Threshold and Jakob’s Law are good to know about, they are still relevant, and can serve as useful tools in your toolkit as a designer.
I also learned some new things from it! I have never heard of shape coding before (turns out I’ve been practicing it without knowing, so learning about it was validating), and never really thought about the equivalent of heat maps for mobile.
Also: I don’t think this book is for me. I get a sense this is a volume for a very different group of UX designers, maybe even people at companies where UX design is not at all established as practice. There is a lot of stuff like explaining personas and basics of user testing and even ethics that feels somewhat out of place and like it’s padding the content – but I can see how that could be valuable. However, I still wish the book didn’t oversimplify a lot of things like I think it does. I believe there’s a way to do it while still keeping it accessible and not overwhelming.
But today, I would rather recommend the beautiful poster that seems more true to what the website was trying to aim for.
In terms of how I would improve the book:
Have it reviewed by someone who actually lives and breathes this stuff for living.
Invest in better writing and better storytelling. This of good stories and not just data. Ditch the random O’Reilly-esque callouts and integrate them into the stories.
Either get deeper into more specific and deeper examples for most of the stuff, or make it drastically shorter.
Don’t package it all as “laws”, or at least – if this title sells – contextualize it better inside. These are useful tools, but they are not laws like physics has laws. Also, all of them, like most of design, will be caveated with “it depends.”
Consider adding stuff about motor memory, Sturgeon’s Law, monotony, gestalt to flesh out the toolkit, and maybe group the chapters into a few bigger areas.
Chapanis began interviewing pilots who had crashed B-17s and B-25s and a pattern emerged that turned his attention to the controls within the cockpit. As Fitts said ‘the intense effort to produce new weapons, the race against time in industrial production, and the magnitude of the program required to train men to operate these new machines resulted inevitably in many instances in which the final man-machine combination failed to function effectively.’
What Chapanis found when inspecting the cockpits of these planes were two identical toggle switches side by side, one for the landing gear, the other for the landing flaps. These controls were also similar in size and shape. […]
He modified the landing gear control by adding a wheel-shaped knob and a wedge like shape to the wing flap control. Now pilots could feel and easily map the shape to the intended purpose. […] Chapanis had solved a real life and death issue with one brilliant insight.
Chapanis was a contemporary of Fitts of Fitts’s Law fame.
I forgot this was called “shape coding,” or perhaps I never knew that? I have employed and sometimes pushed for a similar thing, but I called it making sure things have “distinct visual signature” or something like this. I think “shape coding” would be a more appropriate term.
The article shows one simple UX example – I would love to learn more about who’s employing this deliberately. It is, after all, the opposite force to consistency, and I’m always interested in negotiating with consistency.
Oh, this is a fantastic adage I haven’t heard before, mentioned here in 1978, arguing against distorted, or “faux” typography:
A Linotype assembly elevator with the gate closed. This is the center of an operator’s attention as the mats tumble down and are arranged automatically in lines. The spacer bands adjust themselves to fill out the line but only so many letters can fit in any measure, proving the old trade adage that “type is not rubber.” Modern photocompositors have lenses that can distort the image of the letters to fit where they couldn’t. Today, type is rubber.
