“This way, the interface does not get in the way.”

Ilya Birman on his blog talks about interfaces that unnecessarily slow people down, in a series of two posts.

In the first one, titled “Let me click,” Birman shows a few places that force the user to go through a roundabout series of clicks, instead of taking a direct route:

In Aegea’s comment settings, there is a “send by email” checkbox with an email-address field associated with it. If the checkbox is unchecked, there is no point filling in the field: the address is not needed for anything else. If the checkbox is checked while the address is blank, the system cannot send anything as it does not know the address. In short, these controls are interconnected. Logically you could disable the input altogether if the checkbox is unchecked — there is no point filling it in anyway. But that is irritating. What if I want to enter the address and then turn on the checkbox? It would be even worse not to let me turn off the checkbox when the address is filled in. I want to turn it off — let me click!

In a follow-up, Birman talks about a specific example from the podcast app Overcast, whose creators faced with a tricky systemic challenge:

For any podcast, you can set how many episodes to keep downloaded on the device. Say you set the limit to three, then stop listening to a podcast regularly: the next three episodes download, and after that it stops downloading them — why waste the space? [But,] what if someone manually asks to download an episode when they already have three downloaded? You can’t just immediately delete it to keep things tidy. Finally, Marco’s wife Tiff suggests a solution to all the problems: just don’t let users download more episodes, she said, and show them a message, roughly: “Your episode limit is three, but this would be the fourth, denied”. Marco liked the solution. I didn’t. Sure, it solves Marco’s problems, but not the user’s.

I haven’t seen the Overcast block in action, but all of Birman’s examples across both blog posts rang true to me. Motor memory wants what it wants, and stops for no one.

I wanted to add two things from my end.

1.

Birman presents this as “Let me click,” but I wanted to offer two alternative/​complementary principles that helped me before:

• Let me do things in any order. Here’s Google Home app, where I can change the temperature and the time for holding – but if I change the time first, it frustratingly resets when I subsequently change the temperature. It forces one specific order in an interface that suggests any order is okay:

• The current action has the most momentum. The user is right there, active, tapping on things, wanting to get stuff done. If Overcast indeed throws a “your episode limit is three” message, then it forces the user to remember how to get to the settings and change it. The momentum is lost. The decisions of past me should not be as important as the decisions of present me.

2.

I agree with all the examples given by Birman, but things can be stranger, and sometimes letting people click or do things in any order can make the interface harder to understand.

In Figma, each text box dimensions could be set to be completely automatic (automatic width and height – used for short labels), with only specific width (and automatic height – used for paragraphs of text), or with manual width and height (used for graphic elements):

You can also see that in text boxes where width or height are automatic, the fields for those values are grayed out, and cannot be changed. In order to change them, you have to switch to a particular mode first, which makes the relevant fields active. This is to help people understand how those things relate to one another in a pretty tricky space, but it effectively means sometimes Figma won’t let you click, and will force you to do this in one specific order.

But this is only in those fields – you can always grab the object on the canvas and resize it, and it will switch to manual on its own, respecting the drag’s momentum:

The inconsistency here is intentional. I’m not saying these are the right choices, and we indeed heard from some users frustrated that they cannot click easily when they already understand the system (unfortunately, I am aware of no good affordance for “breaking” a disabled field in modern GUIs, like a molly guard). I mostly wanted to share that these things can be hard, and the balance between “let me click” and “not being able to click can be helpful in understanding the system” tricky to achieve.

I keep thinking of the story from a decade ago when someone’s phone rang at the front row of a New York Philharmonic’s concert, prompting an actual performance halt, and anger from both the conductor and the audience. The ashamed patron’s eventual explanation was: “I turned the phone to silent, but I also had an alarm set up.”

Let’s assume this is actually true (in people’s reports, the phone rang the marimba ringtone, which isn’t standard for alarm – but people’s recollections are routinely flaky, too). This, I think, is a perfect example of “let me click” in action. You can set an alarm for a certain time, and you can subsequently turn the phone to silent. You can also do it in the opposite order. You just gave your phone two inconsistent instructions, and the phone logic decided in either case the alarm will win.

I can’t think of an easy interface solution here. It feels correct for the order to not matter here. It’s hard to imagine disallowing you switching to silent mode with any alarms on, since the silent mode also affects calls. It’s also hard for me to imagine any effective UI warnings at any given moment in the process. (Besides, back in the day, iPhone used to give you a gentle one via a little alarm icon visible in the top bar.)

The silent mode and the alarms are, as Birman put it, interconnected – but their connection is ultimately tricky to explain to the user.

#case study #details #flow #system design