Keywords

1 Introduction

Different approaches exist to describe the design and development process of human computer interfaces (HCI). A very common approach is the human-centred design standard ISO 9241-210 of the International Organization of Standardization [1]. Wallach and Steimle describe a similar approach with the focus on collaborative projects [2]. Another famous representative is the Usability Engineering Lifecycle by Mayhew [3].

An area that considers the development and design process of technical products from the mechanical engineering and engineering design viewpoint is the field of design theory and methodology (DTM). In this regard, there exist also several different ways to describe the used procedures and processes. The development of the internet of things (IOT) and internet of everything (IOE) increases the interdisciplinary nature of products and thus also of the human computer interfaces.

This paper takes up a methodology of the DTM and proposes an application to the HCI design and development process to gain new insights and a deeper understanding by opening a new perspective.

2 The Field of Design Theory and Methodology

The field of DTM became an independent research area after WWII [4]. It combines a large number of different approaches, some of them incompatible to each other. Based on scientific findings, the objective is to determine how much designing can be systemized and automated and to develop concepts which make the activity teachable and trainable [4].

In the variety of approaches available, some have emerged as particularly popular. Weber gives a good overview in [5] and some of the most remarkable theories should also be mentioned here. Suh introduced a model called “Axiomatic Design” in 1990 [6]. Suh basically describes the design process as mapping from a functional space to a physical space. Another approach from the research field of artificial intelligence is John Gero’s “function behaviour structure model” [7]. In Europe and especially in the German-speaking countries, VDI guideline 2221 and the fundamental works of Pahl and Beitz play an outstanding role as a general framework and summary for design guidelines [8, 9]. The approach to product and process modelling this paper is based on is called Characteristics-Properties Modelling/Property-Driven Development, or CPM/PDD. It is based on the differentiation of product characteristics and properties. In the late 1990s, it resulted from mechanical design project work at Saarland University. It is particularly suitable for integrating existing models, methods and tools [10]. Its versatility has already been demonstrated in several research projects such as the approach of cost-driven development [11] the engineering change management [12] or the capturing of design knowledge [13] by means of CPM/PDD. For this reason, it appears to be especially appropriate for the intended purpose and was chosen as the basis for this paper.

3 Characteristics-Properties Modelling/Property-Driven Development

This section explains briefly the Characteristics-Properties Modelling/Property-Driven Development (CPM/PDD) approach. The concept of CPM represents a product model and PDD presents the process of developing and designing products based on CPM. The most significant feature is the differentiation in characteristics and properties of a product:

  • Characteristics (C) cover all the items of a product that can be directly determined and influenced by the designer. These are for example the geometry, structure, shape, spatial configuration and material consistency [14].

  • Properties (P) describe “the product’s behaviour” [14]. They cannot be directly determined and influenced by the designer (e.g. weight, safety, aesthetic properties, usability), only indirectly through modifications of the characteristics.

This distinction is also applied in other approaches; the special point is that it is the focus of CPM/PDD’s considerations [10].

The links between characteristics and properties are represented by relations. They can be read in two directions. In the analysis direction (R), characteristics are known and the product’s properties are derived (Fig. 1 left). In the synthesis direction (R−1), properties are known/required and the product’s characteristics are established (Fig. 1 right). In addition, Dependencies (D) respect potential constraints on the characteristic side and External conditions (EC) represent the context in which (analytical as well as synthetically) statements are valid.

Fig. 1.
figure 1

Analysis and synthesis in the CPM model [14]

Full size image

PDD describes the product development process based on the CPM product model. Weber depicts the iteratively conducted 4 development steps in [10] as follows:

  1. 1.

    The product development process starts with a requirement list (Fig. 2 top left). In the PDD approach, this is basically a list of required product properties (PRj). Starting from this, the first step of product development is a synthesis step: The product developer selects one of the required properties (in the case of a new design, usually the functional properties) and determines some essential characteristics (design parameters) of the solution (Ci) using suitable synthesis methods \( ( {\text{R}}_{\text{j}}^{ - 1} ) \), for example in the form of a sketch. Alternatively, existing (partial) solutions can also be used (e.g. solution patterns).

    Fig. 2.
    figure 2

    The four steps of a PDD process iteration [10, 14]

    Full size image
  2. 2.

    The next step is an analysis step (Fig. 2 top right). Based on the characteristics of the solution defined at this point, the properties (Pj, actual properties) are determined or predicted. Suitable analytical methods (Rj) are required for this purpose. This analysis should include not only the examination of those properties which were the starting point of the previous synthesis step, but if possible all (relevant) properties. This is not always possible in early phases because there may not be enough characteristics defined at this stage.

  3. 3.

    In step 3 (Fig. 2 bottom left), the actual properties (Pj) are compared with the target properties (PRj) and the individual deviations are determined (△Pj).

  4. 4.

    The individual differences (Pj) between the actual and target properties determined in the previous step are of relatively little benefit to the further process progress. However, they are the basis for an overall evaluation. The product developer must identify the most important problems of the current state of development and decide on how to proceed. This means that he must select the properties to be considered in the next cycle from synthesis, analysis, determination of individual deviations, overall evaluation and put suitable methods and tools in place for this purpose. In early stages of the development process, it is a possible strategy to take the properties with the greatest deviation between actual and target as the starting point of the next cycle. In later phases the situation is not so clear, under certain circumstances complex evaluation methods may have to be used. In any case, the results of the overall evaluation are the actual “driver” of the process (Fig. 2 bottom right).

The modeling of both, the product and the process is a major advantage of the CPM/PDD compared to most other models, which mostly focus on the process model. Among other things, this simplifies software support [10].

4 Processes in HCI

As mentioned in the introduction, there are also numerous procedural models for the design and development process in the field of HCI. The international standard 9241 210 [1] is the basis for many user-centered design methods. The aim of the User-Centered design is to design “products that have a high degree of usability” [15]. This includes a usable, manageable, efficient and effective realization of the user requirements. The user-centered design outlines the phases during the entire lifecycle of a design and development. It focuses on a good understanding of who will use the product by proposing four phases to go through in the design of each interactive system:

  1. 1.

    Understanding and specifying the context of use

  2. 2.

    Specifying the user requirements

  3. 3.

    Producing design solutions

  4. 4.

    Evaluating the design.

To realize a human centred approach in accordance to the ISO guideline, the development process should ensure to follow the principles below [1]:

  • The design is based upon an explicit understanding of users, tasks and environments

  • Users are involved throughout design

  • The design is driven and refined by user-centred evaluation

  • The process is iterative

  • The design addresses the whole user experience

  • The design team includes multidisciplinary skills and perspectives.

Together with the four design phases, these principles of UCD bring several dependencies into the development process. Figure 3 shows the ISO development process and its interdependences. It is complemented with the development results for each of the phases proposed by the International Usability and User Experience Qualification Board (UXQB) [16]. However, the UCD process does not specify precise methods for each phase. Therefore, the approach is very appropriate for the investigations in this paper.

Fig. 3.
figure 3

Interdependence of human-centred design activities [1, 16]

Full size image

In addition to this model, there are numerous other possibilities for the representation of the design and development. Due to its widespread use, this model will form the basis for further considerations.

5 Bringing CPM/PDD and UCD Together

In the development of interactive products, the requirements are usually not directly realizable. For this reason, the CPM/PDD model is particularly suitable in this context, since it describes a procedure for getting from the properties to the characteristics of a human-machine interface. In this chapter, the phases of the UCD are mapped to the steps of the PDD process. In the following explanations only a single iteration of the UCD or PDD is considered, in a real development process these steps are of course repeated several times until a finished product is obtained.

The first step project planning of the UCD is excluded, since it does not represent any of the recurring, iteratively incrementally executed phases of the process.

UCD starts by analyzing the context of use (phase 1 of the UCD) and specifying user requirements (phase 2 of the UCD). Output of these phases are the properties required (PR), the starting point for the PDD as shown in Fig. 4.

Fig. 4.
figure 4

Phase 1 and 2, defining the properties required

Full size image

Phase 3 of the UCD is the creation of solutions that meet the user requirements. According to CPM/PDD, these solutions represent characteristics, i.e. the elements that can be directly influenced. The design solution is therefore a set of concrete characteristics and the “produce” is the synthesis step for determining characteristics (Fig. 5).

Fig. 5.
figure 5

Phase 3, the synthesis step

Full size image

The fourth phase in UCD is the evaluation of a design against the user requirements. This evaluation corresponds to the analysis step in PDD. It is important that this step has no relation to the analysis of the context of use (phase 1 of the UCD) but refers explicitly to the evaluation of the design.

As a result of this analysis, properties of the solution emerge that can be compared individually with the required properties in the next step (Fig. 6).

Fig. 6.
figure 6

Analysis step

Full size image

The last step of PDD is the overall evaluation. Since this step is the actual driver of the development process, it is decided here whether the process is finished or not. If the user requirements are fulfilled, the process is terminated. Otherwise, depending on the result, a new iteration starts with phase 1, 2 or 3 (Fig. 7).

Fig. 7.
figure 7

Overall evaluation

Full size image

The mapping above shows that the four phases of both models cannot be mapped one to one. In phases 1 and 2, UCD focuses on analyzing the context and specifying user requirements. The aspect of the requirements analysis is not considered in the PDD process until a first version of the properties required, i.e. the user requirements, exists. In the course of the process, however, these are further developed, refined and in some cases discarded.

The representation of the relations R and R−1 is an interesting complement to the UCD. In particular, the method selection and execution of the synthesis as well as the analysis are presented in UCD rather implicitly and can be described more precisely with the help of PDD.

The evaluation of the results of an iteration (phase 4) is mapped in PDD more fine-grained. Here, the analysis, i.e. the determination of properties from the previously defined characteristics, as well as the comparison of the evaluation results with the required properties are considered separately.

A particularly interesting aspect is the consideration of the overall evaluation in PDD. In a development iteration, the evaluation phase is followed by a decision as to whether to jump into one of the preceding phases 1–3 or whether the level of development is assessed as sufficient. This very important step is only implicitly represented in the UCD, although the underlying decision making is quite complex. In the PDD it is mapped as an overall evaluation. But in this context, the following steps are only displayed implicitly. In this field, following UCD and CPM results in a better clarity of the individual steps and a clearer overview of all steps.

6 Applying the Approach

To provide a case study of how to use the approach, excerpts from an example provided by UXQB are applied to the process described in the previous chapter. The proposed outcomes of each phase are already mentioned in Fig. 3. For the context of use description, these can be user group profiles, task models, scenarios and personas [17]. From this the user requirements can be defined. An example of derived user requirements for a calendar app is given in Table 1.

Table 1. Example for User requirements [17]
Full size table

Starting with these properties required, a synthesis step is conducted to define characteristics of the resulting user interface (Fig. 8).

Fig. 8.
figure 8

Synthesis step example

Full size image

The next step is the selection of a suitable analysis procedure for the respective maturity level and scope. In this example, a usability test was assumed. The result for each property is compared with the corresponding user requirement (Fig. 9).

Fig. 9.
figure 9

Analysis step example

Full size image

The last step Overall Evaluation checks whether the properties fulfill the user-requirements adequately and which step of the UCD is the next (Fig. 10).

Fig. 10.
figure 10

Overall evaluation example

Full size image

In ongoing studies, the design and development of IOT devices, as well as the limitations and benefits of the proposed combination of CPM/PDD and human centred design are investigated. As this example illustrates, the complexity of the presentation quickly becomes quite high. Depending on the application, a problem in a real development project will not be realizable without software support. In addition, parts of the CPM model described in Chap. 1.2 have not been considered in this example. These are the external conditions and dependencies, for example.

7 Conclusion and Future Work

This paper offers a first exploration of the application of CPM/PDD to the UCD process. It has shown that the two approaches can be combined very well. However, there is no one to one mapping since the approaches have different focal points. But this feature results in the strength of the combination. UCD focuses on the process of analysing users and determination of user-needs. CPM/PDD provides a clear framework for the evaluation part and process control. In this way, the method may be helpful to the practice development process of human computer interfaces.

The combination of UCD and CPM/PDD can support the collaboration in interdisciplinary development teams (e.g. mechanical engineering, software engineers, UX designer) by driving the process through customer requirements. In future work it may be the starting point for the development of interdisciplinary products like IoT devices.

The mapping of the models offers among other things the possibility to carry out a structured allocation of supporting tools and metrics in the design process.

Identifying and evaluating suitable user requirements is the central strength of the user-centered approach. On that basis, specific methods for the relations synthesis and analysis can be proposed via CPM/PDD. The preparation of catalogues and tables to support the process is part of current research. A very promising use is the integration of the UX Metrics Table as analysis tool, presented in [18].

The development of software support for mapping the UCD process in combination with CPM/PDD is also currently being investigated and pursued.

Last but not least, this modeling of the process provides a very good preparation for the application of deep learning algorithms and artificial intelligence to the design process.