User interface ideals can be very subjective. Here are my own biases. Much of it may be motherhood and apple pie. In a way, more than 25 years after the WWW project started, you'd think that these things would be be generally understood. And they are covered in many blogs and books. But here are some points which still now seem to need pointing out. They may not include your own pet peeves -- but here are some of mine. The order is a bit random.
If you put up information which your user can read then you should always make it copyable. (This is not just for web sites, it is also for native apps) You can't tell when a user won't want to share it with someone, look it up in a search engine, save it for later.
People who do not understand a lot about your system may still be able to use a full detailed error message, but looking it up in a search engine, or asking a friend. Make this easy by allowing them to copy and paste it! You'd think this was obvious but it amazing how often it isn't done.
An exception to the copyable rule for text is, for security, a password field.
These normally do come paste-able out of the widget library, so it takes actual effort to make a non-paste-able one, but it happens when developers try to be over-cute about capturing all the keystrokes, and for example preventing anything being typed apart from numbers in a numeric field. If you take suppress and replace the default line editing the browser does in each device, then you should have really important reason for it, not just cuteness.
Auto-complete libraries may be a common source of problems here. If the auto-complete librray you are thinking of using doesn't allow users to paste, it is a step backwards.' Just go back to the basic input widget.
You should be encouraging your users to be using long unguessable passwords. This means they will be generating them or storing them with something app or some service but not in their heads. They will be copying them into the pastebuffer and pasting them into your app. If they then can't paste them in, and are forced to type them (perhaps on a phone keyboard with the echo of the characters replaced by dots) they may give up and switch to using a short and unsafe password out of frustration.
It seems that when I am entering a password on laptop I sometimes I have a checkbox available to make it visible, but often the option isn't there.
Meanwhile, on a phone, the ability to make the password field visible is more important. If you want me to use a good password, I am not going to be able to type it in without mistakes -- unless you let me see it as I type it and pour over it to correct errors before I hit Enter.
When I load a form, for example a log-in page, I am typically going to be filling out the form starting at the first field. It is a bit lame of I have to click on the first field to get the focus there. You should set that up automatically. After that first field, I should of course be able to navigate around the form using tab.
Only, though, take the focus if you are doing it immediately as a result of my user action, so I am expecting it. Otherwise you will not only confuse me, you might also end up with secret thing I was typing somewhere else.
For example, in an alert box for something urgent you need to put up at a random time, do bring it to the front, but do not move the input focus to it.
A modal dialog box is one which interrupts the flow of user interaction, blocking the ability to use any of the rest of the UI, until the user has finished the sub-task involved. They are almost always a bad idea, unless it really is crucial that the user attend to nothing else until the dialog box is answered. The problem is the at the user is working on things in parallel, and for all kinds of reasons will justifiably want to work on different things before they finish the sub-task.
An example of doing it wrong might be, on a bank web site, popping up a blocking UI to transfer money from one account to another, when the amount of money transferred, or an account number, may be elsewhere in the site and end up being inaccessible. Another example might be of popping up a modal which the user doesn't understand, while blocking their ability to actually look up the help information about it.
Instead, just open up the dialog box in the real estate you have on screen, between other related things, and when the user has finished, close it up again.
In fact, there are two related anti-patterns: modals and popups. I just found my calendar program was completely unresponsive. Anywhere I clicked just made a little error beep. In fact I had to look at a different screen completely, one which had no calendar windows on it, to find a modal popup asking ."You are changing a recuring event - do you want to change all of them or just one?". I must have jogged the posiion of an event by accident. A better place to talk to me about it is by the UI for the event itself, not on some screen you might think is my "primary screen" to get my attention. )
A pop-up is a bit of UI which is in some central or default place, typically (I imagine) to get my attention. They are easy to code in web app programming, with alert() and confirm() functions very available. (A quick rant about those two functions: they are poor anyway in that they are not hypertext - you can't give the user links to what you are talking about. They force you to give a poor UX.)
There is also a security argument against popups. From a security point of view, I want to know exactly who is telling me something, who is asking me for infomration. A given app want to install a helper extension? Let that app itself tell me, not a disemmbodied popup. I am trained in OS X to type in a Administrator password to popups. Not a safe habit to have. Popups are too easy to fake.
Instead take me into the app itself, or into the System Preferences where I can look at all installed things, and I can if I want, find out what this extension will do, and what resources and access it will need.
Devices are becomeing more and more disparate in their size and capabilities, and our systems are getting better at allowing better at allowing our experience and our activity and our creativity move smoothly between them, and be in multiple places at once. I am feeling more and more comfortable with UX where functionality which is on an object itself rathan in a global menu for the whole app or for the whole logged in session.
Any web page should have a descriptive title which can identify it out of context. That is, when it shows up in a user's bookmark list, then it will make sense and help the users find the page again months later. So for example "Acme Order 8948375 Complete", not "Orders", or "Complete", or "Acme Inc". The title of this page is "User Interface, random tips - Design Issues" so you can spot it your bookmarks and it won't look anything else you have bookmarked. The page title ("User Interface"), random tips" is before the series title ("Design Issues") so that when it is truncated, like in the tab label of a browser with many tabs open, you will be able to tell it from the other Design Issues articles.
Any webapp page should also similarly have a nice, useful, title. This means adjusting it as the user navigates around your app. The user should be able to bookmark separately different views of the same stuff. So give them different URIs and different titles. This means you have to be organized about all the different views in the system, and make sure you don't leave an old title up from a previous view.
By the way, for downloaded files, like PDFs, or XML data files, there is no title users will see, so think about the filename you give them to download it should also be useful in this case. It will also determine in which order the see it, as file bowsers typically list files in alphabetical order so "2023-01-12-Ac-87612374.pdf not "Jan-12-2023-Ac-87612374.pdf""
Anything which moves by itself like a carousel I find distracting unless I have turned it on myself because I want to play it as I play a video. It makes the site look exciting to people who are not actually trying to actually use it.
If you have a "save" button, then you may not be trying hard enough to save my data automatically.
If I fill out a form, and one of the form fields is invalid, then save all the others. Let me fix the invalid one in its place. (And when I have fixed it in place, take away the error message about it not being right immediately, don't wait for me resubmit the whole form again.) The error message should be there when and only when the bad syntax is vidible in the input field.
In general, I set my browser and my mail reader to by default use a font size which I am comfortable. Mail applications which send me text which is deliberately 80% of normal arrogantly assume they the know better what is going to work for me. Same with web sites. Yes,there are lots times when a smaller font to normal is used, like in footnotes which are really unimportant. But son't make the default font for text anything other than 100% of normal.
This applies also if you are designing UI widgets for re-use. Often pop-up boxes and other input fields are designed to default to a smaller font to the surrounding text. Not logical.
See also Matej Latin's notes on Typeography
Never underestimate the time it may take before I am ready to move to the next step. Need my passport number? Be prepared to wait while I apply for a passport and get it back from my government. Need to know when I want to travel? Let me figure that out over the next few weeks. Even for something very simple and trivial, just be aware that I can be interrupted in a million different ways, and still want to eventually, do something in your session. Do something with the data I have already given you.
True, you should time me out of I am in a very secure state, authenticated with powerful credential, such as a bank account, especially if you can't be sure whether I have the computer, the room, the house, etc to myself.
Unlike most of the topics in these Design Issues, this one has been written about at huge length.
Also,... never use a multi-page electronic digital road sign. It distracts users, who have to take their eyes off the road for 10-12 seconds... safer to send them a text?