Theory and Practice in UX Design

Abstract

In many productions, work processes are becoming increasingly complex and are controlled, monitored and analysed with the help of computers with appropriate software. The task of user-centred design is to present this wealth of information to the user in such a way that the relevant facts can be quickly grasped and analysed in order to react accordingly. A customised interface can increase effectiveness, employee satisfaction and also error prevention. Legislation has also responded to this increasing relevance by issuing the standard on human-centred design of interactive systems [1].

From experience, problems often arise in the practical implementation of theoretical concepts that could not be foreseen beforehand. For the successful completion of the project, these changes/events should be reacted to and the processes adapted if necessary. In this paper, the possible problems and deviations in the implementation of DIN EN ISO 9241-210 are to be pointed out. For this purpose, suitable methods for obtaining information in theory and practice are illustrated for each phase. It will also be shown that the entire design process can develop a momentum of its own, as external influences and new information often lead to an adaptation and readjustment of the selected methods.

1 Design Process According to DIN EN ISO 9241-210

Due to the fact that more and more people have to deal with computers and software in their daily work, the government has reacted and issued standards and guidelines for the human-centered design of interactive systems. The various parts of DIN EN ISO 9241 list the procedures, requirements and recommendations for designing an HMI.

Basically, the entire development process should be iterative, i.e., certain procedures can or should be repeated if necessary. Also, the later users should be involved already in the development, since the comprehensive understanding of the tasks and the working environment are crucial for the success of the software. By having users repeatedly review and evaluate the design solutions, the design can be adjusted and refined.

In order to design a user-centered system, DIN EN ISO 9241-2101 [1] recommends an approach with four development phases (Fig. 1):

• 1. Phase: Understanding and defining the context of use

• 2. Phase: Specifying user requirements

• 3. Phase: Developing design solutions

• 4. Phase: Evaluation and design

Fig. 1.

Design process according to DIN EN ISO 9241-210 [1]

1.1 1. Phase: Understanding and Defining the Context of Use

The determination of the ACTUAL state is the basis for the analysis and provides essential information about the technical and organizational knowledge of the application area. Among other things, the analysis provides facts such as:

• Who works with the system

• which work is supported and

• which technical conditions are available.

In addition to the determination of the given state, the existing weak points should also be pointed out in order to consider them in the implementation [2]. It is helpful if facts such as organizational structures, business processes and its weak points and workflows are already documented.

A wide diversity of methods is available for obtaining the information, such as questionnaires, interviews or on-site observations.

Depending on the depth of detail of the available information, the different methods are suitable. Combinations can also be useful.

On-site observation of work processes provides additional information to obtain a holistic view of the performance of activities, especially for those tasks that have a high routine component. If on-site observations are not possible or the effort is too great, procedures and methods such as live ideation can be used as an alternative.

For a better understanding of interrelationships and dependencies, it is helpful to present the processes in the form of charts, diagrams and/or flowcharts. Often, further weaknesses, information deficits or even questions are raised that are important for a holistic understanding.

1.2 2. Phase: Specifying User Requirements

After the ACTUAL analysis has been completed, the usage requirements are derived. The usage requirements contain generally formulated requirements as given by the user's work tasks; under no circumstances do they contain software-specific features [2].

The first thing to do is to clearly define who the main user group is. Due to the large amount of information, it can be difficult to understand and specify the needs of the individual target groups. In some cases, creating fictional people, called “personas,” can reveal a more concrete picture of the target group and their needs.

Once the goals and requirements have been identified, it is useful to clearly define them. This can be particularly helpful in the design phase and also during the argumentation towards the customer. In addition, the project status can always be checked against these criteria. However, it should be noted that this requirements list can be adjusted and supplemented throughout the project.

1.3 3. Phase: Developing Design Solutions

The implementation can be done with the help of different types of prototypes. A software-based solution is chosen for the most part for the design of interfaces, because at an advanced stage it is possible to link between the screens and thus experience a “real” impression of the menu navigation.

For the design of an interface, design criteria (structural structure) and design guidelines (type of presentation) have developed over time. According to Ben Shneiderman [4] and Jakob Nielsen [5], the following principles should be considered when designing an interface:

• 1. consistency

• 2. universal usability

• 3. informative feedback

• 4. completed dialogues

• 5. error prevention/error correction

• 6. reversibility

• 7. user control

• 8. relief of short-term memory

• 9. correspondence between the system and the real world

• 10. help and documentation

Many of the design features listed above are taken for granted at first glance. The structure of an HMI is usually developed from the rough to the small, which can cause the overall consistency of the concept to be lost sight of when working out the details.

1.4 4. Phase: Evaluation and Design

In each phase of HMI design, the results obtained should be repeatedly reviewed, questioned, revised and adapted. Different methods can be used for this, such as pretest, interviews, workshops, cognitive walkthrough. The choice of method depends a lot on the user group and the course of the project. Often methods can be combined. One possibility could be to conduct a pretest in combination with the observation of the users. Afterwards, a short interview could be made with the person in order to find out how the work and the operation of the program were perceived.

1.5 Documentation

Good documentation helps the customer to improve his understanding of the process and also of the product. The central role here is played by the style guide, as this represents the design guideline for the software. As work is done with the document, the structure should be well thought out so that elements can be found quickly. At best, a user-friendly design is also followed through here. Even after the project has been completed, the software will continue to develop; it is important to maintain the corresponding documents so that the consistency of the product can be maintained.

2 Design Process in Practice

According to the classic design process, the individual phases are worked through in chronological order. The evaluation briefly refers back to the previous phase and is mainly carried out in the design phase.

However, practice clearly shows that such a linear process is rarely or never adhered to. Already during the procurement of information, misunderstandings can arise regarding the importance of information and/or delays in the transmission of data. Furthermore, there is the danger that the selected methods for information procurement are not target-oriented and an additional method must be applied. This can already cause the first deviations from the planned schedule.

In addition, it may be determined during the presentation of the first analysis data that the specified circle of users must be expanded, since additional groups of people will use the program/app. If this is the case, the needs of this user group must be analyzed and compared with the existing requirements. As a result, previous results will have to be adjusted more frequently.

Extensive research is the basis for the success of a user-centric HMI. Therefore, the significance and the resulting importance of the research should be explained to the customer. However, the employer usually demands concrete solutions quickly, which means that tasks from following sections or phases often have to be brought forward.

In order to meet the wishes of the customer, the information can be evaluated and defined as preliminary requirements after the initial information gathering. This also offers the possibility of evaluating and, if necessary, consolidating requirements through more precise queries, further surveys and observations.

For successful project implementation, it is useful to clearly formulate and prioritize the requirements from the research. By defining the goals, the requirements for the product become clear for the first time. Also, especially in large and complex projects that run over a long period of time, the goal hierarchy can help not to lose orientation during the implementation. The method of goal definition is well known in project management [3] and is used at the end of a project to make an objective evaluation of the successful implementation. Often this step is not carried out at the beginning of a project, because the development of the prototype is already started. Only afterwards the benefit of the formulation of the goals becomes conscious e.g. if it goes to the documentation and explanation of the concept.

Another very useful method that can be borrowed from project management is environment analysis. In the first part of an environment analysis, all factors (stakeholders and factual factors) that have a direct or even an indirect influence on the project are identified. Then, the individual factors are evaluated and weighted to ensure the satisfaction of the affected persons/groups of persons. The analysis includes the possible risks and the measures derived from them.

In this context, communication to the stakeholders is more important than clarifying the framework conditions. This is due to the fact that the more a person is made to feel that he or she has been actively involved in shaping the project, the more sympathetic he or she will be towards the result. Like the goal definition, the environment analysis is carried out rather rarely, because during a project no great importance is attached to these two analyses.

After the first data collection has been successfully carried out, a first rough prototype can be presented to the customer.

Here, especially at the beginning, attention should be paid to a strongly reduced surface design in the design, so that it is suggested to the customer that this phase is exclusively about the construction. Otherwise, the customer can be given the feeling that he already has a completely designed product. Because of this, it should be pointed out constantly, especially at the beginning, that it is primarily about the structure, display and weighting of information and not yet about the design of the individual elements. This only follows at the end, when the process and the type of presentation have been clarified.

It may be useful to present the results in small steps, especially at the beginning, because this is where the basic orientation and structure of the product are determined. The further the development progresses, the longer the intervals between the individual evaluation rounds can be. The benefit of conducting multiple iteration loops should always be made clear to the customer, because the clearer and more detailed the user feedback, the more user-specific the end product.

Depending on the phase and method, different evaluation methods are suitable. The effectiveness of a method depends not only on the implementation, but also strongly on the people involved. Consequently, it makes sense to apply different methods to similar scenarios from time to time to determine which method is the more successful (Fig. 2).

Fig. 2.

Design process: theory and practice

3 Conclusion

The theoretical process from DIN EN ISO 9241-210 can be regarded as a rough outline in practice. In experience, however, it has been shown that a linear progression of the phases - especially in large projects - is not practicable.

Even at the beginning of the project, it can be assumed that not all the information and documents will be submitted in full by the customer at the start of the project. This is usually due to the fact that the customer assesses the relevance of information differently. Also, there are often different understandings of the duration and effort of each phase on the part of the customer and the contractor.

Therefore, it is essential for the successful completion of the project, among other things, that transparent and constant communication is maintained with the customer. The earlier problems, changes and wishes are discussed, the easier it is to react to them and take them into account in the project. Another important aspect is that applied methods are questioned again and again and if necessary supplemented by new methods. Every project is different and changes should be reacted to dynamically and at short notice. This makes strict adherence to fixed structures a hindrance.

4 Discussion

Consequently, it can be discussed to what extent the process in DIN EN ISO 9241-210 can be seen as a sequence to be aimed at, or whether the process can be seen more as a kind of ‘guideline’ or rough basic structure on which the design process is based instead of viewing it as a ‘slavish’ guideline.

In this course it should also be considered whether a weighting of the phases e.g. by a rough time estimation could be helpful. Furthermore, the listing of possible disruptive factors (new user groups, delayed information, etc.) could help to make a more realistic project progress planning.

Finally, in actual industrial projects with design involvement, it turns out again and again that the established development models - whether according to DIN ISO, SCRUM or Design Thinking - do not sufficiently reflect the actual development methodology and way of thinking in the design process. It would be debatable whether a method and guideline adapted to the actual iterative and recursive approach in the design process should be developed, or whether the established models should be revised accordingly.