12 ms·

Golden Rules of Interface Design (2013)

340 points by luu 3y ago

lxe 3y ago
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. 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.
stevage 3y ago
These seem common sense, but it's good to see them written down. The one about giving users closure in a sequence of tasks is kind of novel. I like it.
georgeecollins 3y ago
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. 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.
- leetrout 3y ago
  Not sure that is the best comparison because it removes the mechanical need for leverage, even with power steering. Now that we have more electric steer by wire... maybe.
- ebiester 3y ago
  Think of it more like this. On page A, you have a button. It looks like a button. When you click it, a dialog opens that confirms you want to perform an action. On page B, you click on the button, and it's a dropdown. You now have lost a sense of the mental model of the application world. It's possible that you may want one of three actions based on your mental model, but the visual should lead you to know "this is different." If you have something that looks like a
- Jtsummers 3y ago
  > that are applicable in most interactive systems. These principles, derived from experience and refined over three decades, require validation and tuning for specific design domains. No list such as this can be complete, but even the original list from 1985, has been well received as a useful guide to students and designers. The author already caveated that they aren't absolutes. That is, they aren't declaring you should follow these rules off a figurative cliff. That would be stupid. The presumption is that people would still exercise judgement.
- ivan_gammel 3y ago
  > 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. Consistency means that users can expect the same behavior from elements with the same specific purpose. When you put steering wheel and infotainment system in the same classification bucket, it is not consistency, it is excessive abstraction.
- projektfu 3y ago
  When I was a kid there were toy RC cars that had two controls, kind of like 1-axis joysticks. The left one pushed upward would cause the car to go forward, possibly with more or less power. The right one pushed to the right allowed turning to the right (but not the left, like Zoolander). A consistent upgrade to this interface would be to allow reversing using the left control in a downward direction and turning left using the right control pushed to the left. An inconsistent application would be to have reverse on the right control pushed to the left and left turning on the left control pushed downward. Inconsistencies across classes are not uncommon and probably understandable given various expectations. For example, the same handlebar steering control behaves very differently on a two-wheeled motorcycle compared to a tricycle.
- p1necone 3y ago
  I feel like that's a bad example because touchscreen controls in cars are just bad in general. Adding a new one makes the car worse because the touchscreen control is bad, not because of anything to do with consistency - all the other touchscreen controls made the car worse too.
- quickthrower2 3y ago
  In this case the consistency is between what you learned to drive in, and the car you use now.
- JusticeJuice 3y ago
  +1, consistency above everything is a very common trap new designers fall into. Humans are messy.
bbor 3y ago
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. 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”). Obviously these principles are great, just seems like there has to be a story about the academic drama here.
- ivan_gammel 3y ago
  I was not familiar with this author, but they mentioned that these principles were defined around 1985 — before Nielsen‘s heuristics. A lot of things were different 40 years ago, so language may indeed seem a bit archaic.
  - bbor 3y ago
    Ah okay saw the textbook publish date and stupidly assumed that was the overall date. Thanks, makes sense! In that case this is a fascinating look into the past and a testament to how solid these principle are, since they’ve endured and popped up in similar lists.
- jonstewart 3y ago
  Ben Schneiderman is an ACM Fellow and CS professor emeritus of the University of Maryland-College Park. These 8 principles are from his 1986 book. He’s done a lot of work in infovis and HCI and is the inventor of the treemap visualization. https://en.m.wikipedia.org/wiki/Ben_Shneiderman https://en.m.wikipedia.org/wiki/Ben_Shneiderman
- sib 3y ago
  No drama, just history! Ben Shneiderman's been doing "UX" research since before it was a defined term (previously called "Human-Computer Interaction" or even "Man-Machine Interfaces"). He was my thesis advisor in the early 1990's and first published these guidelines in the 1980's.
graypegg 3y ago
A designer I worked with years ago had a great explanation for why consistency is important. 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. It’s about letting someone become an expert in your software. 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. Office and (Neo)Vim aren’t exceptional examples of UI, but they are uniquely stable.
- munificent 3y ago
  I'm a programming language designer, so I think about this stuff all day every day. I believe you're right that expertise has something to do with it, but I don't think your comment quite connects why consistency leads to expertise. Consistency is about taking what users already know about a system and compounding that expertise across other parts of the system. When a system is consistent, once I spend the effort to learn X and Y, then I also know Z and W because they'll behave the same way. In an inconsistent system, I can't extract as much value from my existing learning investment.
  - hypercube33 3y ago
    I fully agree. it's also how the user takes what they know and making it work for them. Windows 95 had years of user testing behind it. They'd sit people down who were used to DOS or Windows 3.11 and give them tasks and see where they struggled or where it worked and iterated on it and the talks by the ux teams really stuck with me. every color and design choice was important even the awful but good real background wallpaper colors
- Angostura 3y ago
  It's possibly one of the reasons why so many people were bent out of shape when MS introduced the adaptive ribbon shenanigans that tried to 'help' by only showing the most likely options. Really knocked my ability to find stuff
infotainment 3y ago
Some good stuff here, but generally I’d disagree with: > 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 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.
- ivan_gammel 3y ago
  > It’s often better to allow mistakes but also offer immediate explanatory feedback if something is incorrect. That is just another form of error prevention: in the end erroneous data will not be submitted.
- Jtsummers 3y ago
  > It's often better to allow mistakes but also offer immediate explanatory feedback if something is incorrect. Which is what the rule actually describes. > If users make an error, the interface should offer simple, constructive, and specific instructions for recovery. 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. Erroneous actions should leave the interface state unchanged, or the interface should give instructions about restoring the state. I'm very confused by some of the attempts at "gotchas" in this discussion that are just restating what the list (and context paragraphs) already say as if it didn't say it.
- deleted 3y ago
  [deleted]
- naasking 3y ago
  Add a tooltip on disabled inputs.
  - DonHopkins 3y ago
    A thousand times this! All disabled menu items and inputs should always have a tooltip or other means of explaining why they are disabled and what to do to enable them, with no exceptions.
joshuaheard 3y ago
"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." 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. "Erroneous actions should leave the interface state unchanged, or the interface should give instructions about restoring the state." 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.
- ShadowBanThis01 3y ago
  Annoying as shit. If I'm trying to log into something with an E-mail address (already a fail, but that's another topic) and password, and I click "forgot password," don't take me to a form where I have to re-enter the goddamned E-mail address I JUST ENTERED.
  - nox101 3y ago
    Or every customer service phone line where the automated system asks for your info (account# or phone#) and then the customer service rep asks again >:(
    - rrr_oh_man 3y ago
      That is only to keep you busy and engaged
      - esafak 3y ago
        I just engaged the close button.
    - bluGill 3y ago
      In some cases this is a verification and reques, for more information. when doctors reask what the nurse just asked. most of the time it isn't. the doctor already knows what you told the nurse. (where the doctor doesn't that is bad)
Stenzel 3y ago
Title should say screen design, for general UI these are quite useless, especially if your UI is physical.
- madeofpalk 3y ago
  I think these guidelines are pretty translatable for any kind of user interface, including physical. Machines should have consistent physical controls that make it readily apparent whether it's a button to press or a knob to turn. They should prevent errors like an exposed blade cutting my hand off.
breadwinner 3y ago
> gray out menu items that are not appropriate 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. Update: Read more about this in this article: https://medium.com/@vedranio/james-bond-and-the-design-of-disabled-buttons-6c6bc51ee4cf https://medium.com/@vedranio/james-bond-and-the-design-of-di...
- arcanemachiner 3y ago
  Sure, but there should be some kind of consistent visual affordance that conveys that the action is disabled, before the user clicks on it.
  - breadwinner 3y ago
    If the user is likely to keep clicking the button only to be told that the feature is currently unavailable, then some kind of status indicator would be helpful. In my experience, this situation is very uncommon.
- euroderf 3y ago
  > 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. An exception to this: premium (for-pay) features. There is a certain To-Do app that does this. Premium commands are visually indistinguishable from freemium commands, so they get clicked a lot and they interrupt the entire experience with nag dialogs. A serious UI error IMO.
  - carlosjobim 3y ago
    It's not an error, it's deliberate.
bithive123 3y ago
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. 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. 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!
- 9dev 3y ago
  > the home screen layout and app icons frequently changing positions for no apparent reason. Spotify does this, too. Every morning I listen to the same two news podcasts. And every bloody morning the suggestions in the app shuffle around for no apparent reason. To add insult to injury though, when the app starts, it still shows the layout from yesterday, hangs for a second while it loads, then reorders stuff - and every time I’ll tap on something that moves somewhere else in that exact moment. It’s extremely frustrating.
- godzillabrennus 3y ago
  Ever since Snapchat exploded in popularity I’ve decided bad UI is a gen z feature. They flock to difficult to use interfaces that become an insider feature for young folks to keep their parents out.
  - munificent 3y ago
    Or more likely explanation for this phenomenon is that for Gen Z people: 1. Snapchat has relatively more people that they want to interact with. 2. The cost of learning a difficult UI is relatively low since they have more spare mental bandwidth since they aren't working full time, raising kids, etc. So for a younger person, it's worth it to fight a bad UI to get to the social network, but for an older person the trade-off may not be worth it.
  - 3y ago
kazinator 3y ago
Where are the apps shipped by umn.edu?
- subroutine 3y ago
  Universities teach students about a lot of things they don't actually create themselves.
- deleted 3y ago
  [deleted]
- DonHopkins 3y ago
  What does the University of Minnesota Twin Cities have to do with this discussion? And why do you care which apps a university research lab shipped? ;) If you want to know about what contributions Ben Shneiderman and his University of Maryland Human Computer Interaction Lab have made, you can read my other post: https://news.ycombinator.com/item?id=38920423 https://news.ycombinator.com/item?id=38920423 Or wikipedia: https://en.wikipedia.org/wiki/Ben_Shneiderman https://en.wikipedia.org/wiki/Ben_Shneiderman https://en.wikipedia.org/wiki/University_of_Maryland_Human%E2%80%93Computer_Interaction_Lab https://en.wikipedia.org/wiki/University_of_Maryland_Human%E... Or Ben Shneiderman's home page: https://www.cs.umd.edu/users/ben/ https://www.cs.umd.edu/users/ben/ One app that the UMD Human Computer Interaction Lab shipped in several versions was HyperTIES, which was used to implement “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference, which influenced Tim Berners-Lee to make hypertext links blue: The Interactive Encyclopedia System: https://en.wikipedia.org/wiki/The_Interactive_Encyclopedia_System https://en.wikipedia.org/wiki/The_Interactive_Encyclopedia_S... HyperTIES Discussions from Hacker News: https://donhopkins.medium.com/hyperties-discussions-from-hacker-news-937d156f0330 https://donhopkins.medium.com/hyperties-discussions-from-hac... >Don Hopkins sent the following message at 10:07 AM, AUG 28, 2021 >Why are hyperlinks blue? >Hello Elise. Here is some information about why hyperlinks are blue, from Ben Shneiderman’s answer to a question I asked him about the origin of the term “hyperlink”. I think your belief that HyperTIES was not the first instance of blue hyperlinks because it used cyan links is splitting hairs, and a “No Blue Scotsman” argument, especially since Tim Berners-Lee told Ben Sheniderman at the time that he was influenced by Ben’s design as he saw it in the HyperTIES-based “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference at the University of North Carolina. Ben describes the color as “light blue”, which he chose from the limited palette available on PCs at the time, based on controlled experiments he and his students performed comparing user comprehension and recollection. https://news.ycombinator.com/item?id=28317104 https://news.ycombinator.com/item?id=28317104 HI Don (and Jack Gilmore), Thanks for including me in this conversation. I do not have a claim for the term “hyperlinks” and don’t know when it came into use. My claim is for the visual interface for showing highlighted selectable links embedded in paragraphs. This is what we called embedded menu items in that I think is an influential paper on the topic, which was peer-reviewed and published in the CACM in April 1986. https://dl.acm.org/doi/10.1145/5684.5687 https://dl.acm.org/doi/10.1145/5684.5687 http://www.cs.umd.edu/~ben/papers/Koved1986Embedded.pdf http://www.cs.umd.edu/~ben/papers/Koved1986Embedded.pdf While Engelbart had shown a list that could be selected by pointing and clicking in 1968, I claim the idea of embedded highlighted selectable text in paragraphs. This was implemented by grad student Daniel Ostroff and described in: Ewing J, Mehrabanzad S, Sheck S, Ostroff D and Shneiderman B (1986), "An experimental comparison of a mouse and arrow-jump keys for an interactive encyclopedia", International Journal of Man-Machine Studies, Jan., 1986, Vol 24, pp. 29-45. [Abstract] [BibTeX] [DOI] Ostroff D and Shneiderman B (1988), "Selection devices for users of an electronic encyclopedia: an empirical comparison of four possibilities", Information Processing and Management, Nov., 1988, Vol 24(6), pp. 665-680. [Abstract] [BibTeX] [DOI] I think the 1988 paper was the earlier study, but the publication took a while. My students conducted more than a dozen experiments (unpublished) on different ways of highlighting and selection using current screens, e.g. green screens only permitted, bold, underscore, blinking, and I think italic(???). When we had a color screen we tried different color highlighted links. While red made the links easier to spot, user comprehension and recollection of the content declined. We chose the light blue, which Tim adopted. His systems with embedded menus (or hot spots), where a significant user interface improvement over early systems such as Gopher. But Tim told me at the time that he was influenced by our design as he saw it in the Hypertext on Hypertext project that we used Hyperties to build for the July 1988 CACM that held the articles from the July 1987 Hypertext conference at the University of North Carolina. The ACM sold 4000 copies of our Hypertext on Hypertext disks. Our history is here: https://www.cs.umd.edu/hcil/hyperties/ https://www.cs.umd.edu/hcil/hyperties/ and the video is very helpful in showing the design we used, which is what I think Tim built on for his WWW prototypes. https://www.youtube.com/watch?v=29b4O2xxeqg https://www.youtube.com/watch?v=29b4O2xxeqg So in summary, I don’t know who coined hypertext, but I do think our work visual and interaction design was influential. Our Hyperties system was picked up by Cognetics Corporation (around 1987) who made a modestly successful commercial run with it, doing dozens of corporate projects, most notably the Hewlett-Packard user manual for their Laserjet 4 was distributed as a Hyperties disk. Hyperties was the name we shifted to after we got a stop and desist order from a lawyer because our TIES (The Interactive Encyclopedia System) conflicted with an existing product. By then “hyper” was a growing term. Let me know if this helps, and what other questions you have…. Ben ---- HCIL also shipped various treemapping applications: https://en.wikipedia.org/wiki/Treemapping https://en.wikipedia.org/wiki/Treemapping >Area-based visualizations have existed for decades. For example, mosaic plots (also known as Marimekko diagrams) use rectangular tilings to show joint distributions (i.e., most commonly they are essentially stacked column plots where the columns are of different widths). The main distinguishing feature of a treemap, however, is the recursive construction that allows it to be extended to hierarchical data with any number of levels. This idea was invented by professor Ben Shneiderman at the University of Maryland Human – Computer Interaction Lab in the early 1990s. [21][22] Shneiderman and his collaborators then deepened the idea by introducing a variety of interactive techniques for filtering and adjusting treemaps. https://www.cs.umd.edu/~ben/papers/Johnson1991Tree.pdf https://www.cs.umd.edu/~ben/papers/Johnson1991Tree.pdf https://treemapart.wordpress.com/ https://treemapart.wordpress.com/
ShadowBanThis01 3y ago
It's missing a critical one, which once seemed obvious: Distinguish between static information and controls. Also, don't HIDE inapplicable controls; GREY THEM OUT. That way people learn 1. They exist 2. Where they reside 3. There's some condition to satisfy before they can be used 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.
23B1 3y ago
9. The actual golden rule: don't create UX that you yourself would find hostile.
dang 3y ago
Related: Eight golden rules of user interface design - https://news.ycombinator.com/item?id=36652355 https://news.ycombinator.com/item?id=36652355 - July 2023 (1 comment) 8 Golden Rules of Interface Design - https://news.ycombinator.com/item?id=233654 https://news.ycombinator.com/item?id=233654 - July 2008 (7 comments)
wouldbecouldbe 3y ago
The Golden Rules of obvious Utopia. I think most of us won't disagree with these rules. 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. 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.
bob1029 3y ago
> 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. 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.
- rrr_oh_man 3y ago
  Care to share the product?
dmalik 3y ago
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. https://lawsofux.com/ https://lawsofux.com/ Here are a few that relate to laws: Strive for consistency - Jakobs law Reduce short-term memory load - Millers Law
bluSCALE4 3y ago
I think undo and history is vastly underrated. Lots of systems have activity logs but not many associate anything actionable to them.
causality0 3y ago
0. Don't change things just for the sake of justifying your employment as a UI designer. The software I use with the best UI is also the software I use with the oldest UI.
pugworthy 3y ago
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...
- hannofcart 3y ago
  Am certainly not the dev you inherited the project from but I used to prefer an all gray palette too on projects that didn't afford me any design help. This was because I'm colour blind (red green) and find it near impossible to keep track of what signal I may be sending using one of the other colours while I am likely oblivious to that colour even being used. So I used to use an all gray palette as a placeholder till real designers who could properly see colours and understood significance of each could come in and "colour in" the UI.
elf25 3y ago
[dead]
GMoromisato 3y ago
The one "rule" I wish it covered is about surfacing/exposing the conceptual model to the user. 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? The UI must be designed so that the user can infer the conceptual model just from exploring the interface. This is not always easy.
- Ygg2 3y ago
  Point of good interface is to hide implementation detail while guiding you towards your goal.
  - nirimda 3y ago
    To be clear - the conceptual space the software is built around isn't an implementation detail. It's the way you reach your goal; it necessarily imposes a burden on the user. A good conceptual space presses less heavily against the user, but you can't obscure the notion that there are containers in a file system but not a relational database.
    - moring 3y ago
      There is always the discussion whether the UI should "hide the implementation details" (make the internal model, which differs from the conceptual model, invisible -- resulting in hard-to-understand behavior) or "make the implementation details visible" (change the conceptual model to be equal to the implementation model, and force the user to adapt to that). But the one option that is rarely used but yields the (IMHO) best results is: design the conceptual model, then build/change the implementation model to be equal to it. One example for this strategy that is forever stuck in my head is macOS application folders. The conceptual model is that an application can be moved around like a file, and applications be organized in folders like files. But you also want to run an application by double-clicking it. Instead of what Windows (and then Linux) did with links, menus, installing applications and centrally registering them etc., the implementation was changed to be like the conceptual model. A whole class of errors from inconsistencies just vanished.
oivviopolite 3y ago
1. Set your page margin to 0px.
ozim 3y ago
One thing is that some times some things have to be made harder for end users good or for business rules protection. 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. 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.
- Kranar 3y ago
  I really detest that principle. For the design of my software I make almost every action reversible and avoid at all costs confirmation dialogs or anything that makes it seem like the user could be at fault for something if they choose incorrectly. I also work on financial trading software so I do need to think a great deal about user error and the best principle I have found is to never create a situation where a confirmation is needed. Among new users it creates anxiety and indecisiveness, and among experienced users they just ignore it and it's noise to them. All confirmation dialogs do is make the developer/designer punt responsibility off to the user for what is generally a bad design decision.
tsunamifury 3y ago
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. This is so obvious yet so many completely fail to do it.
eviks 3y ago
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)
guardian5x 3y ago
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.
- whycome 3y ago
  Everyone wants to create new expectations and hope they become the new standard
beefield 3y ago
I think it would be important to understand the distinction between two types of applications, I call them "utilities" and "tools" here. 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. 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. And the peeve here is of course that way, way too often these are confused.
stronglikedan 3y ago
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.)
- tech2 3y ago
  Jira and the Unassigned/Automatic selection when trying to change a story assignment, I'm looking at YOU in particular!
andsoitis 3y ago
Nielsen's 10 usability heuristics for user interface design gives a good north star: 1. Visibility of system status 2. Match between system and the real world 3. User control and freedom 4. Consistency and standards 5. Error prevention 6. Recognition rather than recall 7. Flexibility and efficiency of use 8. Aesthetic and minimalist design 9. Recognize, diagnose, and recover from errors 10. Help and documentation https://www.nngroup.com/articles/ten-usability-heuristics/ https://www.nngroup.com/articles/ten-usability-heuristics/
- lcuff 3y ago
  The contrast between this Nielsen-Norman (NN) page and the OP page is marked. The NN page is much easier to absorb the information. More succinct, way better page layout. Both articles have information/direction worth heeding, but there is irony in the fact that the OP page adopts same-text size and paragraphing conventions of yesteryear that the NN page does away with. It's also frustrating that Hacker News doesn't pay attention to some of the information. In creating an edit to an existing post, the feedback after clicking on the 'update' button is not as clear as it should be. (It's a screen redraw, I guess).
  - btbuildem 3y ago
    Are we looking at the same thing? The NN pages are cluttered with navigation to other areas, links for "more this and that", related courses, etc. Everything is in six different font sizes, there are variously-coloured illustrations that pull at strenuous off-topic metaphors... it's a mess. In contrast, the OP page is clear, simple, sticks to the topic at hand. Easy to read typography, eight paragraphs for the eight rules.
nyreed 3y ago
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.
- jetrink 3y ago
  I wish this would be addressed at the OS level. If a target popped into existence less than ~0.25 seconds before it was touched, a touch event shouldn't be generated. Humans reaction times aren't fast enough to hit a button that quickly anyway.
  - murermader 3y ago
    Great idea. Should also take into account misclicks directly after layouts shifts in some websites.
  - yshklarov 3y ago
    One problem with this: People often learn to touch multiple targets quickly in sequence, because one touch event predictably pops up the target for the next event.
zestyping 3y ago
This one simple information-theoretic principle is an effective guide for user interface design: Things that are the same should look the same, and things that are different should look different. 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! 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.: - If the user changes something, make the change immediately visible - If internal state affects what the user can do, make it visible - Don't use nonstandard interface widgets or icons If you can get this right, you're a lot of the way there.
zubairq 3y ago
I always think of the one golden rule of interface design to be: Don’t make me think!

340 points by luu 3y ago

lxe 3y ago

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. 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.

stevage 3y ago

These seem common sense, but it's good to see them written down. The one about giving users closure in a sequence of tasks is kind of novel. I like it.

georgeecollins 3y ago

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. 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.

leetrout 3y ago
Not sure that is the best comparison because it removes the mechanical need for leverage, even with power steering. Now that we have more electric steer by wire... maybe.
ebiester 3y ago
Think of it more like this. On page A, you have a button. It looks like a button. When you click it, a dialog opens that confirms you want to perform an action. On page B, you click on the button, and it's a dropdown. You now have lost a sense of the mental model of the application world. It's possible that you may want one of three actions based on your mental model, but the visual should lead you to know "this is different." If you have something that looks like a
Jtsummers 3y ago
> that are applicable in most interactive systems. These principles, derived from experience and refined over three decades, require validation and tuning for specific design domains. No list such as this can be complete, but even the original list from 1985, has been well received as a useful guide to students and designers. The author already caveated that they aren't absolutes. That is, they aren't declaring you should follow these rules off a figurative cliff. That would be stupid. The presumption is that people would still exercise judgement.
ivan_gammel 3y ago
> 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. Consistency means that users can expect the same behavior from elements with the same specific purpose. When you put steering wheel and infotainment system in the same classification bucket, it is not consistency, it is excessive abstraction.
projektfu 3y ago
When I was a kid there were toy RC cars that had two controls, kind of like 1-axis joysticks. The left one pushed upward would cause the car to go forward, possibly with more or less power. The right one pushed to the right allowed turning to the right (but not the left, like Zoolander). A consistent upgrade to this interface would be to allow reversing using the left control in a downward direction and turning left using the right control pushed to the left. An inconsistent application would be to have reverse on the right control pushed to the left and left turning on the left control pushed downward. Inconsistencies across classes are not uncommon and probably understandable given various expectations. For example, the same handlebar steering control behaves very differently on a two-wheeled motorcycle compared to a tricycle.
p1necone 3y ago
I feel like that's a bad example because touchscreen controls in cars are just bad in general. Adding a new one makes the car worse because the touchscreen control is bad, not because of anything to do with consistency - all the other touchscreen controls made the car worse too.
quickthrower2 3y ago
In this case the consistency is between what you learned to drive in, and the car you use now.
JusticeJuice 3y ago
+1, consistency above everything is a very common trap new designers fall into. Humans are messy.

bbor 3y ago

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. 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”). Obviously these principles are great, just seems like there has to be a story about the academic drama here.

ivan_gammel 3y ago
I was not familiar with this author, but they mentioned that these principles were defined around 1985 — before Nielsen‘s heuristics. A lot of things were different 40 years ago, so language may indeed seem a bit archaic.
- bbor 3y ago
  Ah okay saw the textbook publish date and stupidly assumed that was the overall date. Thanks, makes sense! In that case this is a fascinating look into the past and a testament to how solid these principle are, since they’ve endured and popped up in similar lists.
jonstewart 3y ago
Ben Schneiderman is an ACM Fellow and CS professor emeritus of the University of Maryland-College Park. These 8 principles are from his 1986 book. He’s done a lot of work in infovis and HCI and is the inventor of the treemap visualization. https://en.m.wikipedia.org/wiki/Ben_Shneiderman https://en.m.wikipedia.org/wiki/Ben_Shneiderman
sib 3y ago
No drama, just history! Ben Shneiderman's been doing "UX" research since before it was a defined term (previously called "Human-Computer Interaction" or even "Man-Machine Interfaces"). He was my thesis advisor in the early 1990's and first published these guidelines in the 1980's.

graypegg 3y ago

A designer I worked with years ago had a great explanation for why consistency is important. 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. It’s about letting someone become an expert in your software. 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. Office and (Neo)Vim aren’t exceptional examples of UI, but they are uniquely stable.

munificent 3y ago
I'm a programming language designer, so I think about this stuff all day every day. I believe you're right that expertise has something to do with it, but I don't think your comment quite connects why consistency leads to expertise. Consistency is about taking what users already know about a system and compounding that expertise across other parts of the system. When a system is consistent, once I spend the effort to learn X and Y, then I also know Z and W because they'll behave the same way. In an inconsistent system, I can't extract as much value from my existing learning investment.
- hypercube33 3y ago
  I fully agree. it's also how the user takes what they know and making it work for them. Windows 95 had years of user testing behind it. They'd sit people down who were used to DOS or Windows 3.11 and give them tasks and see where they struggled or where it worked and iterated on it and the talks by the ux teams really stuck with me. every color and design choice was important even the awful but good real background wallpaper colors
Angostura 3y ago
It's possibly one of the reasons why so many people were bent out of shape when MS introduced the adaptive ribbon shenanigans that tried to 'help' by only showing the most likely options. Really knocked my ability to find stuff

infotainment 3y ago

Some good stuff here, but generally I’d disagree with: > 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 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.

ivan_gammel 3y ago
> It’s often better to allow mistakes but also offer immediate explanatory feedback if something is incorrect. That is just another form of error prevention: in the end erroneous data will not be submitted.
Jtsummers 3y ago
> It's often better to allow mistakes but also offer immediate explanatory feedback if something is incorrect. Which is what the rule actually describes. > If users make an error, the interface should offer simple, constructive, and specific instructions for recovery. 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. Erroneous actions should leave the interface state unchanged, or the interface should give instructions about restoring the state. I'm very confused by some of the attempts at "gotchas" in this discussion that are just restating what the list (and context paragraphs) already say as if it didn't say it.
deleted 3y ago
[deleted]
naasking 3y ago
Add a tooltip on disabled inputs.
- DonHopkins 3y ago
  A thousand times this! All disabled menu items and inputs should always have a tooltip or other means of explaining why they are disabled and what to do to enable them, with no exceptions.

joshuaheard 3y ago

"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." 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. "Erroneous actions should leave the interface state unchanged, or the interface should give instructions about restoring the state." 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.

ShadowBanThis01 3y ago
Annoying as shit. If I'm trying to log into something with an E-mail address (already a fail, but that's another topic) and password, and I click "forgot password," don't take me to a form where I have to re-enter the goddamned E-mail address I JUST ENTERED.
- nox101 3y ago
  Or every customer service phone line where the automated system asks for your info (account# or phone#) and then the customer service rep asks again >:(
  - rrr_oh_man 3y ago
    That is only to keep you busy and engaged
    - esafak 3y ago
      I just engaged the close button.
  - bluGill 3y ago
    In some cases this is a verification and reques, for more information. when doctors reask what the nurse just asked. most of the time it isn't. the doctor already knows what you told the nurse. (where the doctor doesn't that is bad)

Stenzel 3y ago

Title should say screen design, for general UI these are quite useless, especially if your UI is physical.

madeofpalk 3y ago
I think these guidelines are pretty translatable for any kind of user interface, including physical. Machines should have consistent physical controls that make it readily apparent whether it's a button to press or a knob to turn. They should prevent errors like an exposed blade cutting my hand off.

breadwinner 3y ago

> gray out menu items that are not appropriate 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. Update: Read more about this in this article: https://medium.com/@vedranio/james-bond-and-the-design-of-disabled-buttons-6c6bc51ee4cf https://medium.com/@vedranio/james-bond-and-the-design-of-di...

arcanemachiner 3y ago
Sure, but there should be some kind of consistent visual affordance that conveys that the action is disabled, before the user clicks on it.
- breadwinner 3y ago
  If the user is likely to keep clicking the button only to be told that the feature is currently unavailable, then some kind of status indicator would be helpful. In my experience, this situation is very uncommon.
euroderf 3y ago
> 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. An exception to this: premium (for-pay) features. There is a certain To-Do app that does this. Premium commands are visually indistinguishable from freemium commands, so they get clicked a lot and they interrupt the entire experience with nag dialogs. A serious UI error IMO.
- carlosjobim 3y ago
  It's not an error, it's deliberate.

bithive123 3y ago

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. 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. 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!

9dev 3y ago
> the home screen layout and app icons frequently changing positions for no apparent reason. Spotify does this, too. Every morning I listen to the same two news podcasts. And every bloody morning the suggestions in the app shuffle around for no apparent reason. To add insult to injury though, when the app starts, it still shows the layout from yesterday, hangs for a second while it loads, then reorders stuff - and every time I’ll tap on something that moves somewhere else in that exact moment. It’s extremely frustrating.
godzillabrennus 3y ago
Ever since Snapchat exploded in popularity I’ve decided bad UI is a gen z feature. They flock to difficult to use interfaces that become an insider feature for young folks to keep their parents out.
- munificent 3y ago
  Or more likely explanation for this phenomenon is that for Gen Z people: 1. Snapchat has relatively more people that they want to interact with. 2. The cost of learning a difficult UI is relatively low since they have more spare mental bandwidth since they aren't working full time, raising kids, etc. So for a younger person, it's worth it to fight a bad UI to get to the social network, but for an older person the trade-off may not be worth it.
- 3y ago

kazinator 3y ago

Where are the apps shipped by umn.edu?

subroutine 3y ago
Universities teach students about a lot of things they don't actually create themselves.
deleted 3y ago
[deleted]
DonHopkins 3y ago
What does the University of Minnesota Twin Cities have to do with this discussion? And why do you care which apps a university research lab shipped? ;) If you want to know about what contributions Ben Shneiderman and his University of Maryland Human Computer Interaction Lab have made, you can read my other post: https://news.ycombinator.com/item?id=38920423 https://news.ycombinator.com/item?id=38920423 Or wikipedia: https://en.wikipedia.org/wiki/Ben_Shneiderman https://en.wikipedia.org/wiki/Ben_Shneiderman https://en.wikipedia.org/wiki/University_of_Maryland_Human%E2%80%93Computer_Interaction_Lab https://en.wikipedia.org/wiki/University_of_Maryland_Human%E... Or Ben Shneiderman's home page: https://www.cs.umd.edu/users/ben/ https://www.cs.umd.edu/users/ben/ One app that the UMD Human Computer Interaction Lab shipped in several versions was HyperTIES, which was used to implement “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference, which influenced Tim Berners-Lee to make hypertext links blue: The Interactive Encyclopedia System: https://en.wikipedia.org/wiki/The_Interactive_Encyclopedia_System https://en.wikipedia.org/wiki/The_Interactive_Encyclopedia_S... HyperTIES Discussions from Hacker News: https://donhopkins.medium.com/hyperties-discussions-from-hacker-news-937d156f0330 https://donhopkins.medium.com/hyperties-discussions-from-hac... >Don Hopkins sent the following message at 10:07 AM, AUG 28, 2021 >Why are hyperlinks blue? >Hello Elise. Here is some information about why hyperlinks are blue, from Ben Shneiderman’s answer to a question I asked him about the origin of the term “hyperlink”. I think your belief that HyperTIES was not the first instance of blue hyperlinks because it used cyan links is splitting hairs, and a “No Blue Scotsman” argument, especially since Tim Berners-Lee told Ben Sheniderman at the time that he was influenced by Ben’s design as he saw it in the HyperTIES-based “Hypertext on Hypertext” that ACM distributed with the articles from the July 1987 Hypertext conference at the University of North Carolina. Ben describes the color as “light blue”, which he chose from the limited palette available on PCs at the time, based on controlled experiments he and his students performed comparing user comprehension and recollection. https://news.ycombinator.com/item?id=28317104 https://news.ycombinator.com/item?id=28317104 HI Don (and Jack Gilmore), Thanks for including me in this conversation. I do not have a claim for the term “hyperlinks” and don’t know when it came into use. My claim is for the visual interface for showing highlighted selectable links embedded in paragraphs. This is what we called embedded menu items in that I think is an influential paper on the topic, which was peer-reviewed and published in the CACM in April 1986. https://dl.acm.org/doi/10.1145/5684.5687 https://dl.acm.org/doi/10.1145/5684.5687 http://www.cs.umd.edu/~ben/papers/Koved1986Embedded.pdf http://www.cs.umd.edu/~ben/papers/Koved1986Embedded.pdf While Engelbart had shown a list that could be selected by pointing and clicking in 1968, I claim the idea of embedded highlighted selectable text in paragraphs. This was implemented by grad student Daniel Ostroff and described in: Ewing J, Mehrabanzad S, Sheck S, Ostroff D and Shneiderman B (1986), "An experimental comparison of a mouse and arrow-jump keys for an interactive encyclopedia", International Journal of Man-Machine Studies, Jan., 1986, Vol 24, pp. 29-45. [Abstract] [BibTeX] [DOI] Ostroff D and Shneiderman B (1988), "Selection devices for users of an electronic encyclopedia: an empirical comparison of four possibilities", Information Processing and Management, Nov., 1988, Vol 24(6), pp. 665-680. [Abstract] [BibTeX] [DOI] I think the 1988 paper was the earlier study, but the publication took a while. My students conducted more than a dozen experiments (unpublished) on different ways of highlighting and selection using current screens, e.g. green screens only permitted, bold, underscore, blinking, and I think italic(???). When we had a color screen we tried different color highlighted links. While red made the links easier to spot, user comprehension and recollection of the content declined. We chose the light blue, which Tim adopted. His systems with embedded menus (or hot spots), where a significant user interface improvement over early systems such as Gopher. But Tim told me at the time that he was influenced by our design as he saw it in the Hypertext on Hypertext project that we used Hyperties to build for the July 1988 CACM that held the articles from the July 1987 Hypertext conference at the University of North Carolina. The ACM sold 4000 copies of our Hypertext on Hypertext disks. Our history is here: https://www.cs.umd.edu/hcil/hyperties/ https://www.cs.umd.edu/hcil/hyperties/ and the video is very helpful in showing the design we used, which is what I think Tim built on for his WWW prototypes. https://www.youtube.com/watch?v=29b4O2xxeqg https://www.youtube.com/watch?v=29b4O2xxeqg So in summary, I don’t know who coined hypertext, but I do think our work visual and interaction design was influential. Our Hyperties system was picked up by Cognetics Corporation (around 1987) who made a modestly successful commercial run with it, doing dozens of corporate projects, most notably the Hewlett-Packard user manual for their Laserjet 4 was distributed as a Hyperties disk. Hyperties was the name we shifted to after we got a stop and desist order from a lawyer because our TIES (The Interactive Encyclopedia System) conflicted with an existing product. By then “hyper” was a growing term. Let me know if this helps, and what other questions you have…. Ben ---- HCIL also shipped various treemapping applications: https://en.wikipedia.org/wiki/Treemapping https://en.wikipedia.org/wiki/Treemapping >Area-based visualizations have existed for decades. For example, mosaic plots (also known as Marimekko diagrams) use rectangular tilings to show joint distributions (i.e., most commonly they are essentially stacked column plots where the columns are of different widths). The main distinguishing feature of a treemap, however, is the recursive construction that allows it to be extended to hierarchical data with any number of levels. This idea was invented by professor Ben Shneiderman at the University of Maryland Human – Computer Interaction Lab in the early 1990s. [21][22] Shneiderman and his collaborators then deepened the idea by introducing a variety of interactive techniques for filtering and adjusting treemaps. https://www.cs.umd.edu/~ben/papers/Johnson1991Tree.pdf https://www.cs.umd.edu/~ben/papers/Johnson1991Tree.pdf https://treemapart.wordpress.com/ https://treemapart.wordpress.com/

ShadowBanThis01 3y ago

It's missing a critical one, which once seemed obvious: Distinguish between static information and controls. Also, don't HIDE inapplicable controls; GREY THEM OUT. That way people learn 1. They exist 2. Where they reside 3. There's some condition to satisfy before they can be used 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.

23B1 3y ago

9. The actual golden rule: don't create UX that you yourself would find hostile.

dang 3y ago

Related: Eight golden rules of user interface design - https://news.ycombinator.com/item?id=36652355 https://news.ycombinator.com/item?id=36652355 - July 2023 (1 comment) 8 Golden Rules of Interface Design - https://news.ycombinator.com/item?id=233654 https://news.ycombinator.com/item?id=233654 - July 2008 (7 comments)

wouldbecouldbe 3y ago

The Golden Rules of obvious Utopia. I think most of us won't disagree with these rules. 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. 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.

bob1029 3y ago

> 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. 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.

rrr_oh_man 3y ago
Care to share the product?

dmalik 3y ago

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. https://lawsofux.com/ https://lawsofux.com/ Here are a few that relate to laws: Strive for consistency - Jakobs law Reduce short-term memory load - Millers Law

bluSCALE4 3y ago

I think undo and history is vastly underrated. Lots of systems have activity logs but not many associate anything actionable to them.

causality0 3y ago

0. Don't change things just for the sake of justifying your employment as a UI designer. The software I use with the best UI is also the software I use with the oldest UI.

pugworthy 3y ago

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...

hannofcart 3y ago
Am certainly not the dev you inherited the project from but I used to prefer an all gray palette too on projects that didn't afford me any design help. This was because I'm colour blind (red green) and find it near impossible to keep track of what signal I may be sending using one of the other colours while I am likely oblivious to that colour even being used. So I used to use an all gray palette as a placeholder till real designers who could properly see colours and understood significance of each could come in and "colour in" the UI.

elf25 3y ago

[dead]

GMoromisato 3y ago

The one "rule" I wish it covered is about surfacing/exposing the conceptual model to the user. 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? The UI must be designed so that the user can infer the conceptual model just from exploring the interface. This is not always easy.

Ygg2 3y ago
Point of good interface is to hide implementation detail while guiding you towards your goal.
- nirimda 3y ago
  To be clear - the conceptual space the software is built around isn't an implementation detail. It's the way you reach your goal; it necessarily imposes a burden on the user. A good conceptual space presses less heavily against the user, but you can't obscure the notion that there are containers in a file system but not a relational database.
  - moring 3y ago
    There is always the discussion whether the UI should "hide the implementation details" (make the internal model, which differs from the conceptual model, invisible -- resulting in hard-to-understand behavior) or "make the implementation details visible" (change the conceptual model to be equal to the implementation model, and force the user to adapt to that). But the one option that is rarely used but yields the (IMHO) best results is: design the conceptual model, then build/change the implementation model to be equal to it. One example for this strategy that is forever stuck in my head is macOS application folders. The conceptual model is that an application can be moved around like a file, and applications be organized in folders like files. But you also want to run an application by double-clicking it. Instead of what Windows (and then Linux) did with links, menus, installing applications and centrally registering them etc., the implementation was changed to be like the conceptual model. A whole class of errors from inconsistencies just vanished.

oivviopolite 3y ago

1. Set your page margin to 0px.

ozim 3y ago

One thing is that some times some things have to be made harder for end users good or for business rules protection. 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. 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.

Kranar 3y ago
I really detest that principle. For the design of my software I make almost every action reversible and avoid at all costs confirmation dialogs or anything that makes it seem like the user could be at fault for something if they choose incorrectly. I also work on financial trading software so I do need to think a great deal about user error and the best principle I have found is to never create a situation where a confirmation is needed. Among new users it creates anxiety and indecisiveness, and among experienced users they just ignore it and it's noise to them. All confirmation dialogs do is make the developer/designer punt responsibility off to the user for what is generally a bad design decision.

tsunamifury 3y ago

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. This is so obvious yet so many completely fail to do it.

eviks 3y ago

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)

guardian5x 3y ago

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.

whycome 3y ago
Everyone wants to create new expectations and hope they become the new standard

beefield 3y ago

I think it would be important to understand the distinction between two types of applications, I call them "utilities" and "tools" here. 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. 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. And the peeve here is of course that way, way too often these are confused.

stronglikedan 3y ago

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.)

tech2 3y ago
Jira and the Unassigned/Automatic selection when trying to change a story assignment, I'm looking at YOU in particular!

andsoitis 3y ago

Nielsen's 10 usability heuristics for user interface design gives a good north star: 1. Visibility of system status 2. Match between system and the real world 3. User control and freedom 4. Consistency and standards 5. Error prevention 6. Recognition rather than recall 7. Flexibility and efficiency of use 8. Aesthetic and minimalist design 9. Recognize, diagnose, and recover from errors 10. Help and documentation https://www.nngroup.com/articles/ten-usability-heuristics/ https://www.nngroup.com/articles/ten-usability-heuristics/

lcuff 3y ago
The contrast between this Nielsen-Norman (NN) page and the OP page is marked. The NN page is much easier to absorb the information. More succinct, way better page layout. Both articles have information/direction worth heeding, but there is irony in the fact that the OP page adopts same-text size and paragraphing conventions of yesteryear that the NN page does away with. It's also frustrating that Hacker News doesn't pay attention to some of the information. In creating an edit to an existing post, the feedback after clicking on the 'update' button is not as clear as it should be. (It's a screen redraw, I guess).
- btbuildem 3y ago
  Are we looking at the same thing? The NN pages are cluttered with navigation to other areas, links for "more this and that", related courses, etc. Everything is in six different font sizes, there are variously-coloured illustrations that pull at strenuous off-topic metaphors... it's a mess. In contrast, the OP page is clear, simple, sticks to the topic at hand. Easy to read typography, eight paragraphs for the eight rules.

nyreed 3y ago

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.

jetrink 3y ago
I wish this would be addressed at the OS level. If a target popped into existence less than ~0.25 seconds before it was touched, a touch event shouldn't be generated. Humans reaction times aren't fast enough to hit a button that quickly anyway.
- murermader 3y ago
  Great idea. Should also take into account misclicks directly after layouts shifts in some websites.
- yshklarov 3y ago
  One problem with this: People often learn to touch multiple targets quickly in sequence, because one touch event predictably pops up the target for the next event.

zestyping 3y ago

This one simple information-theoretic principle is an effective guide for user interface design: Things that are the same should look the same, and things that are different should look different. 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! 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.: - If the user changes something, make the change immediately visible - If internal state affects what the user can do, make it visible - Don't use nonstandard interface widgets or icons If you can get this right, you're a lot of the way there.

zubairq 3y ago

I always think of the one golden rule of interface design to be: Don’t make me think!