Before the game is made available to a broad audience, we test it in smaller groups to catch the moments when the player is blocked because he doesn't know what to do next. Such situations often happen because when creating a game or application, we fall into a trap called "I know - so others will know too". But during the creation process, we teach ourselves how the application works and wrongly expect others to know it too. Often, the rough idea for an application first goes to the engineer, who must first come up with what it should look like. In my opinion, this is mistake number 1 that most often leads to subsequent ones. To avoid pitfalls, it’s best to stick to strict rules. Unfortunately, it usually happens that a client wants something unique right away, and then he is surprised that not everything works as he imagined and wished for. In spinbits there are project managers who keep eye on the progress of the project. This is why I prepared a short and subjective breakdown of interface design mistakes I encountered as an application user and some advice from my game developer experience on how to avoid them.
Experienced developers and engineers make sure that the button is not too big, especially in applications for phones or tablets. Hitting a small button requires accuracy and precision. All zippers suffer the most. Sometimes the hitbox is so tiny that it frequently triggers another option or becomes impossible to move. It shouldn't be our goal to frustrate the user. ;) We should make his life easier! :)
Let’s look at this example: how much time do you need to find some rarely used features in Windows OS? Lately, I was wondering, where can I uninstall programs? I’ve spent a few long minutes looking for the answer. An invisible side scrollbar prevented me from seeing other options, and I didn’t know how to find them.
After a looong moment of closing and reopening the window and staring at it with no clue what to do, I’ve finally noticed this tiny line which turned out to be a hidden scroll bar.
Forcibly hiding certain functions is not always a good solution.
I remember switching from Windows to iOS and always looking for the buttons to close the windows or situations when the keys did not work correctly. After some time, I’ve learned where everything is, and my fingers have gained practice on the keyboard, but I still feel discomfort when switching between systems. Other examples are those websites where someone came up with the idea of an unusual hiding menu so you can't find anything. So let's seriously consider whether we really want to deviate from the standard and change the usual location of the buttons and if it’s worth changing. ;)
I remember the situations when we (designers) insisted on some options in the game. When the players came and couldn't find these options, we had to tell them where to click. We thought it was obvious and so innovative at that time. Then our game engineers team spent a lot of time looking for an idea of how to get out of the deadlock because the game was already at an advanced stage and we couldn't easily make changes.
Once I was asked to evaluate the application's functionalities, which displayed different search results depending on the selected option. Yes, the application engineer knew, which state was responsible for the button pressed and selected option, but anyone else didn’t. It was only because the engineer chose the background color as the color of the selected option.
If you're not an interface design expert, then let's stick to the standards:
Let's choose different colors for buttons to distinguish them from the background so that no one doubts what and where the buttons are doing.
Another problem is too much information that someone tries to squeeze into a tiny window. Sometimes badly positioned. They do not form blocks that would allow, at least visually, to divide the areas of activity. It is a good practice to move them away from each other and visually distinguish (colors, frames) thematic groups. Let the user know where they will lead him and that the area of operation is changing.
[img found on Coding Horror https://blog.codinghorror.com/this-is-what-happens-when-you-let-developers-create-ui/]
Another problem is when we create too many layers. For example, the user must click through 5 different layers to enable or disable an option to find the required information.
A good rule of thumb here is to stick to a maximum of 3 levels. This is great, for example, in the Spine program that I use - if an option requires more sublevels, it has been separated into secondary tabs.
Rethinking the website or application organization should be the first step.
Also, be careful about the names of functions/options, which - we, the creators - have gotten used to, but they tell the user nothing. For example, when creating the function, we already know the difference between “Option-1” and “Option-2”, but before the user learns it, he may get discouraged.
In my opinion, the project should always start with some visualization. What will it look like? Where will the buttons be placed, and how will any info be explained to the user? These are minimum requirements. You should have some ideas, reference pictures, and some ready assets (landing page, pop-up, etc. - the most important for your design) to give to a person working on it. Also, remember about fonts - any font designed should be given too. I asked for this many times - trust me! :) Probably, that is why pages and apps looking for fonts were created ;)
Of course, you don’t have to make all final assets at the beginning of your project. Usually, it’s going to evolve and change, so some work may be wasted, but If you don’t give any assets to the engineer before (s)he starts to work, then later, you will have to discard some of this work when it comes to redesigning.
If you’re an engineer and facing the reality that you start working on a project without reference, then IMHO, it’s good to have some standards and use them in the beginning. You also may take UI design classes, which will help you in the future.