User-Centred Design without Involving Users: A Longitudinal Case Study in a Human-Centred-Design–Mature Company

Abstract

Human-centred design has grown into a widely applied field that has produced a large number of standards, methods and guidelines for designing meaningful and usable products and services and direct contact to users seems to define whether a project is considered human-centric or not. However, as the field has grown more mature, companies have also matured in human-centredness, and thus, they have already accumulated user knowledge and may not need to start from the beginning in each project. This paper presents a case study of a human-centred-design–mature company, where first-hand access to users was blocked due to confidentiality. The project team had to rely on other sources of user knowledge. They utilized user representations that were based on earlier user studies and other sources, and the company also employed in-house users who gave their input in the product development process. Together these resulted in a successful design project.

Keywords:

• human-centred design
• user representations
• product design
• HCD maturity
• user research
• user-centred design
• methods

Introduction

Human-centred design (HCD) has grown into a widely applied field that aims to develop products, services and systems that are easy to use, meaningful and provide pleasure for people (van der Bijl-Brouwer and Dorst 2017). It has emerged during recent decades from several fields including ergonomics, participatory design, computer science, marketing, anthropology and sociology (van der Bijl-Brouwer and Dorst 2017; Giacomin 2014). The basis of HCD provides guidelines and methods for designing products and services (ISO 9241-11 1998; Hackos and Redish 1998; Hollingsed and Novick 2007; Nielsen 1993; Norman and Draper 1986).

The HCD recommendations for methods and processes stress the deployment of user studies and testing in all projects and first-hand contact to users can been considered to define whether a project is human-centred or not (ISO_9241-210 2019), although some methods such as personas (Miaskiewicz and Kozar 2011) and user stories in agile methods (Da Silva et al. 2011) are rather based on representations of users instead of direct contact with them. However, what should be noted is that today, as HCD has been practiced for some decades, HCD mature companies seldom rely on single methods or single sources of user representations and they occasionally run projects with no access to external users (Johnson et al. 2014). Although HCD recognizes only few ‘official’ methods without direct contact to users, this does not cover all the ways HCD mature companies handle the challenge of managing design without first-hand access to users. Furthermore, to define an organization’s or project’s human-centredness based on solely first-hand contact to users does not seem to reflect how HCD is practiced ‘in the wild’. Several studies addressing design and HCD methods in real-life settings have emerged that indicate that there is a gap between the academic frameworks and real-life development projects (Wilkinson and De Angeli 2014; van der Bijl-Brouwer and Dorst 2017; Schønheyder and Nordby 2018; Oygür 2018).

Although the maturity level of HCD in companies has increased and numerous methods for gaining user input exist, there are several reasons why companies run projects with no direct contact to users: there might not be enough resources for user involvement, the confidentiality level is too strict to allow external participation or contact with the customers might be blocked (Eshet and Bouwman 2016). How do the high-maturity–level organizations then manage in these situations as they are not trying to avoid user involvement but instead want to design a successful product or service in a human-centred way? This leads to the research questions of this paper:

How can HCD be applied if direct user involvement is not possible? How can it still be recognized as HCD?

In this paper I present a case study of an HCD-mature industrial company with a high focus on design and user-centeredness. The company applies a quite comprehensive methods set for gaining user knowledge and input into their product development. However, in this studied case, the employees participating in the project were designing a new type of device and, due to a high secrecy level defined by the top management, could not involve any external users. The project team still managed to apply HCD and design a great product.

HCD in company contexts

The strongest marker of HCD is continuous attention to users throughout the design process (ISO 9241-11 1998) and the involvement of real people (the actual or prospective users) in the process. There are several guidelines, processes and standards defined for this purpose (ISO 9241-11 1998; Nielsen 1993; ISO_9241-210 2019). These guidelines have some differences but they roughly involve the following phases: initial user research, product development, validation with the users and iteration (Nielsen 1993; ISO_9241-210 2019). The emphasis here is that the research is conducted with actual users, real people, instead of just designing for the people based on designers’ or marketing assumptions (Hyysalo and Johnson 2015; Woolgar 1991). However, as HCD has been practiced for some decades now, companies are very seldom in contact with their users for the first time during a project; instead, they have already accumulated significant amounts of information about their users prior to the ongoing project (Hyysalo and Johnson 2015; Solano et al. 2016; Woolrych et al. 2011; Savolainen and Hyysalo 2020). Some companies have also hired users into their R&D organization to participate in the development projects (Kotro 2005; Schweisfurth and Raasch 2015), which was also the case in the studied company. Furthermore, the HCD maturity levels of many companies have increased from the initial days of HCD. Today HCD is regularly applied whereas some decades ago, HCD methods and approaches were only being introduced to companies (C. Gray 2016; Marti and Bannon 2009; Johnson 2013; Johnson et al. 2014). Thus, more effort should be placed on understanding how user information is actually gathered and utilized in HCD-mature companies in order to better target these types of organizations. These above-mentioned issues boil down to the actual research methods utilized in companies and how are they used in practice.

During recent decades, HCD has introduced numerous methods for gathering user insights and involving users during product and service design processes (Hackos and Redish 1998; Hollingsed and Novick 2007; Nielsen 1993). During this time, these methods have been developed, evaluated and compared by a number of studies (Gray and Salzman 1998; Nielsen and Phillips 1993). However, during the past decade, criticism has emerged towards this methods-oriented approach (Woolrych et al. 2011; Cole 1996; Kuutti 1996; Johnson et al. 2014). The criticism has been manifold: on the one hand, it reveals a potential problem with the reliability of HCD methods as some of the comparisons have resulted in conflicting results (Gray and Salzman 1998; Hornbaek 2010; Woolrych et al. 2011; Gray 2016). On the other hand, it questions the usefulness of developing and evaluating single methods and projects as, in real life, companies tend to mix methods instead of relying on the use of a single method, and they run several projects in parallel (Johnson et al. 2014; Solano et al. 2016; Woolrych et al. 2011; Kotro 2005; Wardlaw 2016; Cole 1996; Kuutti 1996). This development suggests that the orientation of HCD research should move towards inspecting larger HCD entities and contexts. In this task, we can be supported by considering two aspects of HCD: user representations and a better understanding of the HCD maturity levels of companies.

User knowledge in science and technology studies

There are neighbouring fields that have studied the practices of designing new products and services and from which HCD can learn. Science and technology studies (STS) is a multidisciplinary field that addresses how science and technology are constructed (Sismondo 2008). It has an interest in users and how they consume and shape technologies (Oudshoorn and Pinch 2003) and a long history of studying the users with qualitative ethnographic methods (Mäkinen, Hyysalo, and Johnson 2019).

When studying how a company knows its users or how user information is included in the design process, we can utilize the notion of user representations from STS. During the design process the user is always represented as a separation from the real-use situations (Silvast et al. 2018; Hyysalo and Johnson 2015). The user representations can be of various types and sources (Akrich 1995; Hyysalo and Johnson 2015). A rougher separation divides the sources into implicit or explicit sources, with implicit sources being grounded on the designer’s experience and explicit sources being grounded on conducted studies or reports (Akrich 1995). Hyysalo and Johnson (2015) defined this further, differentiating eight categories of sources for user representations which highlight that the user representations are actually based on quite versatile sources. During the design process, the designers and developers need to use various bits of information to construct the user representations (Williams, Stewart, and Slack 2005; Oygür 2018). The construction of user representations includes the sources for user knowledge, how the information is stored and how it is developed and utilized (Oygür 2018). These provide an additional way of studying how the designers know their users and how user information is used during design processes.

Evaluating HCD maturity

HCD literature suggests several ways for evaluating a company’s maturity or capability level in HCD or related fields (such as usability and user-centred design [UCD]). Research suggests at least 15 different models for assessing a company’s HCD or UCD level (Lacerda and von Wangenheim 2018; Jokela 2004). One of the earlier models that has been developed is the Human-Centeredness Scale (Earthy 1998), which includes five levels for evaluating the maturity of a company’s human-centeredness, with level E being the highest and level A the lowest (Earthy 1998). The model provides a guided way to assess the maturity internally or by interviewing the relevant people inside the company. As a result, the company can see what level it is at in terms of HCD activities and how it can develop into a more human-centric organization. These models can also help to identify whether a company is applying HCD in its activities and, if so, to what extent.

This section has provided a summary of the literature related to HCD research in companies, including HCD methods and the evaluation of companies’ HCD maturity levels. It has also covered aspects of user knowledge in STS, especially user representations. In the next section I will describe both the research I have conducted and the case company, after which I will present the results of the study. This paper will end with the cross-cutting conclusions of the research.

The research methodology

My case study was conducted at a Finnish industrial company. Should be noted that I was only acting as an external researcher with no other relation to the company. For confidentiality reasons, the company will be called CompanyIM. CompanyIM offers a large variety of industrial solutions for a specific technology. Its customers are from a wide variety of markets, covering nearly the entire globe. CompanyIM’s products vary from simple machines to large-scale systems that incorporate automated machines and management software. In addition, they offer their customers training and consultation. CompanyIM has always had a strong focus on innovations and user-centeredness and has won several design and innovation prizes (including the Red Dot and iF design awards). On J. Earthy’s Human-Centeredness Scale (Earthy 1998), CompanyIM is on level C or D, also partly implementing level E. Despite this model being from the end of the 1990s, it was used in this case as it still provides a structured way to assess HCD maturity that takes into account different operational levels. Thus, these factors indicate that CompanyIM is well-established in design and has a strong background in HCD.

This research was carried out as a longitudinal qualitative study during 2014–2018 (Figure 1). The main research methods were semi-structured interviews and ethnographic meeting observations. In addition to the interviews conducted across the different parts of the organization, a single innovation project (ProjectND) was followed in more detail. The target of ProjectND was to create a battery-operated device as their previous devices had been wired. As user tests and user research with external participants were prohibited for this project, ProjectND had to rely solely on other sources for user insights and, thus, it acts as a demonstrative example of a project with no external user participation carried out in an HCD-mature company.

Figure 1. The timeline of the data gathering.

The research data consist of 37 interviews, 33 meeting observations and inspecting documentation from CompanyIM. The interviewees were selected by choosing representatives from different parts of the organization, interviewing the main participants of ProjectND and applying snowball sampling. The research data are described further in Figure 2 and provided a comprehensive data set for CompanyIM and ProjectND.

Figure 2. The collected research data.

The data comprises voice recordings, some video recordings, field notes, pictures and company documentation. Of these, the primary sources are the voice recordings and field notes. All of the voice recordings were transcribed, and Atlas.ti was used to code the transcriptions, which resulted in 65 thematic codes. The data analysis was based on grounded theory. Different information sources were analysed and cross-compared, and a case narrative was written based on the analysis. The transcriptions were annotated based on simplified Jefferson conventions (Jefferson 2004) although the study did not use fully fledged interaction or conversation analysis due to the long time spans of the ethnographic recordings.

Results

The results will first summarize the different sources for designing usage in ProjectND and then present how user insights are discussed in project meetings. In the end I will present a summary of the findings.

The sources of designing usage in ProjectND

As mentioned, ProjectND could not involve external users or customers. Thus, what was used during the project were user representations and relying on internal sources and accumulated knowledge. However, at company level, CompanyIM uses a wide range of methods. The method mix for ProjectND and the company-wide method mix are presented in Figure 3, where the categories for the method mixes are based on the work of Johnson et al. (2014) (Savolainen and Hyysalo 2020).

Figure 3. The method mixes for CompanyIM and ProjectND.

We can now examine closer the method mix of ProjectND and notice that there were no formal methods used in the project. This was not typical for the company, but since ProjectND was defined with a high confidentiality level, the project team had to utilize other methods for user insights. As the company has a high HCD maturity level, they have conducted numerous studies during earlier projects and the insights from those were utilized in ProjectND as well. In addition, several background sources (such as competitor analysis and trade shows) for ProjectND were applied. In particular, competitor analysis provided important insights considering this project as the device type was very new and there were only two competitor products with which to benchmark and provide requirement levels to meet or exceed (although, even though these two devices were battery-operated, they were still quite different from the one being designed). Thus, in the end, the methods used to gain user insight were actually quite diverse. These method mixes also provided sources for the user representations of the project.

Next, we shall move onto the user representations. Approximately 15 relevant user representations were identified in ProjectND. From these 15 user representations, five were seen as the most relevant: a worker up a mast, a worker with a van, a DIY person, an oil platform maintenance worker and a farmer. These representations and others that are derived from them, appear in the project meeting examples presented in the following section. The representations could be traced to the different sources of user representations defined by Hyysalo and Johnson (2015). These categories of user representations and how they appear in ProjectND are shown in Figure 4. This demonstrates how the different methods in CompanyIM link to the user representations in ProjectND. The method mixes and user representations are addressed in more detail in other articles (Savolainen and Hyysalo 2020, 2021).

Figure 4. The sources of user representations.

In addition, CompanyIM has a unique resource: in-house users. The in-house users are professionals who have worked for CompanyIM’s customers or similar sites and still, in their current position, use the machines produced by CompanyIM and its competitors daily. They conduct product testing and benchmarking, consultations for the customers and participate in product development. Thus, they have a very good understanding of using the products as well as the usage environments of CompanyIM’s customers. These can be compared to the hobbyists employed by the Finnish sports equipment manufacturer Suunto (Kotro 2005) or the embedded lead users in the mountaineering industry (Schweisfurth and Raasch 2015).

How is the design of use realized in practice without access to users? Examining a project meeting

Let us now focus on a project meeting in order to examine how the previous study results, experience and representations entered and were dealt with in the design process.¹

During the early stages of ProjectND, in June 2014, the larger project team held a project meeting which addressed several aspects that relate to the usage of the designed device. The meeting incorporated 10 participants, which included the main project team members as well as the sales director, design manager and some of the senior level professionals. The meeting agenda was the following: first the industrial designer presented the design concept and the mock-up of the device. He then continued with presenting different options for the feature set and the technical level of the product, which included several aspects that affect the user experience and usage. After this, the in-house users presented their view on the main user groups and use cases. This led to making a decision about the feature set and technical level of the product. The meeting ended with a discussion on the product’s duty cycles and operation times. In the end, the participants came to an agreement on the main issues regarding the cooling system.

The industrial designer started with presenting three different feature sets and technical levels for the product. Each of the options also included an estimation of the time it would take to have the product ready for launch, the relevant features that the device would include and the technologies it would support. In addition, the designer presented two different concepts that were dependent on the device’s selected charging system. As the designer is experienced and has worked for the company for several years, he knew which are the main features of the device that affect the user and need to be addressed early on in the development phase. Thus, the different views of the users, usage situations, and business and portfolio aspects were brought together.

Then the meeting proceeded to the description of the possible users and usage situations of the device. This discussion was led by the in-house users.

In-house user 1:From here, it’s good to move onto the other part; so, we’ve thought a bit about this machine from the ((technology)) side – what user group this is for, and what are the external requirements and, in the end, the ((technology)) requirements. So, this is our ((technology)) services’ and professionals’ view at the moment.

In-house user 2:Yes, this started, when ((the project manager)) sent a couple of weeks ago a question to us in the ((Technology)) Services, who have ((technology)) advisors and engineers who work with the customers, asking that would have some thoughts about what kind of features a battery-operated machine should have? And I answered that we would like to comment but, to be able to address the features, we would need to think about the user and usage circumstances, and what the ((user)) group is.

Then the in-house user started listing different user groups and usage situations that the device could have (these act as user representations [see, e.g. Oygür 2018]).

In-house user 1:Probably first comes to mind industrial maintenance and the workers who work at the factories of process industries. These are the common users, who usually leave quickly to repair a machine when a bolt or something breaks. Also, in offshore ((contexts)), shipyards and others. ((…)) Then those small one-man companies that every now and then make some ((small repair work)), they need an easy device that you can just take with you in the car. ((…)) But then one group is related to the military users. A bit different are the machine operators – the guys who work with machines in the woods. There it’s wet and dirty and muddy and all, and the aggregate isn’t necessarily near. Well, farms are one typical ((usage situation)); you go to the far corner of the field and fix a fence or something.

The user group approximations are soon tied to some of the different functional requirements that they imply for the device:

In-house user 1:Then requirements relate to the external qualities of the device due to the usage circumstances: lightness and portability, the cables that go with the device can be carried in one hand. Then, as an alternative, a wearable model. That raised some comments that no one would want to wear it during usage, but I thought about the straps ((the designer’s name)) showed us – the machine could have them. Let’s imagine that a factory worker has to climb up a few steps, they could attach it like a biathlon rifle, a backpack.

In-house user 1:The factory worker climbs up the stairs at the factory. But then, in some larger factory, there’s usually a central repair point where the repair workers hang around and pack the devices and drive around on a bike. Similarly, whether it’s on the back of a bike or the front basket or wherever, it’s in a neat package.

This part of the meeting demonstrates how the in-house users’ expertise about the actual users, use cases and usage environments are utilized and how they are appreciated in the product development, especially in this kind of project when the external users could not be involved. These in-house users’ ideas raised a lot of discussion among the meeting participants, but they were valued. We also see here how the meeting concentrates on the work already done separately by each participant on their own, as well as on interaction with each other: ideating carrying solutions, thinking through the likely user groups, considering potential feature sets. This work is then subjected to discussion and iteration among the whole development team. Let us follow further the discussions about the possibility for a carrying case and whether the user interface needed a display or not:

In-house user 1: So now the need for this kind of device is of course that everything would go neatly in one package. The carrying case would have the chargers, power sources, cables, other items. It would be placed inside the case of the forestry toolbox or in the back of a van.

Participant 1: Yes, and in a van there are the drills and everything else in similar cases.

Participant 2: Yes, and we would avoid the problem that ((the designer)) mentioned that when the package starts moving, it bounces around the van. In a case it would be protected.

In-house user 1: We see that a case would be more than needed here – it would be sensible.

Later in the meeting the participants returned to this topic:

Participant 3: So, if we think that this device is meant for this kind of I-need-to-quickly-go-somewhere-and-do-something situation, or the cottage guy, should we also think that possibly somewhere in the carrying case needs be the ((other equipment)) and the=

Participant 4: ((piece of equipment))

Participant 3: = ((piece of equipment)). So, we would need to think of places for those in this whole set.

Participant 5: ((One equipment type)) and all these.

Participant 3: Yes. This came to my mind for a certain reason. I have these two interest areas. One is tennis and the other is the trumpet. And in both, the carrying bags are extremely well designed. So, if you have a tennis bag, you need to have the rackets and the shoes and all the things you can imagine and the strings and so on. And if you are playing the trumpet, the trumpet goes into a million different pieces and then you have the valve oils and the dampers and notes and everything. And the carrying equipment for both are very well designed. So have a look at those.

This shows how an idea is brought up by the in-house users and is supported and further developed in the discussion. It also shows how the insights are brought from other fields that could be utilized in this project. Especially since this is a new type of device, representations from other fields become more important. Next will follow a comment from the in-house user about the need for a display which demonstrates how the in-house users relate the planned users and usages of the product and make suggestions to the development team accordingly:

In-house user: So, regarding the display, we don’t think the display is necessary. But if it is an option, then we need to think about it. But the user group that would be the largest for that, doesn’t do =

Participant 3: Anything with the display.

In-house user: = anything with the display. Because it’s an emergency help device. And, on the other hand, if there’s a clear scale that’s more-or-less accurate around the knob, you can get the same information in the ((gear)) box.

After this discussion, the meeting participants were ready to return to the first part of the agenda and make a decision regarding the level of the product presented in the beginning of the meeting:

In-house user: Then there’re the ((technology-related)) things that ((the name of the person)) has written down. I won’t take a stand about the features at the moment, but we think that if you look at the usage environments where the volume could be, there wouldn’t be a need for ((the technology option)) because …

Participant 1: I would be ready to drop the ((technology option)) because we should aim at the machine being good at what it’s designed for.

Participant 3: Exactly.

((…))

Participant 5: Yes, I haven’t really opened my mouth yet. I definitely agree that, from the user experience point of view, we need to do concept 1, and we do it well. Because we can do it perfectly. So ((it should be)) as simple and minimalistic as possible.

((…))

Project manager: So, do I interpret correctly that have reached a consensus that we go with ((the designer))’s proposal ()

Participant 1: [One.]

The discussion flowed between the participants and dealt with many possible use cases and the technical solutions related to them. This shows how the discussion about the users and all the pieces presented earlier in the meeting come together in the final decision. It summarizes many different views of the users and potential use cases.

To sum up, the meeting addressed the user types and usage situations for the device quite profoundly. It included discussion of the user types and usage situations and matched them with product qualities and technical solutions. In addition, it displayed several different representations of the users and usages, and ways in which they were applied. Naturally one meeting was not enough to plan the whole product and most of the work is done outside meetings. However, this meeting demonstrates how the users, their needs and product qualities are discussed in an HCD-mature company and how the users are constantly kept in the discussion.

What then happened?

The product development project proceeded over the following two years. The main user groups stayed the same, as did the main feature set. A lot of work had to be done on the technical solution of the battery system and the charging system for the device in order to meet the usage time and the water resistance level requirements set for the product.

The form of the product and the different ways to carry it had already been drafted and tried out during the concept phase preceding ProjectND, and the shape stayed roughly the same. This could be seen coming up in the project meeting example presented above.

The device was presented in a public event during autumn 2016 and it got an excellent response from the audience. There was a lot of interest and enthusiasm from the potential customers. It also reached a more extensive testing phase during summer 2018 and was shown to customers visiting the company, the results were very promising and the device’s operating properties were considered good. However, the safety of the battery construction couldn’t be ensured and CompanyIM could not take any risks regarding the safety of their devices, and thus, they had to postpone the production.

How user insight is brought into use and utilized in HCD projects that do not have access to users

Let us now view how user insights were handled in ProjectND and how they were rendered relevant for the product’s design. Firstly, there were the user representations, the main ones being a worker up a mast, a worker with a van, a DIY person, an oil platform maintenance worker and a farmer. These were based on earlier user studies and other encounters with the users (Savolainen and Hyysalo, 2021). Thus, the sources for user representations were many and based on the use of multiple HCD methods, market research and accumulated insights into user experience gained over the years. They were brought into multidisciplinary discussion in the project meetings and placed under critical scrutiny to increase their reliability; they were also pruned and prioritized in order to guide the design work and to form a common point of reference among the project team. Secondly, there were the in-house users who brought their knowledge and experience to the project, as well as tested the different solutions that were created. Since they had worked for the customers or similar sites earlier, they had first-hand knowledge about the users and user environments, and could do the initial testing of the device and comment on the user representations. And thirdly, in addition to the user representations, there were the representations of usage, which could be iterated into feature sets that could be tested independently, for instance, testing the device and the different solutions (such as the backpack and straps). Whilst none of these sources would guarantee adequate design of use and definition of user groups, their complementarities and interaction during the design process could go a long way towards doing so. Thus, in all this, design acted as the glue for user knowledge: it pulled together the different information sources and created meaning from the different user and usage representations, resulting in a well-designed product.

At the same time, this analysis answers the second research question (within the context of this research setup) about recognizing HCD although no direct user involvement occurred. Firstly, we can evaluate the company’s maturity level in HCD and see that adequate HCD procedures are in place. And secondly, by studying the user representations, we can see that they are utilized and from a variety of sources, many of which involve direct contact with the user, and in addition, that the user representations are carefully considered during the project. Thus, there are ways to recognize that a company is applying HCD.

Discussion and conclusions

As can be seen from the various sources of user insights presented, although CompanyIM did not involve users directly in the design process, it does not mean that there was no user input used during the design process. On the contrary, the sources of user insights were rich and diverse, and the insights had been accumulated during many years of operating in the market in a human-centred way. This leads to the primary contribution of this paper; it highlights the various sources of user knowledge that a company with a long history in HCD has. Thus, a design process can differ from the standard HCD process (Nielsen 1993; ISO_9241-210 2019) and still be successful in terms of HCD.

The secondary contribution is that in HCD-mature companies, users and usages can indeed be processed in many ways and be a part of accountable discussion. This can be seen from the many ways in which the users are addressed in the meeting discussions. The users are brought to the discussion often and, significantly, the discussion is based on studies or other sources of user insights rather than on opinions and guesswork.

The tertiary contribution of this paper is that it demonstrates how the developers (designers and engineers) find alternative ways to get the needed user knowledge into product development when the primary source of user input is blocked. This includes several internal sources and, in cases like CompanyIM, the utilization of the in-house users becomes notable. Similar cases of internal users have also been reported in other companies (Kotro 2005; Schweisfurth and Raasch 2015). Thus, HCD mature companies can occasionally manage a project without direct user contact.

However, this study has its limitations. It is based on one company and, as such, it provides a good case example, but the generalizability of the study is limited. In addition, we cannot compare what the end result would have been if direct user contact would have been enabled. Yet, this study adds knowledge about the many ways HCD-mature companies ‘in the wild’ utilize user insights. As in earlier studies in real-life product and service development contexts (Johnson et al. 2014; Kotro 2005; Hyysalo 2010; Wardlaw 2016; Oygür 2018; Schønheyder and Nordby 2018; Johnson 2013), it has proven useful and insightful to study product development projects in real-life design-oriented companies.

In the future, I would recommend further research in high HCD-maturity companies in order to discover the variety of practices that are used for both designing with and for different types of users. This work would at least include mapping the different ways in which the companies know their users, how the knowledge has accumulated and what has worked in different projects (see, e.g. Mäkinen et al. 2019). In addition, more research should be conducted on how to recognize HCD in an organization. This could be studied at different levels, also within organizational research. These would help to gain a comprehensive picture of which practices bring user knowledge into design processes and to discover the strengths and weaknesses of the processes.

Acknowledgements

I would like to thank The Finnish Science Foundation for Technology and Economics KAUTE for supporting writing this paper. In addition, I thank Sampsa Hyysalo, Andrea Botero and other INUSE research group members for commenting this paper.

Disclosure statement

No potential conflict of interest was reported by the author.

Additional information

Notes on contributors

Kaisa Savolainen

Kaisa Savolainen, DA (Art and Des), MSc (Tech) is a researcher at Aalto University. Her research focuses on human-centred design, co-design and accessibility. She has also worked for over 10 years in the private sector on areas related to user research and co-design.

Notes

1 The transcriptions of the meeting are translated from Finnish to English by the author. As Finnish is significantly further from English in terms of vocabulary, grammar and idioms than any Indo-European language, the translation results are at times difficult to follow. In addition, words have been translated into their literal English form, preferring meaning over verbalization. The translations attempted to preserve the tone of spoken language.