Usability and user experience maturity models are used to evaluate the capabilities of an organization in order to provide an assessment of their ability to develop usable products. But, as the main focus of such models is on an all-encompassing organizational level, they are difficult to implement in more complex organizations with a wide range of diverse and interlinked projects.
This paper presents a project related UX maturity model, which was developed at DB Systel to address this issue: the PUXMM. It takes into account the nested internal customer relationships between departments and subcontractors and applies a human-centered design approach. There are two practical application scenarios for the PUXMM. It can be used to determine the UX maturity level of an ongoing project and as checklist to align a project to a desired maturity level from the outset.
In the digital age, software is increasingly becoming a socially and economically formative factor . The success of a software solution is substantially defined by its use. A good user experience (UX)  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 . In addition, new interaction concepts such as “Digital Companion”  or “Digital Twin”  promise new beneficial forms of human-machine interaction within organizations. Overall, human-centered design (HCD)  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 , which is particularly helpful in dealing with complex problems (“wicked problems” ). Then the aspect of continuity , which has a massive impact on time-to-market . And finally, the Lean aspect , 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 . A good design-oriented conception process therefore becomes a critical success factor  and the role of requirements engineering is shifting from problem description to the promotion of a shared understanding of the problem solution .
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 . 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” , . 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 .
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 . 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 . 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 .
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 .
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 , Trillium from Bell Canada , User Centered Design Maturity from Loughborough University  or the Human Ware Process Assessment model from Philips . The Usability Maturity Model was also developed at a very early stage by Jonathan Earthy  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  and Jared Spool his “UX Strategy Playbook” .
In 2000, the issue of maturity was addressed in two standards, ISO/TR 18529  and ISO/TS 18152 , which have been withdrawn and merged into ISO 9241-220 . ISO 9241-220 refines the HCD framework of ISO 9241-210  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)  and ISO/IEC 15504 , also known as Software Process Improvement and Capability Determination (SPICE). In the German-speaking world, there is also the DIN SPEC 92412 , 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  classified existing UX maturity models and described four categories of models:
Standard process assessment models: This category refers to models that are based on those of software engineering, e. g. the ISO standards.
Non-standard models: In this category Jokela includes models that examine processes without a standardized procedure.
Generic models: In addition to the process aspect, generic models also consider aspects of management awareness and the position of usability in the company.
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)
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  was chosen as a Process Reference Model . It provided the theoretical basis for defining the required capabilities. For further structuring, the so called ‘Elements of User Experience’ , which have been established in practice for many years, were used. The framework focuses on the three phases understanding, designing and evaluating , 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 .
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 .
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 .
In order to be able to make as clear a statement as possible about responsibilities despite the most varied project constellations, the PUXMM only makes a very general distinction between the demand and supply sides:
The demand side includes individuals or groups who initiate the project on the basis of their needs and benefit directly from the project result.
The supply side (or the supplier) includes all other individuals or groups that contribute to the creation of the project result. This division can be applied regardless of how many individuals, groups or organizations are involved or how their service relationships are structured.
The demand side is responsible during problem analysis, project initiation, solution selection, and use of the solution.
The supply side is responsible during its design, implementation, and testing.
The model assumes that the supply side develops UX capabilities before the demand side gradually recognizes their value and accepts and finances the use of the capabilities. Therefore, UX capabilities tend to be associated with higher levels of UX maturity than those on the supply side.
The PUXMM is based on a simple project phase model:
Project initiation – rough conception – detailed conception – implementation – test
It assumes that UX capabilities are first applied in implementation, especially in visual design. As they mature, project teams then look at UX aspects in ever earlier phases and can thus positively influence the UX of their product more holistically. This is why UX capabilities for a higher level of UX maturity are assigned to earlier than later project phases.
4.3 UX Capabilities
As described above, the model is divided into five capability areas:
Project Management: Planning resources like time and staff.
Understand: Context of use analysis and the definition of user requirements.
Create: Conception, prototyping and UI design.
Evaluate: Gathering feedback and iterating the solution.
Continuity: Measuring the project success and reuse content for further projects.
As a prerequisite for a maturity level, each skill was assigned a skill level and described in more detail and illustrated by an example (see Figure 2).
The five plus one specified maturity levels are (Figure 3):
Level 1: UX Awareness The project team thinks about the users of the planned project result. The term UX is familiar to the project team.
Level 2: Accepted UX The project team uses some basic UX methods.
Level 3: Selective UX The project team specifically uses appropriate UX methods to avoid business-relevant usage problems and the most important usage problems of employees.
Level 4: Controlled UX The project team makes targeted use of UX methods to provide users with a UX that matches the strategic overall picture of the group company.
Level 5: Full UX For each UX method, the project team consciously evaluates whether its application in the given project can improve the UX and uses each one with positive results.
+ Level: Continuity The project team introduces a continuous measurement of UX beyond the end of the project and documents the UX findings in a comprehensible and searchable way for use and maintenance in the maintenance phase.
4.4 Purpose of Use
On the one hand the PUXMM offers the possibility to determine the UX maturity level of an ongoing project, and on the other hand it can be used as a checklist to align a project to a desired maturity level from the outset.
In order to allow pre-testing and control, the PUXMM requires that the individual capabilities are scheduled accordingly. It also assumes that they are used appropriately within the project. This is the only way it will reach the desired or established level of maturity.
The model does not make any assumptions about whether the capabilities are implicitly anchored as part of a standardized procedure or explicitly appear in a “plan”, e. g. a simple to-do list, a detailed project plan, a rolling backlog and other measures for documentation and implementation.
The PUXMM has so far been used within Deutsche Bahn mainly for monitoring the UX maturity level of single projects. The monitoring was usually carried out by UX consultants together with product owners or project managers or those responsible for the functional conception. Another use case was the comparative evaluation of all digital service products within a department of Deutsche Bahn.
At the ‘Mensch und Computer’ Conference 2019  the PUXMM was discussed and evaluated in a workshop with UX experts. The participants were divided into several small groups and were given the task to assign the 41 capabilities to the five maturity levels. Significant deviations to the defined categorization were subsequently discussed, and an adjustment was made. In addition, descriptions that were ambiguous for the participants were revised and reformulated accordingly. Based on the feedback received so far, four smaller iterations of the initial model design were carried out.
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 .
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 . 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 , which integrates the perspectives of business, people and technology . Each perspective can thereby contribute a particular framing , 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 , 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 .
A further application-oriented adjustment could be the definition of an actionable kernel as defined for software engineering . 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 . Thus, the pure capabilities are put into a context that allows teams to manage a software development endeavor well on their own.
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.  as a promising approach.
About the authors
David Gilbert has worked in various operational and strategic Digital Design roles since 2007. Until 2015, he worked for various design studios. The projects he has worked in have received over 25 international and national design awards. – Since 2015 he is working in the IT department of the Deutsche Bahn Group, where he holds the role of Chief Architect User Experience at the intersection of classic system-oriented and user-oriented software conception. He is a member of the International Requirements Engineering Board and was a founding member of the Digital Design working group in Bitkom. Since 2011 he is a lecturer in UX Design at the RheinMain University of Applied Sciences.
Holger Fischer has been working in the field of Usability & User Experience for about 12 years. Since January 2019 he is a Principal UX Consultant at eresult GmbH, advising clients on UX strategy, introducing human-centered design mindsets in companies and coaching UX in usability and design thinking trainings. Before joining eresult, he worked as a researcher at the Paderborn University in the Software Innovation Lab (SI-Lab), the Software Quality Lab (s-lab) and in the Cooperative Computing & Communication Lab (C-LAB). Within the scope of research and industrial projects he introduced usability activities in companies and accompanied them during the elicitation of user requirements and the implementation of initial human-centered projects. Furthermore, he is involved in the board and as a working group leader in the German UPA e. V. and is a founding member of the UXQB e. V.
Dirk Röder has been working in the field of business software design for 25 years and is a long-time trainer for software design & consulting. He is currently a Strategic Business Engineering Consultant in the IT department of the Deutsche Bahn Group. He studied computer science at the TU Clausthal, with focus on database systems and has a broad and deep knowledge in the areas of structured system analysis, system modeling and enterprise architecture management. He also supports the Digital Design working group of the international requirements engineering board.
At this point we would like to thank especially Torsten Michelmann, Sascha Eckart and Thorsten Riehn. Without their support the creation of this model would not have been possible.
 Bitkom (2017). Bitkom Role Model “Digital Design” – Successful digitalization and digital transformation require a rethink in software development. https://www.bitkom.org/noindex/Publikationen/2017/Leitfaden/20171208-rolemodel-digital-design.pdf, last accessed 2019/12/22.Search in Google Scholar
 Biundo, S., Höller, D., Schattenberg, B., & Bercher, P. (2016). Companion-technology: an overview. KI – Künstliche Intelligenz, 30(1), 11–20.Search in Google Scholar
 Brown, T., & Katz, B. (2011). Change by design. Journal of Product Innovation Management, 28(3), 381–383.Search in Google Scholar
 Carvajal, C. L., & Moreno, A. M. (2017, October). The maturity of usability maturity models. In: International Conference on Software Process Improvement and Capability Determination (pp. 85–99). Springer, Cham.Search in Google Scholar
 CMMI Institute (2020). Capability Maturity Model Integration (CMMI) v2.0. https://www.cmmiinstitute.com/cmmi (last reviewed: July 27, 2020).Search in Google Scholar
 Cooper, R. G. (1990). Stage-gate systems: a new tool for managing new products. Business Horizons, 33(3), 44–54.Search in Google Scholar
 Diefenbach, S., & Hassenzahl, M. (2017). Psychologie in der nutzerzentrierten Produktgestaltung. Springer Berlin Heidelberg.Search in Google Scholar
 DIN SPEC 92412 (2015). Ergonomics of human-system interaction – Auditing procedure for the development of interactive products based on DIN EN ISO 9241-210.Search in Google Scholar
 Dorst, K. (2011). The core of ‘design thinking’ and its application. Design Studies, 32(6), 521–532.Search in Google Scholar
 Dubberly, H. (2004). How do you design. A compendium of models.Search in Google Scholar
 Earthy, J. (1998). Usability Maturity Model: Human Centredness Scale: INUSE Project Deliverable D5.1.4 (s) Version 1.2. Technical report, Llyod’s Register, 71 Fenchurch St, London, EC3M 4BS.Search in Google Scholar
 Eason, H. (1997) User Centred Design Maturity. Internal Working Document. Technical report, Department of Human Sciences. Loughborough University.Search in Google Scholar
 Fitzgerald, B., & Stol, K. J. (2017). Continuous software engineering: A roadmap and agenda. Journal of Systems and Software, 123, 176–189.Search in Google Scholar
 Flanaghan G. A. (1995). IBM Usability Leadership Maturity model (self-assessment version). In: I. Katz, R. Mack, L. Marks, M. B. Rosson & J. Nielsen (eds.), Proceedings of CHI’95: Human Factors in Computing Systems. ACM Press.Search in Google Scholar
 Johnson, D., Stern, S. et al. (2017). The Employee Experience Imperative. The Experience Factors that Matter Most to Employees – and How to Improve Them. Forrester.Search in Google Scholar
 Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28–35.Search in Google Scholar
 Gänshirt, C. (2012). Tools for ideas: Introduction to architectural design. Walter de Gruyter.Search in Google Scholar
 Garrett, J. J. (2010). The elements of user experience: user-centered design for the web and beyond. Pearson Education.Search in Google Scholar
 Gilbert, D. (2020). Design-driven Development und Requirements Engineering. Objektspektrum, 04.Search in Google Scholar
 Gilbert, D. (2019). The concept in crisis. Designreport, 02.Search in Google Scholar
 Gilbert, D. (2018). Digitales Design als Update der “klassischen” Softwareentwicklung. In Denzinger, J. (ed.) Das Design digitaler Produkte: Entwicklungen, Anwendungen, Perspektiven. Birkhäuser.Search in Google Scholar
 Gilbert, D., Röder, D., & Fischer, H. (2019). UX auf dem richtigen Level! // UX-Fachkompetenz mittels Reifegradmatrix für Projekte & Produkte angemessen einplanen. Mensch und Computer 2019 – Usability Professionals.Search in Google Scholar
 Glinz, M., & Fricker, S. A. (2015). On shared understanding in software engineering: an essay. Computer Science – Research and Development, 30(3-4), 363–376.Search in Google Scholar
 Gupta, A. (1997). The Humanware Process Improvement Framework: Interfacing User Centred Design and the Product Creation Process at Philips.Search in Google Scholar
 Immich, T. (2018). Continuous UX – “Lean” und “Large” unter einem Dach. Mensch und Computer 2018 – Usability Professionals.Search in Google Scholar
 ISO 9241-210 (2019). Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems.Search in Google Scholar
 ISO 9241-220 (2019). Ergonomics of human-system interaction — Part 220: Processes for enabling, executing and assessing human-centred design within organizations.Search in Google Scholar
 ISO/IEC 15504-2 (2003). Information technology — Process assessment — Part 2: Performing an assessment.Search in Google Scholar
 ISO/IEC 15504-5 (2012). Information technology — Process assessment — Part 5: An exemplar software life cycle process assessment model.Search in Google Scholar
 ISO TS 18152 (2010). Ergonomics of human-system interaction — Specification for the process assessment of human-system issues.Search in Google Scholar
 ISO/TR 18529 (2000). Ergonomics — Ergonomics of human-system interaction — Human-centred lifecycle process descriptions.Search in Google Scholar
 Jacobson, I., Ng, P. W., McMahon, P. E., Spence, I., & Lidman, S. (2012). The essence of software engineering: the SEMAT kernel. Communications of the ACM, 55(12), 42–49.Search in Google Scholar
 Johanssen, J. O., Kleebaum, A., Paech, B., & Bruegge, B. (2018, May). Practitioners’ eye on continuous software engineering: an interview study. In: Proceedings of the 2018 International Conference on Software and System Process (pp. 41–50).Search in Google Scholar
 Jokela, T. (2010). Usability maturity models: making your company user-centered. User Experience Magazine, 9(1).Search in Google Scholar
 Kelly, K. (2017). The inevitable: understanding the 12 technological forces that will shape our future. Penguin.Search in Google Scholar
 Kieffer, S., Rukonić, L., de Meerendré, V. K., & Vanderdonckt, J. (2019, February). A process reference model for UX. In: International Joint Conference on Computer Vision, Imaging and Computer Graphics (pp. 128–152). Springer, Cham.Search in Google Scholar
 Kieffer, S., Rukonic, L., de Meerendré, V. K., & Vanderdonckt, J. (2019). Specification of a UX process reference model towards the strategic planning of UX activities. In: VISIGRAPP (2: HUCAPP) (pp. 74–85).Search in Google Scholar
 Kuusinen, K. (2015, September). Continuous user experience development. In: INTERACT 2015 Adjunct Proceedings: 15th IFIP TC. 13 International Conference on Human-Computer Interaction, 14–18 September 2015, Bamberg, Germany (Vol. 22, p. 233). University of Bamberg Press.Search in Google Scholar
 Lauenroth, K., Bramsiepe, H., Gilbert, D., Hartwig, R., Lehn, K., Schubert, U., Trapp, M. (2018). Das Digital-Design-Manifest. www.digital-design-manifest.de.Search in Google Scholar
 Lauenroth, K., Schreiber, F., & Schreiber, F. (2016). Maschinen-und Anlagenbau im digitalen Zeitalter: Requirements Engineering als systematische Gestaltungskompetenz für die Fertigungsindustrie Industrie 4.0. Beuth Verlag.Search in Google Scholar
 Nielsen, J. (2006). Corporate UX Maturity. https://www.nngroup.com/articles/ux-maturity-stages-1-4/ (last reviewed: July 27, 2020).Search in Google Scholar
 Norman, D., & Nielsen, J. (2016). The definition of user experience (UX). Nielsen Norman Group Publication, 1.Search in Google Scholar
 Object Modelling Group (2018). Essence Specification Version 1.2. https://www.omg.org/spec/Essence/About-Essence/.Search in Google Scholar
 Open Group (2018). The TOGAF® Standard, Version 9.2.Search in Google Scholar
 Paulk, M. C., Curtis, B., Chrissis, M. B., & Weber, C. V. (1993). Capability maturity model, version 1.1. IEEE Software, 10(4), 18–27.Search in Google Scholar
 Peres, A. L., et al.(2014) AGILEUX model: towards a reference model on integrating UX in developing software using agile methodologies. In: 2014 Agile Conference, AGILE 2014, pp. 61–63.Search in Google Scholar
 Rittel, H. W., & Webber, M. M. (1973). 2.3 planning problems are wicked. Polity, 4(155), e169.Search in Google Scholar
 Salah, D., Paige, R., & Cairns, P. (2016). A maturity model for integrating agile processes and user centred design. In: International Conference on Software Process Improvement and Capability Determination. Springer International Publishing.Search in Google Scholar
 Schaffer, E., & Lahiri, A. (2013). Institutionalization of UX: a step-by-step guide to a user experience practice. Addison-Wesley.Search in Google Scholar
 Sedano, T., Ralph, P., & Péraire, C. (2017, May). Software development waste. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE) (pp. 130–140). IEEE.Search in Google Scholar
 Spool, J. (2019). Driving Product Teams to Become More Design Mature. https://articles.uie.com/driving-product-teams-to-become-more-design-mature/ (last reviewed: July 27, 2020).Search in Google Scholar
 Tao, F., Sui, F., Liu, A., Qi, Q., Zhang, M., Song, B., Guo, Z., Stephen C.-Y. Lu, & Nee, A. Y. C. (2019). Digital twin-driven product design framework. International Journal of Production Research, 57(12), 3935–3953.Search in Google Scholar
 Trillium (1994). Model for Telecom Product Development & Support Process Capability, Technical Report, Bell Canada.Search in Google Scholar
 VDI (2019). VDI 2221 Part 1 Design of technical products and systems – Model of product design.Search in Google Scholar
 Yang, Q., Steinfeld, A., Rosé, C., & Zimmerman, J. (2020, April). Re-examining whether, why, and how human-AI interaction is uniquely difficult to design. In: Proceedings of the 2020 Chi Conference on Human Factors in Computing Systems (pp. 1–13).Search in Google Scholar
© 2021 Walter de Gruyter GmbH, Berlin/Boston