Principles of UX/UI
People Don't F*cking Read
It was a famous saying of a boss of mine, and it still holds true. It's also, for a person like me who loves reading and thinks in words, rather than pictures, one of the hardest rules to learn. There are too many times when I've stood behind a user/player during play-testing, steam billowing from my ears, silently willing them to just read the bloody instructions that are there, LITERALLY RIGHT THERE, written on the screen. But some people just...don't. It's one of those things that, like the existence of raisins, you might not like, but you have to accept. Good UX/UI in your application or game should be about more than just text; use symbols, indicators, sounds, animations and highlights to draw your player to where they should be going next if straight up telling them isn't getting through. A glowing, flashing, whistling "Next" arrow might not be noticed because it says "Next," but the effects might just get their attention.
Interaction Should Be An Experience, Not A Puzzle
Don't reinvent the wheel unnecessarily. Breaking with established norms and conventions doesn't make you a creative innovator, it just confuses your user, and makes their experience worse, as they have to invest energy in figuring out how your application works first, rather than just going ahead and using it. As (finger quotes) "normal" technology users, we are already familiar with a huge array of symbols and conventions for how things such as as forms, displays, password entry boxes and games of various types are expected to work. Creating novelty for the sake of it, particularly when you are considering inventing new symbolic indicators, should be considered very, very carefully, ie don't do it if you can possibly avoid it! Be consistent in the ways you use colours and arrange elements on a screen, and try to layer multiple levels of communication into individual items, eg. if the password is correct, display green on the traffic light indicator, put a tick next to the input box, and allow the NEXT button to display. If the password is incorrect, display the traffic light indicator as red, and do not allow the player to move on to the next item until the issue is resolved. Sounds can also really help with this, as they can convey emotion: a happy, positive "ding!" for correct input, a harsh "womp!" for a disappointing error.
Signpost The Way
The Last of Us has one of the best examples of user signposting that I can think off. The game is full of subtle uses of the colour yellow, which act as signposts to guide the player through areas. There are yellow cables, yellow graffiti, yellow traffic signs, yellow police hazard tape - it's everywhere. The yellow signposting is so subtle that many players don't even realise it's there, yet subconsciously register it and follow along the path highlighted for them. Non-game applications can also use a colour, shape or symbol to indicate where the user should go next. For a non-digital example, consider famed architect and socialite Stamford White, who had white wine served by a blonde haired sommelier, and red wine served by a brunette. Instantly intuitive! Designing for the natural instincts of the user, though not a fool-proof plan, can often be a helpful approach. However, as Stamford White was also a serial rapist and child molester, he probably shouldn't be remembered for his design skills alone.
Give Meaningful Feedback
Terrible error messages like these give the player no way of understanding or diagnosing the problem, leaving them confused, angry, and worried. Ensure your error messages are meaningful, and where possible include a) a unique identifier for the error type b) a description of the error intelligible to a non-technical user and c) a suggestion for a remedial or preventative action. It's often important - more so when designing video game interfaces rather than medical forms(!) - to permit the player/user to make minor mistakes, but it's vital to give them opportunities to rectify, and resolve, or to learn from their mistakes so they don't make them in the future. And if something has gone wrong which is outside the user's control, it is often useful to indicate that the blame lies elsewhere. A mild, humble mea culpa to the tune of "Oops, our silly server has made a mistake" can help sooth and reassure nervous users, but if that error occurs too often, you do set yourself up as a direct target for your users' anger!
Less Is More
Think about the number of things you are asking the player/user to do: to look at, to interact with, to interpret, to remember, to read, to listen to, to input, to check for accuracy, to judge distance or speed of...when you actually tally it up - it's probably a lot! The appropriate amount of on-screen stuff is obviously directly relative to what you are making, an immersive video-game verses a piece of training software for a spreadsheet program, a competition entry form verses a browser game, and judging the correct level of on-screen clutter will only come with experience and time. What you can do to help yourself and your users, however, is to establish working conventions that tend towards simplicity. Buttons could be different sizes, but unless you can think of a really good reason why not to, consider making them all the same size. Where there is a binary option, use a toggle; where there are multiple options on a continuation, consider a slider. Restrict yourself to a small number of colours, and decide on, and stick to, a consistent art style. All of these are guidelines, you will always find exceptions, or reasons to bend the rules to better serve the project. That said, I once reviewed a project than contained 17 different fonts in it's in-game menus. 17 is definitely too many. Try 3. Maximum.
(Probably.)
