What do software startups need from UX work?

Abstract

Empirical research on software development practices in startups is growing. However, little has been investigated about how User eXperience (UX) work has been carried out in software startups. The primary objective of this paper is to investigate what software startups need from UX work. To achieve this goal, we conducted open-ended interviews and retrospective meetings with 16 software professionals from two software startups in Brazil. We analysed the data qualitatively using different coding approaches: initial coding, focused coding, and theoretical coding. We found 14 UX work-related needs which emerged from the daily practices used for software development in the two startups studied. Based on our findings, we propose an initial theoretical framework that highlights two theoretical themes and four groups underlying the needs identified. Our study reveals several relationships between UX work-related needs which are helpful to understand in order to identify what startups need from UX work in practice and to focus startup teams' efforts on the most urgent needs. As future work, we plan to explore ways in which these needs may be addressed so that UX work may be put into practice in software startups.

1 Introduction

Startups are companies of high relevance to the economy of any country. The global startups’ economy has more than doubled over the last five years (Gauthier et al. 2021) which has drawn the attention of researchers from different areas including software engineering. Many studies of software engineering in startups have pointed out the need to pay attention to the experience that the product provides to the users, i.e. the user experience (Paternoster et al. 2014; Giardino et al. 2016; Hokkanen et al. 2016b; Unterkalmsteiner et al. 2016; Klotins et al. 2019a; Saad et al. 2021). There are many definitions for the term user experience (UX) but most focus on the holistic perception that users have of a piece of software’s functionality and quality characteristics (Law et al. 2009). More recently, ISO 9241–210 defined UX as “user’s perceptions and responses that result from the use and/or anticipated use of a system, product or service” (ISO9241-210 2019).

The literature on software startups has discussed UX design as a critical factor that can support teams in the creation of software that brings value to users and businesses (Hokkanen et al. 2016b; Unterkalmsteiner et al. 2016; Giardino et al. 2016; Hokkanen and Väänänen-Vainio-Mattila 2015; Saad et al. 2021; Silveira et al. 2021). Since software startups have limited resources and work with small teams, their activities are run on very tight schedules, and often they do not prioritise the design of UX (Hokkanen et al. 2016b). On the other hand, startups are aware that failing to deliver a satisfying user experience can result in a poor product for users and may lead them to waste their few resources on features that can be less desirable for the users (Unterkalmsteiner et al. 2016; Klotins et al. 2019b).

Similarly to Saad et al. (2021) and Hokkanen and Väänänen-Vainio-Mattila (2015), we use the term UX work to refer to the use of user-centred approaches, practices, and techniques with the purpose of acquiring and applying knowledge about the target audience. Investigation on how to conduct UX work in startups is needed because of the particular conditions under which startups operate, i.e., time pressure and lack of resources (Paternoster et al. 2014; Hokkanen et al. 2016b; Unterkalmsteiner et al. 2016; Silveira et al. 2021). By understanding how UX work is carried out in these conditions, we can improve current UX approaches, practices, and techniques and/or design new ones so that software startups can deliver better products.

Although the importance of considering UX work in software product creation is recognised in the literature on software startups, only a few publications have explored UX work in the daily activities of startups (Saad et al. 2021). Some studies report that startups often use UX practices informally to gather data about users and product usage (Hokkanen et al. 2015; Hokkanen and Väänänen-Vainio-Mattila 2015; Kuusinen et al. 2019). However, startups struggle with how to process the information they collect, not recognising the potential of this data to support user-centred software development (Liikkanen et al. 2014; Hokkanen and Leppänen 2015; Hokkanen et al. 2015). In many cases, this issue relates to a lack of knowledge about how to use UX practices in the startups' environment, even when a UX expert is working with them (Guerino et al. 2021; Saad et al. 2021).

The literature mostly discusses the needs and challenges related to UX work in startups without relating them to the day to day activities of software development (Silveira et al. 2021; Hokkanen et al. 2015; Hokkanen and Väänänen-Vainio-Mattila 2015). Although the literature mentioned has shown that user data is relevant to UX work, there is no research on how UX practices can support the software teams in startups to process the user data that is collected. To address this and other challenges, we aim to understand the needs that startups have and that UX work can fulfill. Therefore, we define the following research question (RQ):

• RQ—What do software startups need from UX work?

To answer this research question, we carried out a multiple case study based on two software startups in Brazil. In each startup, we carried out interviews and retrospective meetings. The participants were 16 professionals in software development, UX, and customer relations positions. To analyse the data, we adopted elements of the constructivist Grounded Theory Methodology proposed by Charmaz (2014) which are based on coding techniques. From the analysis we could uncover 14 needs related to UX work and answer the research question.

Our findings with these two startups reveal that: (1) 4 out their 14 needs are about handling customer feedback and user information; (2) although startups document customers/users feedback, they do not take advantage of this to effectively use the information to improve the product; (3) startups adopt a small number of UX practices; and (4) software teams face difficulties when communicating about UX work. Our results differ from previous studies by discussing: (1) the needs that support startups in improving user experience of their products; and (2) the needs that have to be fulfilled so that UX work can be put into practice in the startup context. To the best of our knowledge, no other work has explored this complementary perspective of user data and UX work in detail.

The rest of the paper is organised as follows. Section 2 presents related work. In Section 3, we describe the research method giving details about the studied software startups, data collection, and data analysis. The 14 UX work-related needs are presented in Section 4 alongside an initial theoretical framework that integrates them. In Section 5, we answer the research question by discussing our findings in relation to the literature. Study validity is discussed in Section 6. Finally, Section 7 concludes the paper and outlines the contributions of our study for researchers and practitioners of software startups, and points out possibilities for future work.

2 Related Work

2.1 Software Startups

Startups are recognised as companies that operate in environments of high uncertainty and constant rapid evolution (Sutton 2000; Giardino et al. 2016). According to Paternoster et al. (2014), startups typically operate with little financial and human resources, under time pressure, and they are highly reactive to market conditions. The strong presence of entrepreneurial personalities encourages innovative team behaviours in these companies which are constantly seeking methods and techniques that could help them in the creation of new products (Bygrave and Hofer 1992; Hokkanen and Väänänen-Vainio-Mattila 2015; Klotins et al. 2019a).

Startups differ from established organisations in their constant search for a scalable and sustainable business model (Ries 2011; Paternoster et al. 2014; Hokkanen et al. 2016b). Paternoster et al. (2014) point out that startups operate in a market-driven context which makes them launch products fast with minimal resources. For startups that are software producers, called software startups (Giardino et al. 2014), this search for a business model translates into iterative software development with frequent releases and the need for constant customer/users' feedback (Paternoster et al. 2014).

Typically, software development in startups is driven by agile practices both to understand their target audience and needs, and to develop software; this helps startups' small teams deliver business value to customers and be ready to change quickly according to market demand (Coleman and O’Connor 2008; Unterkalmsteiner et al. 2016). Software startups work under the influence of different variables such as time pressure, lack of resources, and no prior operating history, and are often required to work with disruptive technologies (Sutton 2000; Giardino et al. 2016; Klotins et al. 2019a). Once they enter the market with a software product, software startups increasingly focus on solving problems that emerge from everyday users rather than just considering the technical aspects of the products (Giardino et al. 2016).

2.2 UX Work in Software Startups

A number of studies mention UX as an important factor of product quality or else discuss questions about UX work in startups (Klotins et al. 2019b; Paternoster et al. 2014; Giardino et al. 2016; Unterkalmsteiner et al. 2016); other studies are focused on UX work topics and consider the particularities of startups in the discussion (Hokkanen and Väänänen-Vainio-Mattila 2015; Hokkanen and Leppänen 2015; Hokkanen et al. 2016a, b; Liikkanen et al. 2014; Kuusinen et al. 2019; Lindgren and Münch 2016; Silveira et al. 2021; Guerino et al. 2021; Saad et al. 2021). We explore their results in more detail below.

Klotins et al. (2019b) analysed 88 startup experience reports and showed that many startups consider focusing on the product’s UX to be essential for software development even when the startups did not report the use of UX practices. The findings from Paternoster et al.’s (2014) literature mapping shows that several authors report the importance of involving customers and users in the process of elucidating and prioritising requirements. However, the authors state that due to specific characteristics such as lack of resources, small teams, and fast-paced environments software startups struggle to conduct studies with end-users throughout the development cycle (Paternoster et al. 2014).

Similarly, Giardino et al. (2016) mention the need to obtain user feedback, to process it promptly to learn about the product and, consequently, to make better decisions about the product’s evolution. In 2016, the Software Startup Global Research Network group created a research agenda with emerging topics in software startups (Unterkalmsteiner et al. 2016). This agenda suggests the investigation of: useful UX methods and practices for startups; the role of UX in the different phases of startups' life-cycle; and, the extent of the connection of UX and business models to create customer value (Unterkalmsteiner et al. 2016).

Hokkanen et al. (2015) conducted interviews with 13 entrepreneurs from eight small software startups based in Finland to explore how startups start the UX design of their early product versions. The results showed that entrepreneurs stated the importance of carrying out experimentation and feedback with users and customers. However, they recognised that startups often use UX practices informally to gather data about users and product usage. In another study, Hokkanen and Väänänen-Vainio-Mattila (2015) conducted interviews with eight startups in Finland to investigate their practices in end-user data collection and designing of UX as well as the practices they intend to adopt in the future. The results indicate that a lack of UX expertise and time constraints hinder startups from collecting useful feedback from users. Consequently, startups use personal contacts and unofficial discussions to gain feedback about the product idea and design; they regard friends as a reliable source of feedback. Taking into account these difficulties in getting end-user feedback, Hokkanen and Leppänen (2015) elaborated three patterns to manage user involvement in startups to allow them to gain feedback and learn. These patterns focus on guiding testing with end-users and early user engagement in the development process.

Hokkanen et al. (2016a) proposed the MVUX (Minimum Viable User Experience) framework consisting of categories that describe quality attributes (i.e., attractiveness, usability, market acceptability) that startups should consider in product development to ensure a good user experience. In another work, this proposal was validated through interviews with professionals (Hokkanen et al. 2016b). However, no other related work reports on the use of the MVUX framework in startups’ daily practice.

Kuusinen et al. (2019) conducted interviews with four software professionals to understand how a data-intensive startup carried out UX work to develop its product. They found that the startups in their study do not give much attention to the product’s user experience before the implementation phase and that they do not have a dedicated team or even a single professional for UX work.

Liikkanen et al. (2014) presented the experience of a Finnish organisation adopting Lean UX; Lean UX is a user-centred software development approach that aims to produce a product as quickly as possible and with minimal resources so that the team can learn more about what will satisfy customers/users’ needs. In a short description of the results, the authors point out that the organisation implemented an outsourcing philosophy in which the design, development and user testing are separated by acquiring each of these services from a different provider. Consequently, they had problems in changing the teams’ mindset to integrate the UX work with their software process.

Lindgren and Münch (2016) carried out interviews with 10 Finnish software development companies, three of which were startups, to investigate the use of continuous experiments in lean UX to validate design ideas. Based on the findings and in the literature, the authors suggest that companies should implement a systematic experiment-driven development approach and collect qualitative data; this would help to understand customer feedback better and the results from experiments could be used as input for data-driven decision making. However, the authors do not validate the suggestions with organisations.

Silveira et al. (2021) conducted a survey with 88 software professionals in the Brazilian startups’ ecosystem. The findings show that most of the respondents use UX practices more often during product specification, design, and prototyping activities than in other phases of the life-cycle. They also reveal that the know-how to collect and interpret feedback and user data are considered much-needed skills for professionals who play some UX-related role in startups. The authors point out that adjusting the pace of UX work in a highly reactive environment is a challenge that needs to be overcome if UX work is to be adopted in the startup environment. Silveira et al. (2021) discuss that UX practices are often carried out without the company having a UX team or a dedicated professional (similarly to Kuusinen et al. (2019) above), but rather a strong focus on the customer and their product feedback.

Guerino et al. (2021) carried out interviews with six professionals in five early-stage software startups. They aimed to investigate how startups that are starting to operate use UX practices. The results show that early-stage startups often use UX practices to support their teams in building the minimum viable product and fostering mentoring programs for the team themselves. The authors state that early-stage software startups understand that the results produced by UX practices can generate value for investors and lead to the development of strategies to identify and engage users.

Saad et al. (2021) carried out a thematic analysis of 21 studies selected from the existing literature. The results revealed that most studies point out and discuss the challenges and benefits of UX work for software startups. However, the authors state that there are many open questions that need further investigation in the startups’ context. Some of the open questions are about how startups can make better use of the UX data they collect, which UX practices, methods and techniques could support the startups in working with UX design, and how to apply them with limited resources.

3 Research Methodology

This study is part of a wider research project on UX work in software startups. It was previously reviewed and approved by the Ethics Committee in Brazil (CAAE: 29367020.0.0000.504) at the Federal University of São Carlos, Brazil. This project aims to develop a multi-dimensional framework that helps startups to optimise the integration of UX work activities in the daily work of their teams.

We have conducted a qualitative exploratory multiple case study by following the guidelines from Runeson and Höst (2009) and adopted coding techniques to conduct an in-depth qualitative data analysis. The coding process was carried out in different steps and we adopted elements from the grounded theory proposed by Charmaz (2014) as auxiliary techniques to code our data in different stages. Figure 1 presents the research design overview. As shown, data collection, analysis, and validation were conducted incrementally. The procedures and protocols for data collection were defined before each step by the first and third authors. At least two researchers participated in the preparation of the interview scripts, in the data collection sessions, and in the video recordings transcription (i.e., the first, second and third authors). The data analysis was conducted incrementally with the participation of all the authors in different steps. All authors intensively discussed the results at all stages, including validation of our results. All authors have experience of qualitative research in industrial software contexts with expertise in different methodologies such as ethnography, case study and grounded theory. In particular, the second and sixth authors have expertise in grounded theory fundamentals, while the last author has been conducting grounded theory studies for almost two decades. The first, second, third, and fifth authors also have expertise in investigating UX issues and practices integrated with software engineering practices.

Fig. 1

Research design

Next, in Section 3.1, we discuss the details of research planning, including study design, ethical approval, and selection of case studies. The data collection methods and data analysis procedure are presented in Sections 3.2 and 3.3, respectively. Finally, in Section 3.4, we describe the validation step of the UX work-related needs.

3.1 Research Planning

In software engineering research, case studies are widely adopted to investigate phenomena in their real-life settings (Runeson and Höst 2009). When conducting a multiple case study, it is essential to explore differences within and between cases. The unit of analysis in this study consisted of software startups located in Sorocaba, São Paulo, Brazil. According to the Startup Genome’s report (Gauthier et al. 2021), Brazilian startups raised a record-setting $2.7 billion in the second quarter of 2021. São Paulo state has a robust startups ecosystem with an extensive network of public and private research institutions, as well as technological park systems located in different cities. In Sorocaba, a city with more than 600,000 habitants, the startup ecosystem has grown in recent years. We chose to carry out our studies in Sorocaba because we already had a pre-established contact network with the startups. In addition, our project aims to explore startups in the state of São Paulo. We selected two startups from our network. The two organisations were established startups that apply UX practices in some form (more about that in the next section). Table 1 presents information about the two startups we studied. This table was created using the checklist provided by Petersen and Wohlin (2009). For ethical reasons, the names of the products and companies are omitted.

Table 1 Startups and context information adapted from (Petersen and Wohlin 2009)

Startup A works in the market segment of education. It started as a franchising of a STEM (Science, Technology, Engineering and Mathematics) and robotics company. Startup A was founded in 2015 and in 2017 it launched a new product and service for supporting the introduction of STEM in preschools, elementary and high schools based on robotics. The product had about 55 thousand users (i.e., students, teachers, and parents), and around 90 employees worked at Startup A, with 50 co-located in the organisation. Startup A adopted SCRUM practices and used a virtual Kanban board to keep all the teams informed of software development. The teams were composed of around 6 members each with cross-functional skills. The members of the pedagogical team played the role of product owners. Startup A had no dedicated UX professional, only a graphic designer who is responsible for user interface (UI) design. After the initial UI design was created, some modifications could be made until the prototype was delivered to the developers. However, we observed that Startup A employees applied UX practices many times without labelling or recognizing them as UX practices. In the literature, we see that this scenario is recurrent in many startups (see Section 2). The technology director was our key contact who acted as a facilitator for the research activities.

Startup B’s product is an e-sports platform for competitions with more than 1 million users (i.e., gamers) in the world; they have about 70 employees. The organisation was founded in 2015. Startup B followed SCRUM and Kanban practices, based on the people-driven approach proposed by Spotify (Cruth 2021). Teams, called squads, are similar to SCRUM teams. Squads are small, flexible teams that are responsible for the end-to-end delivery of each product. They are cross-functional, autonomous teams (typically 6–12 individuals) that focus on one feature area (Cruth 2021). Startup B adopted dual-track agile to conduct UX work (Sy 2007). Dual-track agile has two distinct flows, called discovery and delivery (Sedano et al. 2020; Trieflinger et al. 2021). They are executed in parallel, and one track sustains the other at regular intervals. In Startup B, the cross-functional product teams, i.e., the squads, break their daily development work into two tracks. While UX designers are responsible for the discovery process, focusing on producing, testing, and validating product ideas, product designers manage the delivery process, working on turning ideas from the discovery phase into an actual product (Sedano et al. 2020; Trieflinger et al. 2021). The head of product design was our key contact who facilitated our case study.

3.2 Data Collection

Data collection in both startups took place from July to December 2020. The main data gathering methods were open-ended semi-structured interviews and the evidence-based timeline retrospective method (EBTR) following the guidelines of Bjarnason et al. (2014). The interviews and EBTR were conducted in Portuguese which is the native language of the interviewees and interviewers. All data collection activities were carried out online due to the Covid-19 pandemic, as most companies were working remotely at that time. In particular, the selection of the EBTR method was based on three criteria. First, we wanted a method that allowed us to collect in-depth qualitative data according to the professionals’ viewpoint. Second, we sought to encourage all participants to speak and contribute to the online data collection. And, third, we wanted to encourage the startup team members to report data about their work before and during the pandemic.

3.2.1 Participants

To understand the UX work in startups from different perspectives, we included practitioners with different backgrounds, expertise, and roles (e.g., software development, UX design, customer experience, and marketing). We collected data from startup practitioners to explore how the UX practices were being applied in the development of their products and services. We recruited 16 participants in total, 5 of whom were from Startup A and 11 from Startup B. Table 2 shows the roles played by the participants, number of years of working in the startup, and years of work experience in the technology area. In addition, the last two columns of the table show in which collection steps each of them participated (i.e., interview and/or retrospective meeting).

Table 2 Profile of the participants of Startups A and B

3.2.2 Interviews

We conducted semi-structured interviews in which the questions were planned but not necessarily asked as they were written or in the same order. The interviews were carried out in two rounds. In the first round, we interviewed a key contact of each startup to get an overview of the startup, including information related to the company's business model, market segment, products, services, and team characteristics. Afterwards, the key contact helped us to recruit interviewees for the second round of interviews. The interviewees were selected based on time in the company and their involvement with users, product development, design, and UX activities.

In the second round, the interviews were conducted with 5 and 7 interviewees from startups A and B, respectively. The goal of the interviews was to obtain details about the UX work performed at each startup over time. The interview script included: (i) the interviewee’s background (i.e., professional experience, when they joined the company, what positions they had held); (ii) information on their day-to-day work, the use of processes, artefacts, tools, and typical interaction with other practitioners; (iii) the perceived challenges regarding UX work; (iv) suggestions for process improvement; and (v) personal contributions and involvement in UX activities. The interviews were conducted remotely through Google Meet. We recorded all interviews with the participants' prior consent, using Google Meet. The interviews lasted between 40 and 60 min, totalling 7.2 h of video recording. We opted for video recording instead of just audio to get closer to the interviewees as if they were in a face-to-face conversation.

3.2.3 Evidence-Based Timeline Retrospective (EBTR) Method

To complement our interviews, we used EBTR, as proposed by Bjarnason and Regnell (2012). EBTR was originally proposed to support software teams to reflect on their experiences throughout a project to improve their way of working (Bjarnason and Regnell 2012). EBTR is based on the idea of agile retrospective meetings. In EBTR, the visualisation of the project history on a timeline provides objective information to foster the discussions and reflections of participants during the retrospective meeting. The topics on the timeline can highlight different activities performed over time, such as decisions made, events, and actions (Bjarnason et al. 2014). Software teams typically organise retrospective meetings to improve their processes. In our study, we used the EBTR method to collect additional data about UX work and clarify some issues from the open interviews. To conduct the EBTR, we followed the steps suggested by Bjarnason and Regnell (2012), as shown in Fig. 2.

Fig. 2

Data collection step

EBTR Preparation

The third author (hereinafter R1) was assigned as the researcher responsible for preparing EBTR and facilitating the retrospective meetings. The transcripts of the interviews carried out in the previous stage of data collection were used as input for EBTR preparation. The EBTR goal was to investigate the use of UX practices, tools, and techniques in the two software startups under study (Fig. 2, item a). To achieve that goal, based onKashfi et al. (2016),¹ we defined three aspects to explore during the retrospective meeting (Fig. 2, item b): (i) events, activities undertaken explicitly for UX, or for other aims but that influenced UX; (ii) people, those contributing to UX activities and those who consumed the UX information, including UX experts, those promoting the integration of UX in the organisation and those assigned roles related to UX; and (iii) artefacts – tangible outputs of UX practices. Then, R1 conducted a detailed analysis of the interview transcripts to identify evidence (Fig. 2, item c) relating to these aspects (i.e., events, people, and artefacts) for the construction of the timelines.

As a result, R1 identified 18 events for Startup A and 16 events for Startup B. Additionally, R1 identified the people involved and the artefacts related to those events. When identifying UX events in both startups, we noticed that we needed more details about some of them to understand the interaction between the involved professionals and the produced artefacts. These observations helped us elaborate some focus questions. According to EBTR, the focus questions are useful to focus the open discussion and engage participants during the retrospective meeting (Bjarnason and Regnell 2012). Our focus questions addressed the following: the main events that had an impact on the performance of UX activities, the activities related to end-users that were carried out, the artefacts such activities produced, the people responsible for carrying out the UX work, the role of those people, and the UX work that they did independently of end-user requests.

Timeline Construction

Considering all the aspects and evidence identified in the previous step, R1 constructed two timelines, one for each company (Fig. 2, item d). Each timeline contained several UX events carried out over time at the startup, as well as people involved and artefacts used in each of the events. For both startups, the timeline covered the period from January 2019 to July 2020.

EBTR Meeting

The EBTR meetings, with 6 professionals from Startup B and 5 professionals from Startup A took place in September and October 2020, respectively (Fig. 2, item e). Each EBTR meeting lasted around 1 h and a half. Three researchers participated in the EBTR meeting with Startup B, i.e. R1, and first and second authors (R2 and R3 respectively). As mentioned, R1 acted as a facilitator while R2 and R3 participated as assistant-observers taking notes during the meeting. In the EBTR meeting with Startup A, R1 also played the role of facilitator, while R2 was the assistant-observer. Both meetings were videotaped with the prior consent of the participants. One day before each retrospective meeting, R1 sent participants a URL link to a Miro² board with the pre-prepared timelines. Participants were encouraged to check them and take notes of any memories they might have about events and other details related to UX activities, whether reported on the timeline or not.

During the retrospective meetings, R1 followed the same script for the two startups. In the first part of the meeting, R1 talked about the objectives of the meeting, i.e., to understand the different types of UX activities carried out by them, and how the activities had evolved in the company so far. Interacting through Miro, the participants were given about an hour to discuss the visual timeline. During that time, R1 introduced focus questions to encourage discussion among the participants, as necessary. Figure 3 shows the same piece of the visual timeline of startup A, before (a) and after (b) the retrospective meeting; the timeline (b) shows the rearrangement and insertion of events, people, and artefacts done by the participants.

Fig. 3

Example of visual timeline used with startup A

In the final part of the retrospective meetings, the participants were asked to complete a reflection board. For 10 min, the participants added sticky notes with their opinion on UX activities answering three questions arranged in columns: what worked, what needs to be improved, and what actions were needed to improve it. R1 read each sticky note and asked the participants whether they wanted to make more comments. After the meeting, R1 reviewed the timeline and shared the link with all participants. In addition, an online questionnaire was sent to collect participants’ opinions about the activity. After the EBTR meetings, the video-recorded data were transcribed and analysed along with the other interviews.

3.3 Data Analysis Procedures

Coding techniques were used for qualitative data analysis to answer our research question on the UX work-related needs within the context of software startups. In this study, we adopted elements of Charmaz's Grounded Theory (GT) to support our data analysis because of its constructivist approach. According to this approach, knowledge of reality is co-constructed and context-dependent, i.e., individuals make meaning of, and interpret their reality, interactions, and actions taking into account the socio-technical context they are in. Charmaz's GT provides a set of data analysis procedures and coding stages that lead to the identification of key patterns referred to as concepts and categories (Charmaz 2014). Therefore, our data analysis process consisted of three iterative steps called initial coding, focused coding, and theoretical coding, as shown in Fig. 4. Charmaz’s and other GT approaches also recommend that the results of the coding process should have heavy reliance on quotations, as we have adopted in our study report.

Fig. 4

Data analysis and coding stages

The data collected from the two startups included 12 interviews and two EBTR meetings each with several informants, as well as researchers’ notes and information about the visual timelines and reflection boards produced in the retrospective meetings. In total, 619 min of recorded videos were transcribed in Portuguese and subsequently analysed. At each coding stage, the results were translated into English. We used Airtable³ as a database management tool to aid us through the coding process. The following sections detail the analysis procedures at each coding stage.

3.3.1 Initial Coding

Initial coding is the analytic stage in which concepts, their properties, and dimensions are identified from data. In this stage, fragments of text from the transcriptions are coded, identifying a particular meaning. As shown in Fig. 4, two researchers (R1 and R2) individually conducted the initial coding stage. As a result, R1 extracted 395 excerpts defining 35 codes, while R2 extracted 306 excerpts defining 37 codes. Then, R1 and R2 discussed their findings to join similar codes and refine them, for example, by defining broader and more fitting codes. As a result of this step, the initial set of individually identified codes was consolidated with 23 codes related to general issues regarding UX work performed at the studied startups (see Fig. 4). Table 3 presents an example of initial coding containing an excerpt from an interview and the set of codes related to it.

Table 3 An example of identified initial codes

3.3.2 Focused Coding

Focused coding is the stage where initial codes are condensed and refined by highlighting the most significant concepts of large segments of data (categories). The goal of focused coding is to make the codes created in the initial coding more targeted, selective, and conceptual (Charmaz 2014).

In this stage, first R1 revisited the excerpts related to 23 codes identified in the initial coding stage (see the previous section). As a result, R1 identified evidence focusing on UX work-related needs from 151 excerpts. Analysing the codes related to each of the excerpts, R1 initially identified 40 needs regarding the UX work within the context of the startups under study (see Fig. 4).

To make sure the identified needs were associated with the context of software startups and not other software companies, R1 then reviewed the 40 UX work-related needs and excerpts taking into account the 15 characteristics of software startups presented in Paternoster et al. (2014): lack of resources, highly reactive, innovation, uncertainty, rapidly evolving, time pressure, third party dependency, small team, one product, low experienced team, new company, flat organisation, highly risky, not self-sustained, and little working history. This resulted in R1 selecting 61 excerpts representing 30 UX work-related needs that were associated with one or more of the 15 startup characteristics. Then, working together, R1 and R2 revisited the 30 UX work-related needs and grouped them into 14 categories of needs, employing constant comparison and inductive reasoning⁴ (see Fig. 4).

Finally, all authors reviewed the 14 categories of UX work-related needs and their meanings. While refining them, we adjusted the labels and descriptions associated with some of them. Table 4 presents an example of the focused code (i.e., UX work-related need category) named “Promoting UX work culture” and the codes that compose this category. The complete list of UX-related needs and codes related to them is presented in Appendix 1.

Table 4 An example of UX work-related need category and related open codes

3.3.3 Theoretical Coding

The purpose of theoretical coding is to lend form to the focused codes and specify possible relationships between categories. Theoretical codes are "codes that researchers draw on from prior theories or analytic schemes and use to integrate the categories of their analyses" and they are used to develop a coherent theoretical scheme (Charmaz 2014). With theoretical coding, we specified the relationships among the UX work-related needs identified in the focused coding stage. All the authors participated in this stage. Table 5 shows an example of theoretical coding in which a verb (i.e., facilitates) is used to describe the nature of the relationship between two needs, i.e., “having professional input on UX design” (N6) and “documenting UX design artefacts and decisions” (N7). When reading the connection between these needs, we mean that “satisfying” need N6 facilitates need N7. By this we mean that getting professional input on UX design (satisfying N6) facilitates the documenting of UX design artefacts and decisions (N7). A summarised list of relationships among UX needs with some excerpts from participant statements is presented in Appendix 2.

Table 5 An example of identifying relationships among UX work-related needs

In the next section we present the results of the three coding steps.

4 Results

This section presents the findings from the data collection and analysis described in the previous section. In Section 4.1, we detail the set of needs related to UX work and describe existing relationships among them. In Section 4.2, we present the initial theoretical framework of UX work-related needs based on our results of the data analysis from the observed startups. Finally, in Section 4.3, we present the validation of our findings.

4.1 UX Work-Related Needs

A total of 14 categories of UX work-related needs are shown in Fig. 5 together with the relationships between these needs identified during the coding stages; the arrows represent these relationships. The direction of the arrows does not imply a sequence or steps to be followed; instead, it indicates the reading order highlighting dependencies between the needs. For an explanation of how to read these relationships see Sect. 3.3.3. As shown in the figure, there are three types of relationships between needs which are defined by the terms: “facilitates”, “helps fulfill”, and “leads to”. Each relationship type is represented with arrows stylized differently, e.g., a dashed line for “facilitates”, a continuous line for “helps fulfill”, and a dashed line with two points for "leads to". “Facilitates” means that satisfying the need makes it easier for the second need to be satisfied. For example, as shown in the figure, “conducting product research/evaluations with real users” (N5) facilitates “responding to user data” (N1). In other words, “facilitates” represents the idea that conducting research/evaluations with real users creates conditions that make it easier to respond to user data. “Helps fulfill” means that satisfying a need directly contributes to satisfying another need. For example, “conducting product research/evaluations with real users” (N5) helps fulfill “identifying UX insights from user data” (N10) (see Fig. 5). In this relationship type, “helps fulfill” represents the fact that conducting research/evaluations directly contributes to identifying UX insights from user data. Finally, “leads to” means that satisfying one need leads to another need arising. For example, “conducting product research/evaluations with real users” (N5) leads to “documenting UX design artefacts and decisions” (N10) (see Fig. 5). In this example, satisfying N5 means that N7 exists, as the need for documentation exists (N7) because the UX research/evaluation activities (N5) generate various artefacts and design decisions.

Fig. 5

UX work-related needs and relationships

The following sections provide further detail on each of the UX work-related needs. For each need, we present our findings with evidence in the form of direct quotations extracted from the cases which are referred to in the text as [< startup-id >  < collection-method >  < participant-role >]. In addition, we present the relationships between these needs also extracted from our data, highlighting the verbs that link them in bold italics. Finally, we provide a description for each UX work-related need, using text boxes to highlight them.

4.1.1 Responding to User Data (N1)

Our findings show that to improve the product through close contact with users or customers, a startup needs to respond to user demands, whether identified through feedback, queries, suggestions, or complaints from users. During the interviews, DEV2 from Startup A, mentioned that everything that happened related to UX work happened in a "reactive" way: a UX problem arises, then it is solved. Startup B’s SM comments that the responses to user feedback are not at the speed that users expect:

“This close communication with the user should help improve the product, but it doesn't happen at the speed the user needs it to happen.” [B - interview - SM]

In the case of Startup B, an interviewee explained that they have a large user base and the demands that arrive need to be filtered to help decide which demands to prioritise. In this sense, we found that “responding to user data” (N1) leads to “documenting demands coming from the user” (N8). Both startups maintain a service structure for users through support teams and tools such as ticketing systems to register the demands of their users, as pointed out in Startup A member's comment:

“(...) we created this structure for support [support team, ticket system] for the users to enter, log in, and report their needs [demands]; we structure and promote it, and in real time, almost instantaneously it reaches the development team, which decides how to fix it. So, this is a very lively process of improvements and adjustments to the digital solutions that we deliver” [A - interview - MKT]

N1—Responding to user data

Need to improve the product through close contact with users or customers, whether through feedback, queries, suggestions, or complaints regarding the product

4.1.2 Bringing Together Different Sources of User Information (N2)

Since startups need to respond to users’ feedback and research or evaluate the product with users, they can have a considerable amount of disconnected information. “Bringing together different sources of user information” (N2) means to combine the information that the company already has about the user from different points of contact, including company employees, social networks and others. We saw that different areas within the company have information about the user and their relationship with the product beyond technology, such as support and social media. During the interviews, Startup B mentioned that there is a Business Intelligence area and that the information generated in this area should be connected with the existing knowledge from the UX team:

“I think the company lacks an understanding of the need for processes, so there are steps to follow. I know this makes the project take longer, but it's important to bring in more data from the business intelligence people, analyse data first, think collectively of a solution” [B - interview - UX2]

We found that “bringing together different sources of user information” (N2) helps fulfill “responding to user data” (N1) more efficiently since startups have multiple channels with their users, as pointed out by a Startup B interviewee:

“(...) the players themselves are talking within our Discord, giving us feedback (all the time) (...) because there are many [data] sources, you have to get it from Twitter, Discord, find out who talked using DM [direct messages] on Discord with the player along the championship (...) So, there's a lot of room for information to get lost (...) we still need to figure out how to centralise this” [B - interview - PO]

We saw in both startup scenarios the interviewees arguing about having data in an organised and accessible way to improve the visibility of the user’s feedback and comments. In both startups’ scenarios, it is a struggle to combine the different data sources such as external (social media channels) and internal (support and marketing department). “Bringing together different sources of user information” (N2) helps fulfill “identifying real points of improvement through feedback” (N4) and helps fulfill “identifying problems through metrics” (N3):

“Today, one thing that we have improved a lot in terms of product support is that we have the reports [documented], so if the PDM asks us how many calls there were regarding a recently launched product, we can access that number, as long as the team has correctly marked the tickets. So, this is really cool, nowadays we are exploring this tool better” [A - interview - CE]

Furthermore, “bringing together different sources of user information” (N2) helps fulfill “identifying UX insights from user data” (N10) to improve their products, as below:

“There's also the dashboard, which is another project to get an insight into things like ‘the school has bought so many QR codes but it's only using half, therefore half of the students are using the platform.’” [A - interview - DEV2]

N2—Bringing together different sources of user information

Need to gather the information that the company already has about the user (various areas within the company have information about the user and their relationship with the product) and information from different points of contact with users (e.g., contact with company employees, social networks, etc.) and others

4.1.3 Identifying Problems Through Metrics (N3)

In response to “identifying problems through metrics”, the startups' interviewees stated that metrics are relevant to control problems and apply solutions. However, Startup A uses metrics more informally while Startup B uses metrics more systematically. “Identifying problems through metrics” (N3) facilitates “identifying real points of improvement through feedback (N4), as shown by Startup A interviewee's comment highlighting the importance of their service indicators:

“In customer service even when it is not a complaint or feedback, we always have to listen to the user by default. So, we have several improvements that have already been implemented, mainly this year, either by user suggestion, or because the service indicators showed us a certain need.” [A - interview - AT]

Also, “identifying problems through metrics” (N3) facilitates “identifying UX insights from user data” (N10) when practitioners need to investigate in-depth the reasons behind a particular UX problem, as illustrated by another Startup A interviewee:

“There was an error in the backend with a log saying ‘user trying to register with email that already exists’ and they [the users] kept trying (...) So, this increased a lot [the number of complaints] and the loyalty team became overloaded. So, we started to change that, we changed the [login] display. But it was really funny because we thought: ‘how come nobody has ever thought about this?’ ” [A - interview - DEV2]

N3—Identifying problems through metrics

Need to automate the identification of problems through metrics applied in customer service/support

4.1.4 Identifying Real Points of Improvement Through Feedback (N4)

Having close contact with users or customers can lead the startup to collect a lot of feedback from users, but not all of this feedback is valuable to the company. Filtering feedback, complaints, and suggestions led to “identifying real points of improvement through feedback” (N4). However, we found that some feedback provides real points for improvement, while other points are not possible to execute, as they are not aligned with the startup's business model. As stated by Startup A:

“So, we received all this feedback, but there is exactly this filter of what is possible and what we need to guarantee our security; we are not going to change our business model. But they have a very open channel for sending suggestions to us.” [A - interview - AT]

N4—Identifying real points of improvement through feedback

Need to filter feedback, complaints, and suggestions to understand what is really a point of improvement that must be taken into account

4.1.5 Conducting Product Research/evaluations With Real Users (N5)

This need is important to gain an understanding of the users’ profile, their level of knowledge, their pains, and how to communicate with this audience; also, user evaluations of improvements and new features are important so that product improvements are not only focused on information provided by user feedback. As stated by Startup B:

“(...) I sat down with the PO and said “why don't we do a survey with the profile of LoL [League of Legends] users on the current platform to understand [their needs] since we have so many doubts” [B - interview - UX2]

Checking this need with startups, we observed nuances in the stage of the development cycle of the product and the UX practices in the startups. A respondent from Startup A mentioned that they recognize the importance of getting feedback from real users at the beginning of the product development cycle:

“At the time of development, we never did it [test with real users], at least I never did it, I can't tell you whether, for example, any area manager did it, but I never got any feedback from that either. (...) We test during production. We test with the internal staff, not with the final public.” [A - interview - DS]

However, “conducting product research/evaluations with real users” (N5) facilitates “responding to user data” (N1) in any stage of development. For example, practitioners already realise the importance of evaluating the product with real users, as we can see in Startup B's comments:

“There were things that we had planned, I thought they were beautiful, wonderful and tested it with the developers, but when it was launched to the users, they just didn't approve of them.” [B - interview - UX2]

Startup B stated that UX work is already part of their culture and has been better planned lately. This happened after the UX professionals were hired. We noticed that, in many cases, “conducting product research/evaluations with real users” (N5) on a regular basis leads to a need for “having professional input on UX design” (N6). As mentioned by the interviewee from Startup B, the UX work gains another dimension with the support of UX2, the second UX expert:

“(...) the arrival of UX2 made this much easier because, in fact, we started demanding the discovery part, prototyping at least in low fidelity, a usability test with users, and then all this actually became part of the process.” [B - interview - UX1]

Also, “Conducting product research/evaluations with real users” (N5) leads to “documenting UX design artefacts and decisions” (N7), which is not always done due to the dynamism of startups. Sometimes startup practitioners do not know what to do to evolve their products. In this sense, “conducting product research/evaluations with real users” (N5) helps fulfill “identifying UX insights from user data” (N10). The interviewee from Startup B reports how a survey carried out with their users helped them gain insights to move forward with the product:

“(...) in this survey we received 3,000 responses, which opened our eyes and gave us a great insight that the team hadn’t had until then” [B - interview - UX2]

And “Conducting product research/evaluations with real users” (N5) involves getting in- house information to plan the UX work. Overall, professionals need to test their ideas or confirm user information with other practitioners from various areas. “Conducting product research/evaluations with real users” (N5) leads to “improving communication between teams” (N12) when there is a misalignment. The UX expert from startup B illustrates how miscommunication and lack of alignment between practitioners from other areas can be harmful to UX work:

“We, as UX designers, need to understand the context, goals of the product itself and be closer to that to help build the product. And when we work with demands, things arrive ready-made, many things from our process as UX designers get lost. As we do not participate in the creation of those demands, the PO does not know what we could have done.” [B - interview - UX2]

N5—Conducting product research/evaluations with real users

Need to conduct product research and evaluation with real users to gain an understanding of their profile, their level of knowledge, their pains, how to communicate with this audience, and also do product tests and evaluations with real users

4.1.6 Having Professional Input on UX Design (N6)

The two startups mentioned that to have a dedicated area or person assigned to UX design responsibilities/activities depends mainly on the startup characteristics such as resources (financial); team structure (size of development teams); and so on. However, the startups had a slightly different point of view on what the UX design role represents and the impact UX can have on the company.

Startup A saw the need of having a UX professional. However, as there is no funding to hire this person, they preferred to have a partnership with another startup to train the UI Designer on UX design skills. At the time of the interview, they had a hybrid professional who worked as a UI developer and performed some UX work activities such as prototyping.

Startup B evolved the UX work activities they carried out. The UX designers conducted user research, ideation, prototyping, and evaluation activities using different methods and tools. These activities generated countless artefacts and documents. We found that “having professional input on UX design” (N6) facilitates “documenting UX design artefacts and decisions” (N7):

"(...) but we always try to keep the documents we generate separate. So, we have the Figma files, the drive documentation. So, we keep it as [documented as] possible" [B - interview - UX2]

Moreover,“having professional input on UX design” (N6) facilitates “promoting UX work culture” (N11):

“That's when people said 'hey man, I saw UX doing the design, I participated in the workshops, and I saw that it was right'. And even though it was extremely costly and time-consuming, the things that came out of this project were right.” [B - interview - UX1]

However, “having professional input on UX design” (N6) leads to “defining roles and job descriptions for UX work” (N13), as the team of UX design professionals grows. Startup B professionals expect to have a career plan and clear job descriptions about each one's responsibilities:

“ [I think] a career plan is not for you to know what you have to do, a career plan and job descriptions are for you to be clear about your responsibilities, about your commitments, and why you were hired (...) I think [having] that would help a lot with whom you have to talk to, why you are talking to them, who is responsible for ‘x’, and for ‘y’, or to what extent I [am responsible for that]” [B - EBTR - UX1]

N6—Having professional input on UX design

Need to have a professional focused on UX design, as well as understanding how to find this professional, a possible alternative is to train a member of the startup to work with UX design

4.1.7 Documenting UX Design Artefacts and Decisions (N7)

Our findings revealed that for both startups it is not easy to manage the documentation updating since they have reduced time to spend working on documentation. In Startup A where there are no UX designers, the prototypes and the design of user interface flows are the most common artefacts documented. Most of the documentation of UX issues was stored in the ticketing system (i.e., Meistertask tool) without using specific UX-related practices or tools.

“(...) to explain our flow: we use GitLab as a repository, and we have the issues, we create an issue in GitLab and it automatically creates it in the Meistertask tool.” [A - interview - DEV2]

However, the startup members demonstrated that they could not easily reuse their past experiences. A knowledge base from actions taken and lessons learned would contribute to more accurate decisions in the future.

“And in terms of our daily activities (...) we have [the need of seeing] more of our core knowledge, our learning scale, you know a better repository of what we learned, you know? As a ' brain' to which we would ask questions, for example, and it would reply "oh, you've done this before.” [A - interview - MKT]

On the other hand, we noticed that Startup B often documented UX design artefacts but they did not update these documents properly. The UX designer highlights that in the startup environment in which changes happen quickly, the team members often do not even have time to update original screen files, for example. Many artefacts are generated separately and they also reported that they often used a mix of UX design tools (e.g., Miro, Figma) for different purposes such as prototyping user interface flows, and conducting brainstorming ideation sessions. According to UX2, the elaboration of many different artefacts during the UX design process (e.g., personas plus user journeys plus prototypes) is not suitable because of the startup daily dynamics of doing everything fast.

“In fact, there is a lot of documentation that we should have, but there is no time for it. For instance, mapping the user's journey (...). As the startup environment changes very fast, some changes are a little scary, and not even the files of the original screen [of a product] are up-to-date. It is like a fight but we always try to keep the documents we generated separate. There are files and documentation [scattered] in Figma and drive. So, we keep it as [documented as] possible.” [B - interview - UX2]

Due to the lack of organisation of the documentation, they reported the need to have a close conversation with the team all the time. As with Startup A, the value of UX design documentation was recognised by Startup B, but keeping the documentation updated was a challenge they were trying to solve.

“(...) if there was a design of a [interaction] flow, the explanation of why it did that, the thought process to create that, that would already give us another view [about the documentation]. I would not spend so much time talking to people or looking at the site trying to remember how it was created, if it had actually been documented it would be much easier, [people could] read [information] in 15 minutes there and understand it.” - [B - interview - UX2]

Increasing documentation of UX design artefacts and decisions can be evidence that UX is part of the daily work of startups. In this sense, they need to have a professional responsible for the UX work and at the same time have knowledge on it. Moreover, as the team will be responsible for UX documentation the startups need to have a better description of jobs regarding UX work.

N7—Documenting UX design artefacts and decisions

Need to document both UX design artefacts that were generated and UX design decisions. This documentation, no matter how much time it takes to start, helps save time when these artefacts and decisions need to be revisited

4.1.8 Documenting Demands Coming From Users (N8)

Receiving too much feedback from users can cause this information to get lost and not be used to improve the product. So, the startups need to document demands coming from users (N8). This need is related to the documentation of user feedback, including reporting problems, suggestions for new features, or any other improvements. As stated by CE from Startup B:

“Something very important for my team is that we report this feedback (...), we get an email from a player saying something does not work, so, we use Discord and have a feedback channel from the community” [B - interview - CE]

At both startups, users' demands are documented in the ticket systems. For Startup A, registering user demands allows management and tracking of reported issues. Startup B pointed out that only documenting may not be enough by arguing that they need the information to be accessible to all teams. “Documenting demands coming from users” (N8) leads to “bringing together different sources of user information” (N2), since such information can come from different channels with users. However, practitioners still don't know how to put it all together in a more structured way, as seen in the quote below:

“We have these various communication channels [with users] and each of them can report a navigation problem, a user experience problem, or even a bug. Really [requests arrive] from everywhere. Today, it is still hard work to put it all together and prioritise these items” [B - interview - PO]

N8—Documenting demands coming from users

Need to document the feedback, demands, suggestions, and complaints that arrive through the service/support of users and other points of contact with users

4.1.9 Understanding the Value of UX Work (N9)

Our findings show that even when the startup does not have a UX professional the teams can see the value of UX work. According to the technology director, the teams of Startup A already recognize the importance of UX work but do not yet apply it systematically. From the perspective of TD, the value of UX work should be in the mind of all professionals.

“I believe that some areas understand the value of UX work but do not yet apply it (...) the areas that need to recognise that value already do it without having the need of someone from the UX area to carry out this work.” [A - member checking - TD]

During the interviews and the EBTR meeting, Startup A participants demonstrated that they understood that having an understanding of UX work was important for all team members and not just for a UX professional. But they pointed out that they do UX work in an ad-hoc and reactive way, and that they need to do more and learn how to avoid future problems.

“So, we need to learn a lot about UX [work], because we were just doing it. And I would say that we did little UX [work], and the fact of doing little showed us that we need to do more and we could have avoided several things [problems] (...)”. [A - interview - MKT]

Nonetheless, for the PDM of Startup B, the value of UX work will be understood when the professionals share and make the results of UX work visible to the team. In Startup B, the UX designers have delivered presentations to the teams with the results of the user research that they conducted. In many cases, user research was carried out by UX designers with the collaboration of other team members, for instance, developers. During the EBTR meeting, participants pointed out that seeing the boards with user research results and watching the presentations of the results helped them to understand the positive impact of UX work on the design.

Those that participated in the user research activities highlighted that their memories of their interactions with the users helped them understand better the value of UX work to product quality. Thus, “understanding the value of UX work” (N9) leads to internally “promoting UX work culture” (N11) to stimulate their teams’ engagement in UX work:

"I noticed that the professionals opened their eyes (…), they said “this has value, let us start looking a little more carefully at UX, or UX initiatives” [B—interview—UX1]

In addition, “understanding the value of UX work” (N9) leads to “understanding how to start doing UX work” (N14), which can be a challenging task even for experienced professionals, as Startup B's UX expert states:

“Last August, I was frustrated because I tried and it didn't work. So, I tried to find where things went wrong. Also, because I've never worked in companies where I was the first [UX professional]. My situation was ‘hey UX1, what do we do?’ and I was like ‘I don't know! I don't know either’ ” [B - interview - UX1]

N9—Understanding the value of UX work

Need to understand the value that UX work can bring to the startup, and the benefits and return on investment that UX work is capable of bringing

4.1.10 Identify UX Insights From User Data (N10)

Once they have plenty of information gathered in one repository that they can consult, startup professionals can make decisions based on user data, rather than on assumptions, gut feelings, or personal opinions. As stated by Startup B, about how they used to do UX work before having a UX professional in the company:

“(...) they even had a concern with UX [as a product quality], but very much based on feeling and history, and without [applying] any process, interviews, opinions, data [to UX design].” [B - interview - UX1].

It may also happen that some authority or leadership figure in the company wants to participate in UX related decisions and, if there is no UX specialist with research and data to present, the decision may be up to the leader's opinion:

“(...) so we have a culture of integration. Sometimes it may seem like a very simple thing, “a list of material that will go into the app”, but our CEO wants to validate it, he wants to participate, he always participates, a common saying from him is: “the concern with user experience can't generate doubts, if we have to interpret it, then let's do it another way. It has to be as simple as possible, as clear as possible” [A - interview - AT]

“Identifying UX insights from user data” (N10) facilitates “responding to user data” (N1). By analysing data from different sources, professionals can extract insights to make better decisions on UX issues, as commented by the UX expert from Startup 2:

“I know this makes the project take longer, but it's important to bring in more data from the business intelligence people, analyse data first, then think collectively with many areas of a solution (...) because sometimes we spend time and money on something that we are not sure will work” [B - interview - UX2]

N10—Identifying UX insights from user data

Need to make decisions related to the product based on user data, decreasing the use of assumptions, feelings, or personal opinions

4.1.11 Promoting UX Work Culture (N11)

Our results revealed that in addition to “understanding how to start doing UX work” (N14), the professionals of Startups A and B were concerned with “promoting UX work culture” (N11). In Startup A, the professionals revealed their concerns with doing UX work uncoupled from the usual team activities and without communicating the results to other startup members. Consequently, little working history can be produced and shared throughout the startup in terms of which UX design activities worked and which did not. Time pressure is another point that can impact negatively on “promoting UX work culture” (N11). And if a focus on UX is not part of the culture, UX work is left out.

“The problem is not doing it; it is redoing it. Because then you waste time. It's really that lack of talking and understanding the problem of this, this and this, how everyone is a bit desperate, needing things asap, you go there and do it as fast as possible and maybe you didn't need that much.” [A - interview - DEV2]

For Startup B, “promoting UX work culture” (N11) requires involving professionals other than UX designers in the UX design activities. Also, they need to understand the importance of the designer role and the benefits of UX work. Disseminating knowledge about UX work and presenting results are good ways to promote this culture in the company.

“I think there are three points: first it is a matter of time; second it is a cultural issue, for the company to understand the importance of the UX designer, the importance of this in the product (…) maturity; and, thirdly, we need to play the role of facilitator (...) It is part of the UX designer's job to be that evangelist in the company.” [B - interview - UX2]

N11—Promoting UX work culture

Need to promote UX work culture in several ways, such as: sharing knowledge of UX, engaging developers with UX issues, integrating development teams with UX design activities

4.1.12 Improving Communication Between Teams (N12)

In addition to all the needs already mentioned, startups also recognise a need to improve communication between teams from different areas of the startup. Often, in the daily rush, startups can face scenarios of a lot of pressure concerning what they have to do and a great lack of alignment between different areas of the company. Another aspect of improving communication is taking advantage of the background of new people who have joined the company, what they have experienced and worked with. Often, due to lack of communication, team members do not know each other's strengths:

“(...) for example, this discovery and delivery process, so I made a presentation to the PDM and the CEO talking about my experience and they saw it made sense, it worked there. But one can take more advantage of the background of the new people who have been out of that context, they have a lot to add. A lot of it is the result of our history and of what we know.” [B - interview - UX2]

N12—Improve communication between teams

Need to improve communication between the different teams that make up the startup and work directly with the product. This better communication also makes use of the diverse background of the teams

4.1.13 Defining Roles and Job Description for UX Work (N13)

Due to the context of Startup A that had small teams, some professionals accumulated roles such as full-stack developer, for instance. In the same way, they saw that the solution was to have a team member performing the UX design role.

The members of Startup B agreed that a job descriptions bring clarity to the responsibilities and also the delimitation of everyone’s role. As Startup B has experienced UX work they could see that UX professionals should have different skills when compared to other roles. Additionally, for UX2, the UX designer should act as a facilitator to encourage others to collaborate in UX design activities.

“I had even talked to the PDM that we need to prepare more our UX designers to go after things and play the role of mediator, facilitator, because sometimes other people who are not from our area don't realise that they can collaborate; so, the UX designer's role has to be that of calling them [other members] to be closer and showing them that they can give their opinion too. That's the first thing we need to do, and it's easy to get started. Make people understand that they have a stake in that solution, that they can collaborate.” [B - interview - UX2]

N13—Defining roles and job description for UX work

Need to define the role of the UX designer, product designer, or any professional who is involved with UX work, as well as their responsibilities and job description

4.1.14 Understanding How to Start Doing UX Work (N14)

From the results of Startup A, we observed a concern about how to start doing UX work. During the interview, the UI designer also reported that they struggled with understanding what is UX.

“In fact, I've been hearing for a long time about UX, interaction and there's so much stuff on the internet, for instance, courses, so many people talking about it, sometimes I think it's even confusing, you know? Defining what UX is, is difficult. And I've been trying since last year to study more about it, to understand more so that I can actually start implementing this with the people in the company. I have this will, but UX is a lot of things and sometimes it gets very confusing.” [A - interview - DS]

In the case of Startup A, where there is no UX professional, “understanding how to start doing UX work” (N14) comes up within a context where there are no resources to hire a UX professional. Usually, this need means applying further techniques and methods, and that requires more work. For this reason, startups are unsure how they can make UX work part of their activities without increasing the team’s workload. In many cases, “understanding how to start doing UX work” (N14) leads to “promoting UX work culture” (N11) to facilitate the engagement of professionals with UX work:

“(...) only after I delivered a large document, something like 100 slides, which was extremely tiring, I gave a presentation to the whole company. People were amazed, 'Wow! Did he do that? This is really cool!' However, I hadn’t done it all, most of the time I was just a facilitator. The engineering people attended the workshop along with other people, but they did not understand what was all that being done for. Later, they realised 'that is cool, I participated in this too!' So, they realised that dedicating time to that [UX work] could actually generate [good] results” [B - interview - UX1]

N14—Understanding how to start doing UX work

Need to understand how the startup can start doing UX work, i.e., approaches, methods, techniques and practices that can be adopted, the activities which can be done first, and how it can start

4.2 Initial Theoretical Framework

Theorising entails practical activities of engaging the world and of constructing abstract understandings about and within it (Charmaz 2014). In a theorising process, a set of well-developed categories (e.g., concepts, themes, dimensions) are systematically interrelated through statements of relationship to form a theoretical framework (Strauss and Corbin 1990). In this study, after identifying the relationships that emerged from the data, the authors discussed the whole, including the relationships among each of the 14 UX work-related needs, as shown in Fig. 5. This was based on our experience with qualitative methods, software engineering, and UX work (see beginning of Section 3). From this discussion, we designed an initial theoretical framework as presented in Fig. 6.

Fig. 6

Initial theoretical framework of UX work-related needs

From our initial theoretical framework, we identified two theoretical themes linked to our research question and two core categories that cover two sets of UX work-related needs (see Fig. 6). The needs that startups have related to UX work were split into two theoretical themes: key needs to improve the UX of products and needs related to fostering UX work. The first theme encompasses seven needs (i.e., N1, N2, N3, N4, N5, N8, and N10) which are directly related to improving the user experience of their products (on the left of Fig. 6). We claim that these needs can be fulfilled with the proper application of UX methods and techniques (i.e., by conducting UX work). In our analysis, we highlight “conducting product research/evaluations with real users” (N5) as a core category in this group.

The second theme encompasses seven UX work-related needs (i.e., N6, N7, N9, N11, N12, N13, and N14) that support startup professionals in putting UX work into practice. These needs are critical to successfully driving UX work and evolving it. Most of them require the involvement of startup professionals across the company. In this theme, the core need category is “understanding of the value of UX work” (N9).

To achieve a higher level of abstraction and therefore facilitate the comprehension of our results, we also classify UX work-related needs into four groups: (1) customer and user information (N1, N2, N4, and N8); (2) UX measurement and metrics (N3 and N10); (3) UX practices and skills (N5, N6, N7, and N13); and (4) UX value and culture (N9, N11, N12, and N14). These groups are listed at the bottom of Fig. 6 where we use different colours to identify the needs that belong to each of them. The “customer and user information” group covers needs related to feedback, demands, suggestions, and complaints received through customer service and other touchpoints between the company and users. The “UX measurement and metrics” group covers needs related to the collection and use of usage data, as well as metrics and indicators involving the quality of UX aspects. The “UX practices and skills” group encompasses needs related to the use of methodologies, techniques, and tools used to put UX work into practice, including UX documentation and skills needed by specialist or non-UX professionals. Finally, the “UX value and culture” group covers needs related to the behavior of UX professionals and other areas regarding the recognition of the value of UX and the development of a UX culture at the organizational level, including communication and alignment between teams.

4.3 Validation (Member Checking)

As one way to validate the set of UX work-related needs identified (Section 4.1), we undertook two sessions of member checking involving the key-members from startups A and B (identified in Table 1). Member checking (also known as member/respondent feedback, validation, or review) is a relatively common practice in qualitative research to take ideas back to research participants for their confirmation, to improve the accuracy, credibility, and validity of a study (Lincoln and Guba 1985). The technique can be used both to increase research credibility and to involve the participants in the collaborative construction of the research outcomes together with researchers (Iivari 2018).

In our study, two researchers took part in the member checking sessions, where one was responsible for leading it and the other for making notes. The interviews were carried out using Google Meet and video recorded with the prior consent of the participants. These interviews lasted 50 and 35 min with Startups A and B, respectively. After a brief introduction about our goals, we conducted the interviews in two steps. In step 1, we first presented the 14 UX work-related needs to participants, one at a time. As each category was presented, we asked participants to what extent they felt the startup faced this need. We used a 4-point Likert scale (i.e., fully agree, partially agree, partially disagree, and fully disagree) to get the level of participants' agreement. Additionally, we asked them to justify their responses for each need. To collect further data, we also asked them to justify their answers. The member checking results gave us the opportunity to refine the UX work-related needs (e.g., renaming or improving their description). Additionally, we found that the two studied startups have different views regarding some UX work-related needs, as we report below.

During member checking, Startup A partially agreed with the need for “identifying real points of improvement through feedback” (N4), emphasising the importance of working actively on problems that affected users even before receiving a complaint: “I think feedback has to exist as no organisation is smart enough to do this automatically, but I think this could be done more proactively. So, I agree partially, I think there has to be an automated part in this process too, and not just waiting for user feedback.” [A—member-checking—TD]. However, Startup B totally agrees with this need by claiming that an improvement point needs to benefit as many people as possible but there are situations where this assumption can be changed and the improvement areas are prioritised due to the “voice” and the reputation of some users. Regarding this need, we found that startups have contradictory views of the priorities for improvement areas for their products/services.

As for “identifying UX insights from user data” (N10), the member from Startup A totally agreed, stating that the data gathered on the usage of their products helped them to make better decisions. Nevertheless, the Startup B member partially agreed with this need because, for him, not all decisions need to be based on data. He argued that designer intuition and experience must also be taken into account. The next quote reveals his position regarding this need: “but I don't think that decision making should be done 100% based on data without taking into account the intuition and experience of the designer. In that case, I partially agree [with this need]” [B—member-checking—PDM].

Startup A also partially agreed with “having professional input on UX design” (N6) and “defining roles and job descriptions for UX” (N13). The Technical Director from Startup A argued that as the technology team is small, one member could conduct the UX activities: “I believe that every [startup] team starts with the UI person working on the UX part and doing both. So, [this professional] does UX and does UI, goes to UX and comes back and does UI and that is how everyone did it in the past” [A—member-checking—TD]. Although they recognize that new skills need to be developed to perform the UX work, the investment in the UX area was not the company's top priority at that moment. In Startup B, our findings revealed a different perspective. In the past, they could not hire a UX professional due to a lack of resources, and although UX was always considered important it also was not their priority. When the startup received the second round of investments, they were able to hire a UX designer who started to introduce UX practices in their product development. After a while, they realised that the UX work demand was high, and decided to hire another UX designer. The member of startup B highlights the importance of the UX professional and the change in the company's mindset regarding UX work: “So, if you don't have that person and a strong presence of that UX thinking coming from up there, from the decision-makers, it [UX work] doesn’t happen” [B—member-checking—PDM].

5 Discussion

Our research question is: What do software startups need from UX work? To answer this question, we have investigated the needs that startups have related to UX work by gathering data with practitioners from two startup companies through interviews and retrospective meetings. According to Klotins’ et al. model for startup evolution (2019a), both startups were at the stage where the product was stable, and the market size, share and growth rate were already established. At the time of our data collection, both were focused on launching new variations of their products.

By analysing the data from these two startups, we identified 14 UX work-related needs and the relationships among them (Fig. 5). We also developed an initial theoretical framework (Fig. 6) where the identified needs are linked to 2 theoretical themes: (i) key needs to improve the UX of products and (ii) needs related to fostering UX work. In addition, we grouped UX work-related needs into four groups (i.e., customer and user information, UX measurement and metrics, UX practices and skills, and UX value and culture), as shown in Fig. 6. It is important to point out that we present initial results since they are based on two startup companies in a particular stage of evolution (Klotins et al. 2019a). We will discuss this point in detail in Section 6. In the following, we discuss how our findings relate to the existing literature about startups and research on UX work considering the four groups of our initial theoretical framework.

We identified four needs in the customer and user information group (N1, N2, N4, and N8). Collecting customer feedback is a traditional and very valuable practice for startups at all stages of product development (Hokkanen et al. 2015; Lindgren and Münch 2016; Hossain et al. 2019). As seen in our findings and in the literature, most of the time customer feedback is collected by the support team (Hossain et al. 2019). When startups reach a stable version of the product, professionals rely on customer feedback to maintain the product, fix the bugs, and update system features according to customer/users demands (i.e., “responding to user data”—N1) (Hossain et al. 2019). Although startups tend to ignore aspects related to documentation, structures, and processes (Giardino et al. 2016), we found that both startups have met the need for “documenting demands coming from users” (N8) through ticket-based tools that also help startup professionals manage the lists of features to be implemented or modified (Giardino et al. 2016; Ogunyemi et al. 2019). Nevertheless, professionals struggle to prioritise feedback or select the proper feedback for the execution of improvements that will satisfy as many customers as possible (Hossain et al. 2019). Lindgren and Münch (2016) and Klotins et al. (2019b) mention that some startups already have a large customer/user base which makes the data exploration difficult. In this way, “identifying real points of improvement through feedback” (N4) can be difficult for startups. In addition, we found that selecting and prioritising customer feedback can become an even more arduous task when professionals receive input from customers/users across different channels and do not yet have the know-how for “bringing together different sources of user information” (N2). In summary, from this discussion, N1 and N8 have been identified in previous research, while N2 and N4 propose a refinement of what has been discussed in the literature so far.

Two of our needs are related to UX measurement and metrics (N3 and N10). The literature suggests that startups usually collect data from actual usage, i.e., user analytics, to improve and support their UX design (Hokkanen et al. 2016b; Lindgren and Münch 2016); however, they also point out that startups do not benefit from utilising it well. In the investigated startups, we noticed a certain frustration because the professionals are still not able to take advantage of all the information that they collect from users to effectively use the information and start “identifying UX insights from user data” (N10) to improve their products and services. Kuusinen et al. (2019) and Lindgren and Münch (2016) highlight that startups, in general, would benefit from improved skills in user-oriented data analytics, including skills in UX design to utilise data and successfully guide design decisions. In addition to the users’ feedback, startup professionals can rely on product metrics (e.g., web-based statistical hypothesis testing, such as A/B testing) (Giardino et al. 2016; Lindgren and Münch 2016). In our study, we found that only Startup B formally collects product metrics and can start “identifying problems through these metrics” (N3). However, they recognise that they need to establish specific metrics to properly monitor UX issues. N3 and N10 together can support startups to make decisions based on user data rather than using the data informally. Although aspects of N3 and N10 have been identified previously our work refines them to be more specific. In our refinement, we point out the importance of automating the use of metrics and their potential benefits to UX work.

Four needs fall within our group UX skills and practices (N5, N6, N7 and N13). Regarding the need for “conducting product research/evaluations with real users” (N5), the literature discusses that startups often evaluate prototypes and products with friends (Hokkanen and Väänänen-Vainio-Mattila 2015). Moreover, startups generally use a limited set of UX design practices (Hokkanen and Väänänen-Vainio-Mattila 2015). These organisations usually start with a limited product version based on their own hypotheses and then iterate the version with real users and customers (Hokkanen et al. 2015). The literature points out that startups generally do not strictly follow any UX process (Kuusinen et al. 2019). Instead, they tend to select UX practices for convenience reasons, as needed and under certain circumstances (Kuusinen et al. 2019), depending on the product evolution status and maturity stage (Klotins et al. 2019b). The literature has pointed out that the lack of knowledge and a specific UX professional to conduct UX work can hinder the adoption of UX practices (Hokkanen et al. 2016b). In our study, we found that more than a UX expert, startups need “having professional input on UX design” (N6) which is important to conduct the work using proper practices and “documenting UX design artefacts and decisions” (N7). The need for “documenting UX design artefacts and decisions” (N7) was relevant for startups A and B to maintain a useful knowledge base to inform their future decisions.

Documenting UX design artefacts and decisions associated with them was regarded as important by both startups because when their product evolved, or a new team member joined, this documentation allowed them to trace changes to the decisions or explain previous decisions. This might be the case because the products from both startups were stable, and both startups already had an established customer base at the time of our data collection. Nevertheless, it is well known that development teams in startups are often small and lack the resources to hire UX professionals (Liikkanen et al. 2014; Hokkanen and Väänänen-Vainio-Mattila 2015). While the team is small, professionals often take on more roles to deliver the product to the market as quickly as possible. However, new professionals will need to be hired as the startup begins to scale and grow its customer base (Unterkalmsteiner et al. 2016). At this stage, the startup undergoes restructuring which may include clearly “defining roles and job description for UX work” (N13). Surprisingly, we found Startup A which has a smaller team has a well-defined job description and roles for the development team, although they do not have UX experts; while Startup B which has a larger team with UX designers (organised in squads) does not yet have all roles clearly stated. In short, considering the needs of the UX skills and practices group, we see that N5 is widely discussed in the literature; however, the other needs, i.e. N6, N7 and N13, were refined to be in line with the characteristics and demands of the startup context as discussed above.

Four needs are in the UX value and culture group (N9, N11, N12, N14). The literature reports initiatives to promote UX work in startups (Hokkanen et al. 2015) with the involvement of real users (Hokkanen and Leppänen 2015), mainly in the inception phase of the product. The literature points out that there are studies concerned with making the cultural, organisational and team better characteristics of successful software startups to improve their cooperative and human features (Unterkalmsteiner et al. 2016; Saad et al. 2021). However, studies are still lacking on how to start “improving communication between teams” (N12) in software startups. We found that a lack of alignment between teams hinders the smooth running of UX work. “Promoting UX work culture” (N11) can also help improve communication between teams. Rather than focusing on the importance of UX to product development (Hokkanen et al. 2016b), N11 suggests a set of actions that can aid startups to make UX work benefits more evident to non-UX professionals (e.g., developers). UX experts from Startup B have been conducting design workshops involving professionals from different areas to promote UX culture. However, a lack of alignment with the decision-makers of the business area, for example, discourages the team to plan UX work better in the long term. The literature has discussed that startups would benefit from more strategic planning taking into account design ideas that are aligned with business goals from the early stages (Hokkanen et al. 2015; Guerino et al. 2021). By laying out a strategic plan to align UX work with business needs, professionals can clearly start “understanding the value of UX work” (N9) and “understanding how to start doing UX work” (N14) if they have not already done so. Although the literature has widely discussed that startups recognise the value of a good user experience, little has been explored about the value of UX work; this aspect is covered by N11 and N9. Moreover, we did not find studies that investigate N12 and N14 in the context of startups.

Of the 14 needs identified through our research, 3 have been identified and discussed in the literature (i.e., N1, N5 and N8) and 11 of them are new or provide refinements of findings from previous research. In addition, our research extends previous work by highlighting the relationships among the 14 UX work-related needs. These relationships indicate dependencies between the individual needs and between the themes. For example, we found that “responding to user data” (N1) depends on (leads to) “documenting demands coming from users” (N8). Some needs considered as “key needs to improve the UX of products” can be met with the proper application of UX methods and techniques, whereas other needs depend on the actions as a whole, involving startup professionals from different areas. Understanding the relationships among needs is important to improve the planning of UX work and the proper allocation of resources to make UX work successful.

6 Study Validity

As suggested by Runeson and Höst (2009) for qualitative case studies, we discuss the trustworthiness of our work based on Robson and McCartan (2016) considering threats to validity in flexible designs, i.e. bias and rigour, and generalizability.

6.1 Threats to Validity in Flexible Designs

The description of our multiple case study covers all the steps we followed to collect and analyse the data. In Section 3, we provide an overview of the methodology and also an explanation of all the methods adopted in each step. Moreover, we describe in detail the setting of each startup we studied (see Table 1). We documented the data collection scripts and analysis procedures throughout the study which allowed us to produce an accurate report of the study. Our methodology gives details to support its replication in other studies.

We carried out data interpretation by taking into account common perspectives on UX work and software startups. To avoid different interpretations of these terms, we based our definition of UX work on Saad et al. (2021), Unterkalmsteiner et al. (2016) and Hokkanen and Väänänen-Vainio-Mattila (2015). Our perspective of software startup characteristics is based on the work of Paternoster et al. (2014). Our qualitative data analysis followed the coding methods proposed by Charmaz (2014) from which we conducted successive examinations of the data to evolve the codings we found. To achieve a richer understanding of our empirical data, we conducted the data analysis with the participation of more than one researcher in all the stages. In all coding steps, the researchers involved followed the same script to examine the data. Two researchers independently conducted data analysis and held discussion meetings in the initial and focused coding phases. The double-checking conducted by two researchers aided in evolving the definition of the codes that emerged during the analysis. During the theoretical coding phase, all researchers (i.e., the authors of this article) discussed and refined the needs and the initial theoretical framework. All researchers also participated in the construction of the initial theoretical framework. Moreover, the key members of the two startups validated the needs, which gave us confidence in our findings. We did not adopt any a priori theory when conducting the data analysis.

6.2 Bias and Rigour

We discussed the bias and rigour based on the recommendations of Robson and McCartan (2016). Issues of bias and rigour may be found in any research methods (case studies, ethnographies, etc.) that involve the interpretation of people's activities. Since we conducted a case study, in this section we discuss how we handled bias and rigour in our research. To establish a trusting relationship with the study participants, we conducted meetings with key contacts who helped us to make the participants aware of the study's aim. We also sent email messages to participants prior to each data collection activity. As we carried out different phases of interviews and the retrospective meetings, we were able to have prolonged involvement in the fieldwork by keeping contact with the key members and other collaborators. We collected a significant amount of data from several professionals who had different backgrounds (i.e. UX designers, developers, etc.) which supported data triangulation. Our data collection was conducted separately at each startup and in three rounds (i.e., key members interview, startup members interview, and retrospective meeting), allowing us to collect data incrementally. This allowed us to gradually achieve maturity in our understanding of how the UX work was carried out in each startup. At least two different researchers took part in each data collection round which provided us with an observer triangulation perspective. The rich and detailed set of data and the viewpoint of different researchers gave us confidence in our data interpretation. Additionally, all the partial results of each coding step were regularly discussed in debriefing sessions with all the researchers to avoid any influence of individual opinions. And, we conducted member checking meetings with members of the two startups to verify whether our interpretations of the needs were correct.

Reliability issues are related to the methods and practices used to produce consistent results. We adopted a set of procedures to guarantee data integrity (i.e. an audit trail). All the video recordings, notes in digital format and documents were maintained in an external hard drive as well as in cloud storage to which only the project researchers have access. Due to COVID-19, we carried out data collection sessions online and recorded them in video format, which allowed the researchers to revisit the data collected as many times as they wanted during data analysis. All data were transcribed to text, thus avoiding different interpretations for the researchers involved in creating and refining the codes. The three stages of data collection followed scripts previously elaborated and validated by at least one researcher with experience in qualitative studies in the industry. During the retrospective meetings with the startup members, we encouraged them to report aspects related to activities which allowed us to better understand the UX work carried out in the company. As mentioned in Section 3, more than one researcher conducted data analysis (coding) at each stage.

6.3 Generalizability

Internal generalizability refers to the generalizability of conclusions within the settings studied. In our study, we collected data from the perspective of professionals that played different roles within their startups. We explored the viewpoint of the individual professional in relation to the startup's software team's work. By carrying out the retrospective meetings, we were able to consolidate the views on UX methods and practices the startups used during the development of their software products. We considered that our results were consistent with the work of each startups’ teams. As mentioned at the end of Section 6.1, key members of the studied startups validated the needs we report in this paper. These informants reported reasonance and usefulness (Charmaz 2014) of the needs. However, the initial framework that groups the needs was not discussed with them and is a limitation of our work to be addressed in the future.

For external generalizability, our work is limited by studying two startups that operate in different market segments and with particular settings related to UX work. For instance, Startup A did not have a UX professional in the company while Startup B did. While Startup B already had internalised knowledge about UX, Startup A had a more immature vision about UX. Unlike Startup A, Startup B already had external investments that allowed use of financial resources and time for UX work. The data collected on these two different startup contexts allowed us to obtain a degree of abstraction about some common UX needs for these two somewhat different scenarios. However, we understand that there are contextual factors related to the startups that can affect our findings. During the analysis, we relied on Paternoster et al.'s literature so that the needs identified were related to the main startups' characteristics proposed by the authors (Paternoster et al. 2014). Taking into accout the qualitative nature of our study, we can not argue that our results have statistical generalization. However, as in any qualitative study, we argue that our results are theoretically generalizable to other startups that are similar to the ones we studied specially regarding their stage of evolution, i.e., the product was stable (Klotins et al. 2019a). We do not rule out the need to conduct a similar case study in early-stage startups and startups with more maturity as future work. These new investigations can allow us to understand the intensity and complexity of our needs from the perspective of startups’ maturity.

7 Conclusion and Future Work

We conducted a multiple exploratory case study to investigate how UX work has been carried out in software startups, specifically focusing on what they need from UX work. The case study was conducted in two organisations in the same stage of evolution (Klotins et al. 2019a), but with different characteristics regarding the type of product developed, market segment, and the conditions in which UX work is conducted. Data collection was carried out in different rounds using interviews and retrospective meetings. In total, 16 professionals mostly in software development positions participated in the study. We analysed the data collected adopting coding techniques of the constructivist grounded theory approach with the participation of all the paper authors. We employed member checking to validate our results with startup employees.

Our analysis resulted in 14 UX work-related needs which emerged from the daily practices of software development in the two startups. From these results, we proposed an initial theoretical framework that highlights two theoretical themes linked to our research question, encompassing two sets of needs: (1) key needs to improve the UX of products and (2) needs related to fostering UX work within the organisation. The former set of needs refers to needs that can be fulfilled by using UX approaches, methods, and practices, while the second one can be seen as fundamental needs that support startups putting UX work into practice. Furthermore, in our theoretical framework, we group the identified needs into four groups, namely customer and user information, UX practices and skills, UX measurement and metrics, and UX value and culture. These groups show the different perspectives which are impacted by the needs.

Our contributions will benefit researchers and practitioners who work in software startups. From a research point of view, our work provides an in-depth investigation of how UX work takes place in the settings of software startups. We contribute to covering a gap in the literature where few studies have focused on UX work in software startups. In addition, we presented our study in detail so other studies can replicate it. From a practical perspective, software startups in similar contexts can use our theoretical framework as a starting point to identify the needs present in their organisations. Based on the needs identified, they can carry out actions to either fulfil those needs or mitigate their impacts on the products they are developing. Startup professionals often recognize the benefits of producing software with a good user experience because it has an impact on the organisation's business. However, the fast-paced environment where startups operate and the lack of human and financial resources make it difficult to actually carry out UX work. Sometimes, startups do not have professionals that could support them in understanding how to perform UX work. Our theoretical framework provides software startups in the same stage of evolution (Klotins et al. 2019a) with a positioned view of UX work-related needs at a high level of abstraction, which facilitates the identification of what these organisations need from UX work.

Our findings also opens up other opportunities for future investigations. Although our theoretical framework shows the impacts and influence between needs, other opportunities remain for the further exploration of these relationships. For example investigating the degree of influence that these relationships have on teamwork. In the future, we plan to explore some solutions for the needs that facilitate putting UX work into practice in software startups.

Appendices

Appendix 1

Table 6

Table 6 This appendix contains a table of UX work-related needs and relevant codes related to each, identified in the focused coding stage

Appendix 2

Table 7

Table 7 This appendix contains a table of the examples of relationships among UX work-related needs identified in the theoretical coding stage