UX at the Right Level

1 Introduction

In the digital age, software is increasingly becoming a socially and economically formative factor [35]. The success of a software solution is substantially defined by its use. A good user experience (UX) [42] of human-machine interfaces is therefore indispensable. In the business environment, this applies both to the user group of the end customer as well as to the employees of the same company. Under the term “employee experience”, there is a currently growing discourse regarding the necessity of positive experiences with human-machine interfaces for employees [15]. In addition, new interaction concepts such as “Digital Companion^[1]” [2] or “Digital Twin^[2]” [52] promise new beneficial forms of human-machine interaction within organizations. Overall, human-centered design^[3] (HCD) [26] appears essential for the implementation of successful solutions within this environment.

Many companies are now facing the challenge of establishing or expanding HCD and everyone is looking for the best way to describe how it works. However, every company structure, every project and also the people with their personal goals in the company are different, so there is no “right” approach on how a UX strategy should look like. Every project team must develop it for itself, so that everyone in the team stands behind it and endorses its implementation. Existing UX maturity models focus on the organizational level of a company. They lack the focus on an operative project level and thus do not take into account adequately the complexities of company structures affected by interdepartmental dependencies and influenced by subcontractors.

Larger companies, such as DB Systel, are striving for a UX maturity model that is oriented towards such an operational level and that can be applied to the diverse landscape of the most diverse projects. Therefore, such a model was developed in the company and is presented in this paper.

In the following sections we discuss current challenges of UX design in software development (section 2) and give an overview of existing maturity models concerning UX, usability or HCD and summarizes its limitations (section 3). Afterwards we introduce our approach of a project focused UX maturity model, describing its development, the specified UX capabilities as well as its purpose of use and evaluation (section 4). Finally, we reflect on limitations of our model (section 5) and suggest directions for future work that might extend as well as improve the current model (section 6), before we end with a final conclusion (section 7).

2 Challenges of UX Design in Software Development

When it comes to software, HCD takes place in a context that has evolved significantly over the last twenty years in three aspects that are closely interwoven. First of all, the aspect of agility^[4] [16], which is particularly helpful in dealing with complex problems (“wicked problems” [47]). Then the aspect of continuity^[5] [33], which has a massive impact on time-to-market [13]. And finally, the Lean^[6] aspect [50], which aims to avoid wasting resources.

In the past, the conception of software solutions was strongly influenced by the attempt to collect all requirements upfront and then develop a solution. In practice, however, it has been shown that especially complex challenges cannot be specified in advance by means of requirements. It is rather the case that the requirements can only be clarified by dealing with concrete solutions [40]. A good design-oriented conception process therefore becomes a critical success factor [19] and the role of requirements engineering is shifting from problem description to the promotion of a shared understanding of the problem solution [23].

To promote good UX of the design object, HCD is an important factor in software engineering. However, for HCD to be fully effective in software engineering, it must be optimally integrated [21]. It should support the agile attitude, the continuous delivery of results and make its contribution to avoid waste like unfinished work, relearning or defects. Pragmatic approaches to this are discussed under the keyword “continuous UX” [25], [38]. A strong plea for a holistic conceptual approach has been formulated by representatives of requirements engineering, software architecture and UX design. The result was published as a role ideal for a digital designer by the German IT industry association BITKOM [1].

In practice, however, the question currently arises as to how a good UX can be effectively promoted in the situational environment described.

Basically, there are two levels of control that can be applied. On the one hand, there is the organizational level and on the other hand the project level [36]. Two essential tools for management are firstly processes and secondly maturity with regard to certain capabilities. Process Reference Models usually provide the basis for defining capabilities and maturity levels [28]. The two central steps for managing, involving different stakeholders, are planning, i. e. appropriate scoping, and execution, i. e. controlling and identification of optimization potentials [36].

As part of a strategic IT program of Deutsche Bahn, there was a need to provide concrete support for projects in order to adequately plan for capabilities that promote the design of digital solutions with a good UX. For this purpose, the existing approaches were first examined and finally, a theoretically well-founded model was developed from a practical, applied perspective. The goal was to operationalize a group-wide Enterprise Architecture Principle for the HCD of systems, formulated in the sense of the TOGAF standard [44].

3 Existing Approaches for UX Maturity Models

Maturity models in the field of usability and UX are not a new idea. In the 1990s, numerous models were developed by various companies and universities. Some of the first models included the Usability Leadership Maturity Model from IBM [14], Trillium from Bell Canada [53], User Centered Design Maturity from Loughborough University [12] or the Human Ware Process Assessment model from Philips [24]. The Usability Maturity Model was also developed at a very early stage by Jonathan Earthy [11] who had a major influence on the topic of usability and HCD. Other contributors from the UX community followed with further approaches. In 2006, Jakob Nielsen published his “Corporate Usability Maturity” model [41] and Jared Spool his “UX Strategy Playbook” [51].

In 2000, the issue of maturity was addressed in two standards, ISO/TR 18529 [31] and ISO/TS 18152 [30], which have been withdrawn and merged into ISO 9241-220 [27]. ISO 9241-220 refines the HCD framework of ISO 9241-210 [26] by so-called base practices. All three norms tie in with established maturity models from software engineering, such as the Capability Maturity Model Integration (CMMI) [5] and ISO/IEC 15504 [29], also known as Software Process Improvement and Capability Determination (SPICE). In the German-speaking world, there is also the DIN SPEC 92412 [8], which originates from the former DAkkS ‘Leitfaden Usability’ (en. Guideline on Usability) and that aims at the usability assessment of a product.

In 2010, Jokela [34] classified existing UX maturity models and described four categories of models:

1. Standard process assessment models: This category refers to models that are based on those of software engineering, e. g. the ISO standards.

2. Non-standard models: In this category Jokela includes models that examine processes without a standardized procedure.

3. Generic models: In addition to the process aspect, generic models also consider aspects of management awareness and the position of usability in the company.

4. Specific models: These are models that have a very specific and therefore limited focus.

The topic of maturity can refer to different levels in a company: organization, team and product. Models that are aimed at an all-encompassing strategic organizational level usually address the general development of a culture in which HCD should be manifested and lived across all areas of the company. Models that are designed for a product team, on the other hand, focus on the process between the team members and the existing competence with regard to HCD so that a usable product can be developed. Models that are based on the product level measure the specific maturity of the product itself.

Comparing all these existing models, it becomes clear that larger companies with a complex structure as characterized by multiple different internal stakeholder teams or departments working together (e. g. specialist departments, IT infrastructure, software development, legal department, etc.) and the additional involvement of subcontractors are not taken into account by these models.

Nowadays, existing maturity control tools, which are intended to support the conception of solutions with a good UX, are primarily aimed at an all-encompassing organizational level, with few exceptions. Furthermore, an approach at the organizational level seems impossible without a strategic orientation and the commitment from the top management of the company. Therefore, we see a strong need to appropriate a UX maturity model to the project-level. After all, it plays an important role in the planning of the project and needs to be monitored during project execution. This initiated the in-house development of a UX maturity model, which is presented in the following.

4 Project UX Maturity Model (PUXMM)

4.1 Development

When developing the PUXMM in-house for product development, the first step was to create an understanding of the potential area of application for the model. For this purpose, a simple typology of existing software systems within Deutsche Bahn was set up.

In the next step, the HCD framework [26] was chosen as a Process Reference Model [10]. It provided the theoretical basis for defining the required capabilities. For further structuring, the so called ‘Elements of User Experience’ [18], which have been established in practice for many years, were used. The framework focuses on the three phases understanding, designing and evaluating [7], which were already established in the HCD mindset of the Deutsche Bahn. In our view, the decision not to represent the specification of requirements as a separate phase offers the advantage of promoting a more design-oriented understanding of the concept instead of seeing the requirements specification as a stage-gate [6].

In addition to the three capability areas for understanding, designing and evaluating, a management area was defined for the overall, cross-sectional control. Furthermore, a capability area “continuity” was defined to maintain or increase the UX quality achieved throughout the entire product life cycle.

The maturity levels were defined based on common software capability/maturity models [45].

Then 41 associated capabilities were defined and described from a UX expert perspective. A starting point for defining these capabilities was the checklist for calculating the “project usability quotient” by Schaeffer and Lahiri [49].

Figure 1

Overview of UX capabilities in the PUXMM.

Figure 2

Description of a UX capability in the PUXMM.

Figure 3

Overview of the UX maturity levels in the PUXMM.

5 Limitations

So far, the PUXMM has proven to be a pragmatic tool to adequately plan for UX capabilities and promote the design of digital solutions with a good UX. However, there are also some limitations that can be seen as possible incentives for further improvement.

First of all, the PUXMM does not explain how the capabilities are mapped to the specific development process. Thus, there is a need to integrate the capabilities into a project-specific process model on the basis of a general development model [54].

In addition, the model has no direct effect on the real executed quality of the required capabilities. A process and capability assessment cannot substitute a basic design competence, which can be described as a closely interwoven cycle of perception, thinking and expression [17]. Such an assessment can only be performed by experienced UX professionals.

6 Future Directions

A further evolutionary leap could be the expansion of content to a holistic concept-capability model in the sense of digital design [39], which integrates the perspectives of business, people and technology [3]. Each perspective can thereby contribute a particular framing [9], i. e. its respective view of the problem and thus implicit ideas for solutions, at an early stage. In this way, the current conception process, which can be described as crisis-ridden and is characterized above all by dangerous simplifications with regard to the aspects of design thinking, user-centricity, and product experience [20], could be improved.

Using the model in the development of artificial intelligence-based solutions, adjustments would have to be made to the capabilities, since special aspects (such as the difficulty to prototype AI behavior or explaining AI system evolvement over time to users) have to be taken into account in human-computer interaction [55].

A further application-oriented adjustment could be the definition of an actionable kernel as defined for software engineering [32]. Such a kernel describes the following universal aspects: 1.) alphas as essential things you always work with, 2.) competencies as essential capabilities required and 3.) activity spaces as essential things to do [43]. Thus, the pure capabilities are put into a context that allows teams to manage a software development endeavor well on their own.

7 Conclusion

In conclusion, we would like to state that the PUXMM approach in its current form can already be of great benefit in practice. It has already proven itself in practice for planning and monitoring UX capabilities. Thus, the PUXMM closes the current gap in terms of a UX maturity model on the project level. From our practical point of view, the PUXMM represents a major step forward by integrating a HCD approach into the development of digital solutions. At the same time, it provides starting points for possible extensions, such as the fundamental orientation towards a holistic concept-capability model that goes beyond the HCD approach. We would be pleased if these could perhaps be advanced in the future through close interaction of practice and theory. In this regard we see the theoretical work of Suzanne Kieffer et al. [37] as a promising approach.