User Interface Design: Rules of Thumb
mannhowie.com
mannhowie.com
In the software world, designers need to be engineers (or work very closely with engineers, very early in the process). We recently had designers give us a nice looking progressive indicator for a non-progressive operation that happened to take a somewhat predictable amount of time. Business loved the look and visual feedback. Then we got use cases where the operation could be instantaneous. They didn't want to skip the progress animation because they liked how it made the app feel like it was doing something, and also if the user got the result instantly, it was "jarring". So now, even if the operation finishes instantly, we show the animation, wasting the user's time.
I find a small acknowledgement that the thing works is better than just having an arbitrarily long loading indicator.
For greater guidance on this, the Nielsen Norman Group spake thusly:
> Use a progress indicator for any action that takes longer than about 1.0 second.
> [A looped loading animation] should be reserved for actions that take between 2-10 seconds. For anything that takes less than 1 second to load, it is distracting to use a looped animation, because users cannot keep up with what happened and might feel anxious about whatever flashed on the screen
> Generally, percent-done progress indicators should be used for longer processes that take 10 or more seconds.
Spinners are typically used for "indeterminate" operations while progress bars are typically used for "determinate" operations¹.
"Progressive" is a less useful adjective here because indeterminate operations progress too, and it's just that their total duration can't be usefully estimated.
And as you note these aren't hard-and-fast rules, and a spinner is generally a perfectly fine choice for short determinate operations.
¹ Progress bar controls typically have an indeterminate flavor too, and these can be mixed. For example, you'll typically see an indeterminate form of a progress bar until a total duration can be estimated, at which point the progress bar will change to its determinate form.
Good point - I was simplifying by referring to all progressive animations as "progress bars" and all non-progressive animations as "spinners".
>indeterminate operations progress too
I normally think of "non-progressive" and "indeterminate" as synonymous in this context. If the UI can't tell what fraction of the whole has been completed by any metric (which could even include best guesses based on historical data), I refer to that as non-progressive or indeterminate, interchangeably.
I thought it was fairly well accepted that small deliberate UI delays (for things like loading spinners and animations) can in many cases result in a better user experience. Of course, that would depend on how long this animation is that you're talking about.
Like hard bristle toothbrushes. Hard bristle toothbrushes are not good for your gums. So why do they make them? Because customers like hearing the sound of the toothbrush brushing. They like hearing it do something.
Maybe this would be a useful way to look at it: if the average disorientation caused by instant change (which also depends on whether the change is predictable, makes other things change position, etc.) takes longer to recover from than the shortest animation/fade you could come up with, have a transition.
(but even then it doesn't hurt to gate all of that behind a global configuration option, IMO, and if you want to be really fancy make it a float, not a boolean)
He's drawn one of those circle-in-a-slot switches. I often have trouble figuring out what the on / off state of those is supposed to be. And then the discription "flash mode" makes it even more unclear how a switch state corresponds to app state (does on mean enabled? does on mean suppressed?).
The good example for "email weekly summary" is actually good, because checkboxes have a clearly enabled / disabled state and if it's enabled the user knows the thing in the text next to it will happen. It's clear. "flash mode" should be re-written in the "email weekly summary" style. It would have a checkbox with a label "use Adobe Flash for rendering."
I also think flash mode is represented well on most camera apps. I wouldn't change a thing about them other than maybe adding a text label.
"Flash mode" is the problem.
"Flash is on/off" is the solution.
("is" is important here. "flash on" has many ways to be interpreted because it's missing a verb.)
Your UI should be understandable from text alone if needed.
I can understand why designers and even developers want to not use text: Handling multiple languages is annoying and getting people to read is impossible.
But you know what? I don't understand what that fucking black-and-white hieroglyph you pulled out of your ass five days ago fucking means.
Compare that to a checkbox next to "Flash is disabled". Or a toggle. Or a button. The control and its vague state or bad color blindness choices doesn't even matter if you're clear with your words.
iOS has an option to display I/O labels on these toggles too, and as it turns out, not everyone knows that I/O refers to on/off. I found out about this when I had to explain to a friend that those symbols meant open and closed respectively on the vents in a car.
The standby symbol ⏻ combines the two.
I always thought that's literally what it represented, true (on) and false (off).
Is this an instruction or a status?? https://i.imgur.com/2u8RlDG.jpg
The population can be further subdivided into camps which disagree over what enabled and disabled even mean in this context.
Literally any design choice is better.
a. The function exists
b. Where it resides
c. That it requires some condition to be satisfied before usage
Later I went through sent messages and the urgency indicator was opposite of intended on all. I looked at the form more closely and realized that the label was actually indicating what clicking the checkbox would change the state to, so clicking indicated it was not urgent.
I emailed the company about the confusing behavior and received no response.
Having a verb helps.
Here'a blog post with more examples, and tips for checkboxes.
- Options which any particular user might want to change on a regular basis. These should be near the "front" of the UI within reach according to how often a user might be expected to change it.
- Options which different users may select differently, but which a specific user is unlikely to change. These can be buried, as long as they are easily discoverable so that users are at least aware of the option.
Also please make toggles unambiguously on or off. Those little sliders, especially solo, can be difficult to figure out the current state of. Maybe put the word "On/Off" right on the slider itself. Or put the state in the label: (-0) Flash is ON. (0-) Flash is OFF
Now that you got the UI right, stop tweaking and changing it. I can't stand when the UI on so many apps and webpages change simply because the UI folks and programmers need something to do.
If you like an app and don't want the UI to change, tell the company. as long as all the people who like it are silent and all the people who don't like it are complaining loudly, apps are going to keep changing.
* Avoid single choices. If there's only one possible choice, don't waste the user's time by requiring an action. At most show that that value is chosen.
* Select the best defaults you possibly can. If some extra coding work allows pre-selecting the right default infor 50% of the users without making it harder for the rest of the users, it's a win.
* Remember the user's input. Making the user select the same thing again and again is insulting.
* Don't have an explicit setting when an implicit one will do. The width of a panel can be remembered from the last time the user resized it, there doesn't have to be a place to enter a value for it.
This is an anti pattern which good directly against the concept of "affordance."
I was testing a web app out on my dad and he dragged the cursor to the bottom of the screen, which brought up the Mac Dock which immediately confused him and he asked my why I did that. I am not sure how to code around just general inability to use a computer, maybe avoid elements at the edges of the viewport haha.
These days, things are pretty much "stupid proof." No matter how many times I insist on it, people my parents' age simply refuse to believe that there is nothing they could reasonably type or click while using their computer that will irreparably harm it. (Yes, of course they could somehow format their hard drive, etc, but there's zero chance you'd be able to do that on accident.)
I don't agree with this generalization. Here's an example: A stereo receiver, even today's A/V receiver, has a certain number of physical inputs. Back in the day, you had buttons on the front to select the input you wanted, clearly labeled. One press gets you the source you want, every time.
Many receivers today force you to press an Input button or turn a wheel to iterate through a list of inputs, a list of unknown size and unknown beginning and end. This is because the display idiotically doesn't show a complete LIST of the inputs at once, or even a moving dot to show you where you are in the list. So you could be one input below the one you're trying to select in the list, but if you happen to turn the dial the other way you'll go through 10 inputs to get back to it. Granted, this is much less commonly encountered now because nobody is going over to his receiver to put a disc in the player, but it was a problem for many years when people were still doing so.
In some cases, older designs were also better for safety. When safety is on the line, the best design (or at least universally-understood standards) often percolate to the top and stay there.
A sad example of this was Jeep's attempt to "innovate" with a disastrously defective gear shift, which killed Star Trek actor Anton Yelchin: https://www.theguardian.com/film/2016/jun/20/star-trek-actor...
But I also acknowledge that there have been major safety improvements. The other day I rented a chain saw for the first time and was comforted to see the safety brake on it.
> people my parents' age simply refuse to believe that there is nothing they could reasonably type or click while using their computer that will irreparably harm it
Another example is that our last TV had a "Source" Button. But it doesn't change the source, it brings up a list so you can choose a source. Nearly every week she would accidentally hit Channel Up or Down on the TV remote and then not know how to switch it back to the Cable Box. She'd hit Source and it wouldn't change the source and then call me.
Sadly, she has dementia now and will never learn.
Peek-a-boo UI is incompetent. It's even dumber when you consider that, in most cases, the space for the disappearing controls has already been reserved; so nothing is gained by hiding them.
And almost as bad as peek-a-boo UI is "flat" UI, where most controls aren't demarcated as such. So you're reduced to clicking on plain text labels and other inert-looking components to see if there are hidden goodies associated with them. Absurd.
This is age-related only in that that it's about visual cues, which are the entire point of GUIs to begin with. Physical buttons on a device are inherently discoverable, as were the controls in GUIs for decades. Younger people are used to the incompetence of newer designs, and more tolerant of having to click every pixel on the screen to find things. It's unfortunate.
The bright spot is that there has been some backlash against the "flat" laziness and a return to some visual cues.
That said, I learned the hard way the switches put for MMB are often subpar and fail quite fast. I replaced an Omron (?) switch in a Logitech mouse... twice. Thankfully the current Corsair M55 (pretty basic wired gamer mouse) goes strong.
some form elements like checkboxes, radios, sliders, cannot have their size or color be controlled via css - they need to be outright replaced.
It reminds me of the classic dragon drop parody https://m.youtube.com/watch?v=DCu1G2rxj5c
https://developer.mozilla.org/en-US/docs/Web/CSS/accent-colo...
Defaults are fine, but as a user I'd like a choice to enter my own donation amount.
I've always found the touted toggle box control to be ambiguous compared to the old-fashioned checkmark in a box.
A good middle ground that I've seen across programs, apps and OS-level menus is to add a search box that "skips" the hierarchy navigation when the user knows what they're looking for.
Another interesting idea was "adaptive" menus where the most used options (per user) would be "nearest" / easiest to get to. That one is nice in theory, but in practice it causes things to move around, and makes it harder to develop familiarity with the nested menus.
On the point of familiarity: a solution that appears clever and great, but hasn't taken off (probably because it still feels "unusual") is the circle menu. It makes good use of muscle memory, as all the options are arranged in concentric rings around a start point, with selection on one ring opening the next (more outer) ring with more options.
As far as the author's suggestion -- I guess it aims to keep the top-level menus simple. Where does the complexity go? If it's boxed away in some other dialog, per "category" or "subject", it could work relatively well. A bit more effort from the designers to make it that way, but generally that means it's less effort for the user to interact with.
I use this in the iOS Settings all the time. It truly is a great and important UI element.
Web sites could benefit from adopting this as well. With the rise of Google, it seemed like everybody just kind of gave up on search. "They'll just Google it anyway." But for a lot of Web sites, having a decent and working search tool is really important.
I remember a lot of articles talking about how to handle search on your Web site, with lots of tools and libraries and whatnot, and it just kind of dried up. There's still work happening on Big Time search technologies (Lucene, et. al.), but other than built-in things for platforms like Wordpress, it's kind of stale and quiet.
Or, when searching, keep the hierarchy but only show the items that match and their parent folders. Can give users a sense of "oh, that's over there, so similar stuff is in that same location".
Let's try to be a bit more inclusive...
A collection of ui patterns https://every-layout.dev/
A great resource for css reference https://css-tricks.com/
https://typographyforlawyers.com/ Covers the basics with zero pretense
Kevin Powell on YouTube has great css rutorials https://youtu.be/rg7Fvvl3taU
Jen Simmons on YouTube and https://labs.jensimmons.com/
https://www.refactoringui.com/
Full of great tips and no fluff. Basically gives you a large but fantastic set of rules to live by, cohesive enough that you don't have to deviate from them unless you know what you're doing and have a solid need to. But otherwise it's a great foundation that you can implement in any design system.
Confirmation dialogs take about 2 minutes to implement. Undo, while there’s the odd problem where it’s easy, very often it’s a massive amount of work to implement, like many months.
Likewise, a spinner is a few mins of work, while an ACCURATE progress bar can be much, much more. It’s often really hard to predict how long a given operation will take.
The number of times I've deleted something with no recourse because my dog bumped my hand while holding the phone (or some similar unintentional action) went from frustrating to embarassing to enraging long ago.
This guide is from a UX person, they are looking at things from a usability perspective. Developer effort is not a consideration here, and rightfully so.
UX is a feature.
Might be irrelevant for yet another SaaS, but for consumer-facing products it will be the reason you succeed.
Looks at this decade old presentation from Instagram: https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mob...
This is the mindset that led to $1B valuation (which many believe to be undervalued).
Or along a similar line of thought, restyle your confirmation dialog as an undo dialog, but treat dismissal as confirmation instead of cancel.
https://www.nngroup.com/articles/ten-usability-heuristics/
10 Usability Heuristics for User Interface Design
?
Perhaps. But too often tbat mindset results in dark patterns. That is, the user is "encouraged" to make choices not in their best interest.
This was in the first couple of lines. I checked out immediately.