09. Feb 2021
UI/UX Best Practices: What is important in the implementation
UI/UX stands for user interface and user experience and is one of the core competences at XITASO. UI/UX makes operation of the software easy and thus ensures satisfied users and a successful company.
In this article, our UI/UX expert Simon Engelmann reveals the challenges that exist in many projects and which UI/UX best practices have proven themselves for these purposes at XITASO.
1. Less is more
Just because a software has a lot of functions, doesn’t have to mean it’s a good software.
2. The easier, the more difficult
What seems very easy at the end can be hard work during the process analysis.
3. Usage concept
It is about more than just “And what would you like from a new software?”
4. Holistic view
Only those who see the overall process and its dependencies can create software that is really accepted.
1. Less is more
When a project commences it is often little more than an idea or a vision. Concrete notions as to what kind of product or service it should exactly become, seldom exist. What functions are required? And which of those are most urgent?
These decisions are taken by the product owner on the customer’s side. However, as a rule there are many other stakeholders from the board and other departments who want
certain functions implemented and who influence the decisions of the product owner. While the product owner tries to satisfy all stakeholders, focus is quickly lost, and overloaded and ambiguous interfaces that users no longer understand is the result.
A large range of functions is not a bad thing in principle, but the users must then receive support and guidance. Therefore, the users should only be confronted with a manageable number of functions per page, and at the same time receive help with the order in which the respective functions have to be carried out.
We are not saying that the range of functions cannot be large, but they must be well divided to make sure users don’t feel overwhelmed. But the question remains as to which functions should be offered at which time point. It is important to orientate yourself to the frequency of use of the functions. Functions that are consistently used should only be one click away, or maybe even permanently visible no matter which page you are on in the software. A less prominent space is sufficient for less frequently used functions.
And even when there is a good subdivision and the users are coping well despite many functions, critical questions should be asked about each function:
Does this function really help users to carry out their tasks?
If this cannot be answered unequivocally with “yes”, one must also have the courage to omit functions. Fewer, very well implemented functions benefit the user more in the end than many half-thought-out ones.
2. The easier, the more difficult
Displaying fewer functions does not mean that the functionality is inferior or that the application is less complex. Neither does it mean less work in creating the application; indeed, it means much more.
Alongside analyzing how often which function is needed, it is also important to understand the tasks and processes in detail. Only thus is it possible to propose optimizations that actually lead to simplification.
To put it simply, one can say that the easier the operation is to be at the end, the more effort must go into the understanding of the processes. The more complex these processes are, the greater the effort required to create an intuitive operation.
In the best case, the users are not even confronted with a task via the user interface, as the execution is now automatically carried out in the background.
3. Usage Context
In order to avoid overloaded interfaces and unnecessary functions, the users should be the focus of attention from the outset and the context of their use should be considered.
This is about getting a more accurate idea of who is actually using the application in the end. How much prior experience does the end user already have in dealing with digital applications? What are the person’s work objectives?
If users later have difficulties in executing their tasks or are skeptical about the application, for whatever reason, the new software will not be used. All the work will have been in vain.
The user’s tasks are the core element of the usage context. They are the reason why the system and the user interface exist in the first place. The only reason a software exists is to simplify recurring tasks for the users. Therefore, the absolutely most important thing is to identify and evaluate the primary tasks.
The tasks must be carefully investigated and understood. This is the only way to evaluate how important the task is in the overall context and which optimization opportunities exist. It could also be that the task no longer has to be carried out at all in the new system.
It is useful to form clusters to evaluate the tasks and also to rank the frequency a task occurs according to device type.
The user environment has a major impact on the design of the user interface. It is about questions like:
- Which devices are used?
- At what time intervals are they observed?
- Are, for example, gloves worn? This must be taken into account when selecting the control panel?
- What time is work carried out?
- Is there a lot of diversion from other activities or high noise levels?
- Are other applications used in parallel?
- What levels of specialist knowledge does the user possess?
- In what time frame must they complete their tasks?
- Which aids are available?
In order to gain knowledge of these details, it is important to invest enough time in interviews with the users.
Personas are another method of making clear who the concrete users of the software are. Profiles of users are created which are used respectively for an entire user group.
The profiles contain the collected information about the users themselves, their tasks, their environment and their resources. All project participants thereby have a concrete vision of who the application is being developed for. Using detailed representations with pictures and names, the person becomes tangible and easy to remember. With the created personas in the back of your mind, product features, interaction concepts, or application appearance can be better developed.
How does the usage context impact the user interface?
In one of our projects, the analysis of the usage context found that the software is only one of many that had to be operated. The software to be developed should be operated “alongside others”. The most important thing in this case was the status display. If a critical event occurred, the user’s attention had to be drawn to it quickly. Therefore, in a limited visualization, only the system status (red, yellow, green) was displayed in full. An animation illustrated the urgency at different speeds.
Another finding was that the application was also often used in dark environments, which is why a dark version was created in addition to a classic bright variant. The eyes had to adjust less when changing between the environment and the monitor, and therefore became tired less quickly.
4. Holistic View
The primary users are addressed for the first version of the software. They are the ones with the highest demands of the new software. This is a very important step, but it is also important to take the other groups into account who may have points of contact with the system.
The eagle hunts its prey
How can we ensure that all stakeholders and their needs are taken into account and thereby that processes can be optimized holistically?
In one of our projects, a product configurator should be developed to accelerate the sales processes for marine gears.
In order to take all stakeholders into account, the entire process was first examined from a bird’s-eye view during the analysis phase. This gives you a good overview of who is involved and who has to be included when necessary, as well as which processes depend on each other.
The eagle swoops
After the general overview, we will now take a closer look at a process step. In our case, we will look at the process step, “preselection”, as it was the one most needed by the primary users and was the foundation for the further steps.
Analysis and Optimization of the actual status
The detail process step, “preselection”, is broken down into its individual work steps and analyzed. Which employee groups are involved? What documents or resources are used? What are the dependencies?
This overview can be used to check the actual status for optimizations. In this case, for example, it has been identified that the process can be significantly accelerated by real-time validation of the configuration. Previously, the configuration had to be selected manually and then confirmed by a different post.
Software, which will be accepted
Thanks to the holistic view and the broad involvement of different employee groups, one not only gains valuable knowledge for the new concepts, but also strengthens the willingness of the users to accept the new software. Those who have been included and involved are much more motivated to use the new software and give feedback.
Let’s assume the following: The software was developed within a small group and is perfectly implemented from an objective point of view. All necessary functions are available, all usability guidelines have been met and the application looks appealing. It is most unlikely that this will be achieved, when so few users have been involved, but let’s assume it anyway for our purposes. Even in this scenario, the software will not succeed. Our eyes light up when it comes to the conception of a new software. Users, on the other hand, are more critical. And they are right. They are the ones who have to adapt, and they will use the software on a daily basis. There is a lot of skepticism. Will my tasks be taken into account in the new version? How will they be shown? Do my tasks even still exist in the new process?
However, if I become involved as a user at an early stage and can contribute myself and my wishes, the software in the end is also a small piece of me and I will enjoy using it.
Less is more
Each function should be critically examined as to whether it really helps users to do their jobs. If this is in any doubt, these functions should be deliberately omitted.
With a large range of functions, a structured and guided division into several pages makes sense. Then the users do not feel that they have been left alone in a cockpit with hundreds of buttons.
The usage frequency specifies which functions should be only one click away and for which functions would a less prominent space be sufficient.
The easier, the more difficult
In order to be able to propose meaningful optimizations for simplification, the processes must be understood in detail. The simpler the operation is to be at the end, the more effort must be put into the understanding of the processes. What looks like child’s play at the end, was normally hard work in the process analysis.
The usage context looks at the users, their tasks and their environment. In so-called personas, this information can be visualized for all project participants. They are very tangible reminders of who is operating the software at the end.
The users and their context of use should be the focus from the beginning. This is the only way to create user-friendly software that is accepted and used effectively.
In addition to the primary users, the secondary users as well as the stakeholders should also be considered. To do this, it helps to first look at the process from a higher level in order to identify the dependencies.
After that, individual process steps which are especially urgently required are analyzed in more detail. When you begin with a visualization of the actual status, then optimization options can be proposed.
Instead of developing the software in a small circle, as many users as possible should be involved. If you participate yourself, you not only make the software better, but you also enjoy using it in the end.
Author & contact person
Do you have questions, ideas or feedback on this topic? Feel free to contact us!