Although not really part of a UI's "design", performance is often overlooked as well. A poorly performing UI violates every single one of these design rules.
My sony android smart TV looks amazing but the UI is so slow as to be unusable.<p>An unstable UI that is always changing also violates most of these principles. Smart TVs seem to be exceptionally bad in this area too, with the home screen layout and app icons frequently changing positions for no apparent reason.<p>While I'm complaining, my other pet peeve, which unfortunately is only getting worse is: unlabeled icons (often without even tooltips). If I have to google for documentation to know what a button is called, your UI design is bad!
A designer I worked with years ago had a great explanation for why consistency is important.<p>It’s not about a limited colour palette or a careful selection of fonts no one will ever notice. Chasing the specifics makes horrible software. Some people equate less diversity in their UI to more consistency.<p>It’s about letting someone become an expert in your software.<p>Microsoft office was always his example. People pride themselves on “knowing” Microsoft office. They jump between all of the apps because they have a feel for the inertia of “office”. I have the exact same feeling in Vim. I just know how things are expected to be, and new (well made) plugins tend to respect those patterns.<p>Office and (Neo)Vim aren’t exceptional examples of UI, but they are uniquely stable.
The one "rule" I wish it covered is about surfacing/exposing the conceptual model to the user.<p>If I don't understand the conceptual model of the product, I will always be confused, no matter how well-labeled the icons are. For example, imagine a product that has a "New Configuration" command. What is a "Configuration"? Is it like a template that lets me define other objects? Is it a way to rapidly switch between different sets of options? Is it a container, like a folder?<p>The UI must be designed so that the user can infer the conceptual model just from exploring the interface. This is not always easy.
"For example, users should not have to retype an entire name-address form if they enter an invalid zip code but rather should be guided to repair only the faulty part."<p>This is my biggest pet peeve, and I still see it. It should also be true for multi-page forms if you are going back and forth between form pages.<p>"Erroneous actions should leave the interface state unchanged, or the interface should give instructions about restoring the state."<p>Designers seeking to save space on small screens like phones and watches are increasingly relying on icons. However, many icons are unfamiliar or hard to decipher. Sometimes, the only way to figure it out is to click on it. Every such icon should have a way to go back to the original state if a mistake is made.
> <i>gray out menu items that are not appropriate</i><p>Don't do this unless it is obvious why it is grayed out. Commands should be left enabled, then an error message should be displayed when the command is clicked and the command is unavailable, and in this case explain why it is presently unavailable. It is frustrating to the user to figure out why a command is disabled. The only time to not leave commands enabled is if the user is likely to end up wasting a lot of time only to be told at the end that the command is unavailable.<p>Update: Read more about this in this article:
<a href="https://medium.com/@vedranio/james-bond-and-the-design-of-disabled-buttons-6c6bc51ee4cf" rel="nofollow">https://medium.com/@vedranio/james-bond-and-the-design-of-di...</a>
Nielsen's 10 usability heuristics for user interface design gives a good north star:<p>1. Visibility of system status<p>2. Match between system and the real world<p>3. User control and freedom<p>4. Consistency and standards<p>5. Error prevention<p>6. Recognition rather than recall<p>7. Flexibility and efficiency of use<p>8. Aesthetic and minimalist design<p>9. Recognize, diagnose, and recover from errors<p>10. Help and documentation<p><a href="https://www.nngroup.com/articles/ten-usability-heuristics/" rel="nofollow">https://www.nngroup.com/articles/ten-usability-heuristics/</a>
9. Stop popping in something else in place of what I'm just about to select, causing me to select the wrong thing! (I know this maybe violates or can be mitigated by some of the previous rules, but it is the one thing that drives me absolutely bonkers, and I consider it to be a particularly egregious mistake.)
It's missing a critical one, which once seemed obvious: Distinguish between static information and controls.<p>Also, don't HIDE inapplicable controls; GREY THEM OUT. That way people learn<p>1. They exist
2. Where they reside
3. There's some condition to satisfy before they can be used<p>Related: Never, never rely on peek-a-boo UI that hides things unless the user accidentally rolls the cursor over them. I'm trying to get shit done, not explore an Advent calendar.
One golden rule that I learned is that interface elements should not move unexpectedly after the interface has been drawn.
Google is particularly bad for buttons which move between you lifting your thumb and pressing the screen, but they're not alone.
The Golden Rules of obvious Utopia.<p>I think most of us won't disagree with these rules.<p>Yet also most devs will have worked on interfaces that break these rules often. Not because we didn't understand or didn't want, just that the cost was too high at that point.<p>For instance reversibility is very difficult and only possible if the datastructure under the application is build up with this in mind. Or take preventing errors, often it's very difficult and costly to know exactly what errors are, and ever more complicated to provide perfect feedback to a user in their own language.
Not sure that Strive for Consistency should be a golden rule of all interface design. Software maybe. But the reality is the world is inconsistent and humans mental model of tasks are inconsistent. Sometimes its better to design an interface that conforms to the world or the mental model.<p>As a random example: You could have an interface on a car that is almost entirely touch screens. You might see replacing the steering wheel with a touch screen interface. That would be consistent but not a good mapping to people's mental model.
I inherited an app from someone a few years ago at work, and for whatever reason, the developer loved a gray themed UI. Gray buttons. Gray text entry. You never knew what was disabled and just gray for fun. Needless to say that changed...
One thing is that some times some things have to be made harder for end users good or for business rules protection.<p>It is sometimes hard to explain but as an example - delete confirmation - it gets in the way of user because user wants to delete stuff and be done with it. Preventing accidental deletes is more important than any specific user convenience.<p>Keep in mind this is most generic example I came up with on the spot. There are more complex scenarios that are complex for the same reasons. But I find people trying to remove such fences even if they don’t know why they’re there. Claiming simplicity and user convenience as golden rule.
A lot of these rules are taken care of by design systems these days. If you're off developing your own design system or creating custom components the laws of UX are far more useful.<p><a href="https://lawsofux.com/" rel="nofollow">https://lawsofux.com/</a><p>Here are a few that relate to laws:<p>Strive for consistency - Jakobs law<p>Reduce short-term memory load - Millers Law
0. Don't change things just for the sake of justifying your employment as a UI designer.<p>The software I use with the best UI is also the software I use with the oldest UI.
I think it would be important to understand the distinction between two types of applications, I call them "utilities" and "tools" here.<p>Utilities are things that should be designed with the current typical paradigm of simplicity and discoverability to extreme. I should not need to read user manual for my toaster or microwave.<p>Tools then, should be pretty much the opposite. It should be fine and expected to invest some time to learn the efficient and safe usage of the tool. There is no reason to have a intuitive interface on your tool, as long as it is efficient after you did your training. Vim is way better editor than notepad, but I don't think anyone praises it for the intuitively easy to use.<p>And the peeve here is of course that way, <i>way</i> too often these are confused.
These seem common sense, but it's good to see them written down.<p>The one about giving users closure in a sequence of tasks is kind of novel. I like it.
I would like to add: "Live up to expectations" in a sense that there are so many Websites or UIs there, that most users have some sort of expectations, on where to find the menu, how to go back etc. How this and that buttons should behave.
Even though, you might have a great idea, it might just confuse the user, if it is totally different than what the "standard" is.
Related:<p><i>Eight golden rules of user interface design</i> - <a href="https://news.ycombinator.com/item?id=36652355">https://news.ycombinator.com/item?id=36652355</a> - July 2023 (1 comment)<p><i>8 Golden Rules of Interface Design</i> - <a href="https://news.ycombinator.com/item?id=233654">https://news.ycombinator.com/item?id=233654</a> - July 2008 (7 comments)
This one simple information-theoretic principle is an effective guide for user interface design:<p><pre><code> Things that are the same should look the same, and things that are different should look different.
</code></pre>
Your UI conveys information to the user, and the user has finite cognitive capacity for receiving and interpreting that information. So keep the the signal-to-noise ratio high!<p>In my experience, a large portion of the user experience problems in real products are consequences of violating this principle. Construed broadly, this principle implies many design guidelines, e.g.:<p>- If the user changes something, make the change immediately visible<p>- If internal state affects what the user can do, make it visible<p>- Don't use nonstandard interface widgets or icons<p>If you can get this right, you're a lot of the way there.
> Sequences of actions should be organized into groups with a beginning, middle, and end. Informative feedback at the completion of a group of actions gives users the satisfaction of accomplishment, a sense of relief, a signal to drop contingency plans from their minds, and an indicator to prepare for the next group of actions.<p>This is why we built our product around a workflow abstraction. Everything the user can do is some workflow implementation with a # of discrete steps. Our criteria for the scope of a step is guided by a dark and mystical process wherein we all argue about the business for a few hours and then sketch out some prototypes. One trick is to design these with lego-like reuse in mind. Oftentimes, the business will have the exact same view used across a wide range of activities.
These rules were already breaking apart even in 2013. We lost consistency with the advent of CSS-based UI, where design had free reign. This devolved into every site and app doing its own thing for UX. Now we have interfaces with zero visual affordances and you have to basically discover by trial end error what each swipe/long-press/drag/click does.<p>Funny enough, with flash gaining traction in the early 2000s, there was a huge barrage of "mystery meat navigation" which was criticized heavily by the UX community, and it ended up falling out of favor for some time. Yet, we're back to "mystery meat navigation" yet again.
Can an expert explain some context here?? This seems like a less-well-phrased version of Norman’s principles, which were the ones I was taught in HCI class.<p>The author is clearly some sort of textbook author so they know what they’re talking about, but these principles seem like they were written without considering past work. Like “short term memory load” seems like a phrase that would be replaced by “cognitive load” by most authors, even if it’s technically a little bit less specific. Some of the principles are pretty much identical (consistency), while others seem oddly phrased (like “prevent errors” instead of “constraints”).<p>Obviously these principles are great, just seems like there has to be a story about the academic drama here.
The big one missing is “design symmetrically”. The way you go in is also wheee you go out. Where you turn something on is also where it’s turned off. Swipe up so swipe down and on and on.<p>This is so obvious yet so many completely fail to do it.
Some good stuff here, but generally I’d disagree with:<p><i>> Prevent errors: As much as possible, design the interface so that users cannot make serious errors; for example, gray out menu items that are not appropriate and do not allow alphabetic characters in numeric entry fields (Section 3.3.5</i><p>This sounds nice in theory, but in practice too many guardrails like this will just confuse users. “Why can’t I type text here??” It’s often better to allow mistakes but also offer immediate explanatory feedback if something is incorrect.
Looks like a good list, though missing are customization (technically you could tuck customization into "user control", but it's too important for that) and composability (which also helps with 8 memory load - you can remember 'primitive' actions that compose well easier, and that memory would be reinforced with repetition)