Communication challenges in User-Centered Agile Software Development and the role of UX designers towards them

(1)

Communication challenges

in User-Centered Agile Software Development and the role of UX designers towards them

Nguyen Thi Thu Linh

Master's thesis

School of Computing Computer Science

July 2021

(2)

UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Joen- suu School of Computing Computer Science

Student, Nguyen Thi Thu Linh: Communication challenges in User-Centered Agile Software Development and the role of UX designers towards them

Master's Thesis, 61 p.

Supervisors of the Master's Thesis: PhD Solomon Sunday Oyelere July 2021

Abstract: Agile software development (ASD) and user-centered design (UCD) have made powerful impacts to the software development business. Current literature indicates multiple obstacles towards successful integration between these two disciplines. This thesis investigates, in particular, the challenges in communication between design and development departments within a software team. An additional aim is to nd out how assigning dedicated user experience (UX) designers to a team impacts its design communication process. In-depth interviews were carried out with industry professionals in various roles, including designers, developers, management and other stakeholders. The ndings show that (1) organisational separation, (2) inecient communication methods as well as (3) the cultural dierence between design and development are some core reasons for the challenges. Instating a UX designer to the team boosts product quality and brings communication improvements, especially after long periods of collaboration with development side. However, teams risk complicating their own processes by intro- ducing new roles, and designers can easily be siloed with responsibilities in early stages of the product. It is advised that organisations invest time and resources in integrating UX designers into ASD environments for it to be meaningful and truly successful.

Keywords: user-centered design, user experience, Agile, communication, integration

CR Categories (ACM Computing Classication System, 1998 version): Software development, Software process, User-centered design

(3)

Forewords

This thesis was done at the School of Computing, University of Eastern Finland, in the nal semester of my Master's Degree Programme in Information Technol- ogy.

Studying in Finland opened the opportunity for me to work professionally as a user experience (UX) designer. With as much impact it has made to the software business in recent years, UX design - or user-centered design (UCD) in essence - is still seen in some parts of the industry as an add-on, instead of an integral part of development. With this thesis, I aspire to expand my knowledge of UX and Agile development. Hopefully this will be a contribution to existing literature, and make a case for UX/UCD from the industry viewpoint.

There have been many hurdles on my journey towards nishing this thesis. The road was far more dicult than I had ever expected. I would like to thank all my teachers, classmates and coordinators who supported me in dierent parts of the process. I extend the deepest gratitude to my supervisor Dr. Solomon Sunday Oyelere, for the guidance he gave, the patience he showed and the freedom I was allowed to complete this work the way I would like it to be.

I thank all my friends and contacts who reached out and helped me with the interview process. I thank my employer, work supervisors and colleagues who trusted my professional capabilities and inspired me to choose this topic.

Finally, I am forever grateful to my family for treating me throughout my whole life with nothing but incredible support and patience. Thank you all for helping me reach this far.

(4)

List of abbreviations

ASD Agile software development

UCASD user-centered Agile software development UCD user-centered design

UI user interface

UCSD user-centered software development UX user experience

(5)

List of Tables

1 The 10 UCD commandments (Still, 2006) . . . 9 2 12 key principles of user-centered system design (Gulliksen et al.,

2003) . . . 10 3 12 principles of the Agile Manifesto (Beck et al., 2001) . . . 12 4 Benets of adopting Agile (Digital.ai, 2020) . . . 16 5 Key practices in integrating UCD and Agile (da Silva et al., 2011) 17 6 UCD and ASD integration challenges and conicts. Modied after

Jones (2019) . . . 19 7 Study participants and their roles . . . 23

(6)

List of Figures

1 UCD process ISO9241:210 (2010) . . . 8 2 Waterfall development, modied from Dima and Maassen (2018) . 11 3 Agile development cycle . . . 13 4 Software lifecycles comparison (Shore & Warden, 2008, p. 16) . . 14 5 One Sprint Ahead approach (Sy, 2007, as depicted by Kuusinen,

2015) . . . 17

(7)

1 Introduction

Since the introduction of the Agile Manifesto in 2001, Agile software development (Agile for short) has made great improvements in the software business, promot- ing early and continuous delivery of products to the customer while limiting the risk in development (Beck et al., 2001). However, it focuses on developing the product in a useful way and does not necessarily emphasize the goals and needs of the end-users (da Silva et al., 2018). As the software market is highly competitive nowadays, reliable and consistent delivery alone is not enough. Customers expect usable products (Constantine & Lockwood, 2002a; Ferreira et al., 2007a), which means the end-users should be able to reach their goals easily, intuitively, and with a pleasant experience. This is where User-Centered Design comes into play.

User-Centered Design (UCD), as a principle, can be applied to the design of anything that has a user. It takes the end-users into account, evaluates, and includes them into the product design and renement process (Ritter et al., 2014;

Fox et al., 2008). Developing a software product with UCD in mind brings signicant nancial and social benets to both the suppliers and users, as highly usable products tend to sell better and are more successful (ISO9241:210, 2010).

Given that in recent years, software business has priorities both rapid delivery to customers and end-user satisfaction, the integration of UCD into Agile software development is of greater interest than ever (Curcio et al., 2019).

Even though both Agile and UCD aim at producing quality software, they have conicts on a fundamental level. Agile promotes short and fast-paced iterations of development, focusing on delivering a product quickly. UCD on the other hand favors extensive upfront research and planning even before coding starts. Many studies have been conducted on Agile and UCD integration (Jurca et al., 2014;

da Silva et al., 2011), but they focus mainly on the practices instead of the people or social aspects involved.

In my working experience, Agile is usually led by the developers while UCD concerns the product management (or product design) team. The dierence in

(10)

nature between those roles - technical versus creative, left-brained versus right- brained - could add to the conicts between the methodologies, and impact the overall product quality. As a user experience (UX) designer who works closely with both product management and developers, I am particularly interested in the communication and cooperation issues between these departments, and how someone in my role can help alleviate the problem.

1.1 Problem denition

In recent years, Agile has become one of the standard practices in software development (Dingsøyr et al., 2012). Agile is an answer to the need from a highly competitive software industry, where the development process must be fast, exible, and ready to adapt to changes (Boehm, 2010). However, current Agile practices do not have explicit guidance on how to integrate UX values into the development process (Salah et al., 2014). Understanding users and including usability aspects in Agile processes would be extremely helpful for software practitioners.

UCD can be described by professionals using many terms - e.g UX design, usability design, user interface (UI) design - and as dened in ISO 9241-210, UCD concerns all aspects of the user's experience when interacting with the product, service, environment or facility (ISO9241:210, 2010; Hassenzahl, 2008). It is generally agreed that UCD in software development aims to create usable products which satisfy the end-user's goals while at the same time providing a positive experience (Hassenzahl, 2008; da Silva et al., 2018). Extensive research into the collaboration between UCD and Agile has been made, and while there are various benets, the integration is problematic and challenging (Salah et al., 2014; Brhel et al., 2015).

1.2 Research area

One of the challenges with designing good UX and usability in Agile environment is reaching a common understanding between design and development teams about the users' needs. Product designers and developers are therefore required to work in parallel: the rst provides insights into customers and the market,

(11)

while the latter contributes with technical knowledge on what can be implemented and how. However, the dierences in their areas of expertise can easily create misunderstandings (Øvad & Larsen, 2016).

Furthermore, dening the software requirements is problematic during initial phases of development, because end-users might be dicult to reach (Iivari &

Iivari, 2006; Grudin, 1991). In some cases, the product does not even have customers yet. Designers and developers need to work with some level of uncertainty and run the risk of implementing something that ultimately will not be used due to changes in requirements.

Lastly, despite the growing number of research on the challenges when integrating UCD into Agile, the people and collaboration side of that integration are not suciently studied and need to be addressed more (Jones, 2019; Brhel et al., 2015). UCD experts do not always have a dened role in the development process and often have to play multiple roles at once, adding to the collaboration issues (da Silva et al., 2013).

The thesis, therefore, focuses on the communication between UCD and Agile practitioners in a software team, the representation of UCD people in current software teams, and how those aspects aect the addition of UCD to Agile processes. The research is scoped specically around software organisations that have been using both Agile and UCD practices. We do not limit the size of the organisation or the maturity of the product, however, there should be people directly responsible for the UCD of the product.

1.2.1 Research goal and research questions

The goal of this thesis is to identify problems or challenges in the communication between designers and developers within a software team and to nd out how having a person or a team dedicated to UCD or UX design in Agile software development reects upon the quality of work. The study aims to expand on existing research on similar topics (see, e.g., Kuusinen, 2015; Jones, 2019), potentially providing insights and recommendations to software companies looking

(12)

to improve the UCD integration in their development process.

With the goals and problem denition in mind, we investigate the following research questions:

RQ1 What are the challenges in communication and understanding between design and development in a software team?

RQ2 How does having a dedicated UX designer in the development team address the communication challenges?

1.3 Research methodology

To answer the research questions, a exible design, qualitative research (Robson, 2011, p. 130-134) is conducted. The data collection method is focused, semi- structured interviews with 14 participants in various roles from dierent software companies that meet the research criteria. Interview sessions happen mainly during December 2020. Before that, I have gained an understanding of the software business as well as the internal dynamics of software teams by working as a UI/UX designer since January 2018. This helped with developing the interview approach and choosing interview participants that could provide the most insights into the research questions.

The interviews are recorded, transcribed, and translated to English where necessary. Thematic coding approached described by Robson (2011, p. 469) is used for analyzing the data. Finally, results are grouped into theme categories then studied to answer the proposed research questions.

1.4 Structure of the thesis

Chapter 2: Background introduces the theoretical background of the thesis. Relevant literature is reviewed on the subjects of UX design, product-based software development and the nature of communication within a software team.

(13)

Chapter 3: Research methodology describes the research approach, research context, and the employed data collection and analysis methods.

Chapter 4: Findings presents the analysis of the data collected in this study.

Chapter 5: Discussion goes back to the research questions and answers them with the ndings from chapter 5.

Chapter 6: Conclusion presents the conclusion from the research along with suggestions for future work. The design and limitations of the study are also evaluated.

(14)

2 Background

2.1 User-Centered Design

Since the late 1960s, it has been acknowledged that human factors research plays an important part in designing and dening technologies and computer systems (Adler & Winograd, 1992, p. 4; Ritter et al., 2014, p. 33). To quote Nickerson (1969), the need of the future is not so much for computer-oriented people as for people-oriented computers. User-Centered Design has since emerged as a product development approach that addresses that need. The term was coined in the 1980s and came to popularity after the publication of Donald Norman's User-Centered System Design: New Perspectives on Human-Computer Interaction (Abras et al., 2004). UCD can also be described by other terms: usage-centered design, user experience design, usability engineering, and so on (Ritter et al., 2014), but the exact meaning of it may vary in dierent studies (Gulliksen et al., 2003;

Constantine & Lockwood, 2002b; Karat, 1997).

Despite the many ways one can understand UCD, the general consensus is that end-user participation is highly emphasized in the product design and evaluation process (Ritter et al., 2014; Rubin & Chisnell, 2008, p. 12; Garrett, 2011, p. 17).

A good understanding of the users is indispensable to UCD practitioners. Norman listed Start with the needs of the user as one prescription for structuring the UCD process, and elaborates:

the purpose of the system is to serve the user, not to use a specic technology, not to be an elegant piece of programming. The needs of the users should dominate the design of the interface, and the needs of the interface should dominate the design of the rest of the system.

(Norman, 1986) 2.1.1 Usability

The ISO9241-11 standard denes usability as the extent to which a system, product, or service can be used by specied users to achieve specied goals with eec-

(15)

tiveness, eciency, and satisfaction in a specied context of use (Ergonomics of human-system interaction Part 11: Usability: Denitions and concepts, 2018).

For computer systems, usability can be understood as when a design is appro- priate for the users and for the tasks that users perform (Leventhal & Barnes, 2008, p. 15). (Rubin & Chisnell, 2008) further denes usability as the absence of frustration when using a system, and lists ve main attributes of usability:

Usefulness: the degree to which a product achieves a user's goal Eciency: the speed with which the goal can be achieved

Eectiveness: how the system behaves according to the user's expectation Learnability: the user's ability to make use of the system with a certain level of competence or training

Satisfaction: the user's perception of and feelings towards the system These attributes are line with earlier models of usability (Nielsen, 1993, p. 26;

Adler & Winograd, 1992, p. 44; Shackel, 1986). Thus, usability is an integral quality that should be considered since the beginning of the product lifecycle.

2.1.2 User experience

As the term user experience becomes widely used among the computer industry, multiple denitions of it exist (Law et al., 2009; Roto et al., 2011). According to Nielsen and Norman (2009), UX encompasses all aspects of the end-user's interaction with the company, its services, and its products. Hassenzahl (2008) denes UX as a momentary, primarily evaluative feeling (good-bad) while interacting with a product or service. It is also formally dened in the ISO9241-210 standard for developing human-centered systems as user's perceptions and re- sponses that result from the use and/or anticipated use of a system, product (ISO9241:210, 2010)

UX is closely related to UCD and usability, albeit being a wider concept (Väänänen- Vainio-Mattila et al., 2008; Lallemand et al., 2015). Supporting that idea, Roto et al. (2011) point out that even though UX design does not dier from traditional UCD in principles, it is inuenced by larger and more varied factors. Designing

(16)

for good UX and usability is therefore challenging, as it is dicult for designers to address all aecting factors.

2.1.3 User-Centered Design process

As stated in previous sections, the main aim of UCD is to create usable products that help end-users fulll their goals and needs. Carrying out UCD is thus an iterative process that should be done throughout and beyond the product development lifecycle (Gulliksen et al., 2003; Still, 2006). It starts from understanding the needs of users, then dening product design solutions according to that need, and nally evaluating those solutions against the initial needs (Figure 1). This process is repeated over and over again, until the product meets all user and organisational requirements.

Figure 1: UCD process ISO9241:210 (2010)

Because UCD inherits from many other UX disciplines, dening a set of method- ological constructs that guides design decisions is not an easy feat. Still (2006) suggests 10 UCD commandments (or principles) that would help practitioners reach their design goals and fulll users' requirements (Table 1).

(17)

Table 1: The 10 UCD commandments (Still, 2006) I. Thou must involve users early

II. Thou must involve users often

III. Thou must design for use in context (the product will be used in the real world, so design accordingly)

IV. Thou must keep it simple V. Thou must be polite

VI. Thou must know your users VII. Thou must give users control

VII. Thou must remember and design for emotionpeople feel as much as they think

IX. Thou must trust but verifytriangulation is the key

X. Thou must discover before designing and delivering, and thou must know that discovery never ends, even after delivery

Similarly, Gulliksen et al. (2003) have extended upon earlier works and studied UCD in a real-life project. They identied 12 key principles of UCD, summarized in Table 2. These principles emphasize that users must be the focus of UCD process, regardless of the methods or practical tools involved. This agrees with the view of Norman (1986) mentioned at the beginning of this chapter that the design of a product must follow the users, not the other way around.

(18)

Table 2: 12 key principles of user-centered system design (Gulliksen et al., 2003) 1. User focus The goals of the activity, the context of use, the users' goals,

tasks and needs should guide development

2. Active user involvement User participation should be early and continuous throughout the development process

3. Evolutionary systems development The development process should be iterative and incremental

4. Simple design representations Design must be represented in ways that can be easily understood by users and stakeholders

5. Prototyping Prototypes should be used to visualize and evaluate design solutions in cooperation with end-users

6. Evaluate use in context Baseline usability goals and design criteria should be identied early and used to control the development

7. Explicit and conscious design activities The development process should contain dedicated design activities (e.g. user interface and interaction design)

8. A professional attitude The development process should be performed by eective multidisciplinary teams

9. Usability champion Usability experts should be involved throughout the development lifecycle

10. Holistic design All aspects that inuence the future use situation should be developed in parallel

11. Process customization The UCSD process must be specied, adapted and/or implemented locally in each organisation

12. User-centered attitude There must be a common understanding during the development process about the importance of usability and user involvement

2.2 Agile software development

Traditional sequential methods of developing software (e.g. the Waterfall Model, Figure 2) often emphasize up-front planning, complete requirement denition and documentation before actual implementation.

(19)

Figure 2: Waterfall development, modied from Dima and Maassen (2018)

Sequential processes are rigid and often do not allow product modications too far down the road. They are frustrating and less adaptive than desired, considering how fast the industry and customer requirements are changing nowadays (Cohen et al., 2004). Agile was introduced in 2001 by Beck et al. (2001) as a response to the need for alternative methods. It is not a method itself, but a philosophy or a way of thinking about software development (Shore & Warden, 2008, p. 9). The philosophy is supported by 12 principles (Table 3).

Early into the introduction of Agile, Highsmith and Cockburn (2001) stated that these principles stress continuous delivery of working software to the customer, as well as the importance of cooperation between dierent team roles to have a successful product. They wrote:

What is new about Agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on eectiveness and maneuverability.

(Highsmith & Cockburn, 2001)

The same view is echoed in Cockburn's later work (2002, p. 148-165). How agile a team can be depends not on the methodology they use, but on how they apply the Agile philosophy to their specic situation.

(20)

Table 3: 12 principles of the Agile Manifesto (Beck et al., 2001)

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most ecient and eective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indenitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicitythe art of maximizing the amount of work not doneis essen- tial.

11. The best architectures, requirements, and designs emerge from self- organising teams.

12. At regular intervals, the team reects on how to become more eective, then tunes and adjusts its behavior accordingly.

2.2.1 Iterativity of Agile methods

There is no single Agile process to follow, but multiple dierent methodologies - each with their own practices - that endorse the Agile philosophy (Shore &

Warden, 2008, p. 9). Some popular examples are eXtreme Programming (XP), Scrum, Lean or Kanban (Measey, 2015). This thesis will not go further into specic because the research scope does not directly concern any specic Agile method, however reading the descriptions by Cohen et al. (2004) or Measey (2015) is highly recommended.

Due to the focus on quick delivery while maintaining working software, Agile methods utilize short development cycles with regular testing (Beyer, 2010). Each

(21)

cycle includes similar steps to sequential processes: planning, analysis, design, implementation, testing and deployment Figure 3.

Figure 3: Agile development cycle

The idea of cycles - or iterations - stems from iterative techniques which emerged and evolved in the late 1980s and 1990s (Measey, 2015, p. 2-4, 33). The whole development project is split into short iterations of variable lengthtwo to three weeks in eXtreme Programming, two weeks to 30 days for Scrum (Highsmith &

Cockburn, 2001). In Figure 4, Shore and Warden (2008) compared the iteration length between traditional and Agile development processes. Waterfall projects span anywhere from a few months to several years, iterative projects are broken down into iterations of a few weeks to months, and Agile having especially short iterations.

(22)

Figure 4: Software lifecycles comparison (Shore & Warden, 2008, p. 16)

At the end of each iteration, a working solution is produced which can potentially be released to the customer. This continuous delivery means getting feedback more often, then, in turn, prepares the organisation for unexpected events and allows swift reactions to sudden changes.

2.2.2 Benets of Agile practices

One major selling point of Agile software development is that it solves problems for all parties involved with the software (Beyer, 2010). As design and implementation happen concurrently and continuously, developers gain more autonomy and have an inuence over the project as opposed to being handed a xed set of requirements to implement. Management knows more clearly what is being

(23)

worked on in short cycles compared to the traditional timeline of months to years, so they can make changes to the project more easily. Customers get their hands on a working solution fast and continuously, increasing their trust in the product and loyalty to the business (Shore & Warden, 2008, p. 7).

Organisation-wise, Measey (2015) makes a case for Agile economically, citing several studies that reported higher success rates, lower cost and fewer quality issues when software projects implement Agile methods. Shore and Warden (2008, p. 6) adds that because Agile methods set expectations early, the organisation can save cost by canceling infeasible projects well before it uses too many resources. In addition, Cohen et al. (2004) nd that members of a software team need less formal training to participate in Agile than traditional development, and fewer experts are required in the team to mentor others. Jump-starting a development project is, therefore, easier and consumes less human resources.

The points mentioned above are consistent with ndings in the 14th Annual State of Agile Report (Digital.ai, 2020). Table 4 lists the most commonly seen benets by software teams that adopt Agile, along with the percentage of survey respondents who agree.

2.3 Integration of User-Centered Design into Agile devel- opment

We have learned in previous sections that Agile methods aim to involve customers in the development process and satisfy them early and continuously. However, Kautz (2009) points out that end-users of a product seldom take the role of customers. The question of how to achieve usability with Agile and deliver more value to the users is therefore still left hanging. There is a lack of focus on users or UX within the community of Agile practitioners, and major Agile methods do not include explicit details on how to develop usable products (Salah et al., 2014;

Blomkvist, 2005). The amount of up-front design is minimized in the short cycles of Agile, which in turn takes away from the resulting usability. This cost can be oset by frequently improving the product with customer feedback, but it does not

(24)

Table 4: Benets of adopting Agile (Digital.ai, 2020)

Benet % of respondents

Ability to manage changing priorities 70%

Project visibility 65%

Business/IT alignment 65%

Delivery speed/Time to market 60%

Team morale 59%

Increased team productivity 58%

Project risk reduction 51%

Project predictability 50%

Software quality 46%

Engineering discipline 44%

Managing distributed teams 41%

Software maintainability 35%

Project cost reduction 26%

fully address the problem (Jurca et al., 2014). Furthermore, customers and users are often not dierentiated well enough from software developers' perspective, so it is easy to misunderstand that utilizing customer feedback is sucient for users' needs (Lárusdóttir et al., 2016).

The interest in integrating UCD into Agile software development - creating user- centered Agile software development (UCASD), as used by Brhel et al. (2015) - has grown considerably in recent years, in eorts to ll this lack of usability development. Many attempts at studying the collaboration between UCD and Agile have been made (e.g, Jurca et al., 2014; Magues et al., 2016; da Silva et al., 2018). (da Silva et al., 2011) described several techniques that are commonly used in UCASD integration, the most popular of which are summarized in Table 5.

In addition, Figure 5 depicts a process where UCD is integrated into ASD via One Sprint Ahead model.

(25)

Table 5: Key practices in integrating UCD and Agile (da Silva et al., 2011)

Practice Description

Little Design Up Front Small amount of design activities should be carried out before the ocial start of implementation, and then continuously integrated as part of development cycles.

Prototyping Applied from the early phases of development. UI prototypes should be created in parallel or shortly ahead of implementation cycles.

User testing Include user testing to validate the usability and to re- ne designs before going into the next cycle. Testing works with several stages of design, from low delity prototypes to working product.

User stories Created and improved by UCD team to help identify usability requirements. Usually used in combination with prototypes.

Usability inspection Usability evaluation should be done on early prototypes to form a basis for the UI design of future iterations.

One Sprint Ahead UCD team work at least one sprint (cycle) ahead of development team while paying attention to the current sprint for possible usability ndings.

Figure 5: One Sprint Ahead approach (Sy, 2007, as depicted by Kuusinen, 2015)

Utilizing UCD practices in Agile processes allows developers to better understand

(26)

the goals and needs of users who end up using their product, and improve the development process towards better usability (Jones, 2019). For the benets that integration brings, it is dicult to arrive at a denite solution because both UCD and Agile are broad concepts that can be applied in vastly dierent ways.

Nevertheless, Brhel et al. (2015) were able to draw from their systematic literature review 5 principles for successful integration:

1. Separate product discovery and product creation. User-centered agile software development should be based on separated product discovery and product creation phases.

2. Iterative and incremental design and development. User-centered agile approaches should support software design and development in short iterations and an incremental manner.

3. Parallel interwoven creation tracks. In user-centered Agile approaches, design and development should proceed in parallel interwoven tracks.

4. Continuous stakeholder involvement. Stakeholders should be actively involved in user-centered agile approaches early on and should remain involved throughout the entire development process to collect input and feedback.

5. Artifact-mediated communication. In user-centered agile approaches, tangible and up-to-date artifacts should be used to document and communicate product and design concepts and should be accessible to all involved stakeholders.

Another reason for the challenges in UCASD integration is because UCD and Agile are perceived to be dierent in principles (Salah et al., 2014). In Table 6, Jones (2019) summarized the major dierences between the two approaches, as indicated by major literature reviews of the topic (see, e.g., Salah et al., 2014;

Brhel et al., 2015; Law & Lárusdóttir, 2015).

In their review, Brhel et al. (2015) used a system of 4 main dimensions - process, practices, people/social and technology - to analyze the aspect of UCASD that researchers and practitioners are interested in. Out of the 4 dimensions, process,

(27)

Table 6: UCD and ASD integration challenges and conicts. Modied after Jones (2019)

ASD UCD

Lack of allocated time: Delivering working code quickly, focus on func- tionality

Upfront planning activities: Requires insight, research and design

Work divided into chunks: Tight

deadlines Designing for the whole user experi-

ence; holistic design of UCD Working software over comprehensive

documentation; Fast-paced releases;

Deadlines

Medium to long-term studies before implementation work; Prototypes; Us- ability testing

Lack of documentation Decisions based on information: data, reports, prototypes

Limitation of work-in-progress Delays UX designer from giving eective feedback on design

Decisions are made quickly; Project manager is not the accountable decision maker

Decisions after data gathering and thorough analysis, iterative design Cross-functional teams UX designer often in a specialist cen-

tralized team/services Using tools/default metrics to mea-

sure work progress UX professionals cannot easily track the interplay between user evaluation and redesign

practices and technology are very closely intertwined (da Silva et al., 2018), leaving people/social as one unique aspect. Because of the dierences in background and culture between practitioners of the two disciplines, reaching a common understanding between UCD and Agile teams is usually dicult. In addition, there have not been many studies on the people side of UCASD integration (Jones, 2019), and existing ones provide contradictory suggestions (Brhel et al., 2015).

This indicates that further research on the people or social aspect is desired, and would be very benecial.

(28)

2.4 People and social challenge in UCD and Agile integra- tion

When bringing UCD and Agile experts together for UCASD integration, the people and social factor concerns team organisation, knowledge sharing, collaboration and communication (Brhel et al., 2015). Brhel et al. proposed that even though the team structure might vary depending on the degree of UCD adoption by Agile software teams, close collaboration between the two sides is always important.

2.4.1 Communication issues between designers and developers

Traditionally, designers and developers have dierent perspectives when looking at software development. Many of the key points are recounted in studies by Löwgren (1995) and Maudet et al. (2017). Designers are seen as creative people, who ask the question Why? to identify the correct problem and explore the many options for solving that problem. They put more emphasis on the visual and interactive aspects of the process, utilizing graphical tools to create and communicated designs. On the other hand, developers are practical and analytical:

they ask the question How? to nd one satisfying solution and keep on rening it. They use abstract tools (e.g. text editors) to do their jobs and prefer having design documents in concrete, implementable formats.

Because of these dierences, designers and developers may understand the importance of each others' work but still struggle to eciently cooperate on a daily basis (da Silva et al., 2018). Maudet et al. (2017) identied three major collaboration breakdowns when designers and developers work together on a software product:

(1) missing information, when designers do not communicate enough details of certain designs; (2) edge cases, when designers do not consider specic cases during designing; and (3) technical constraints, when designers do not understand the technical limitations from developers' point of view. The study suggests in- volving developers in the initial design process to mitigate breakdowns, but even that does not completely solve the problem (Maudet et al., 2017). From the developers' side, lack of communication about changes in the development cycles as well as feedback for existing designs could confuse the UCD team, and cause a rift

(29)

in synchronization between design and implementation processes (Budwig et al., 2009). Finding an eective way to communicate between design and development teams is therefore crucial, as a shared understanding reduces the bottleneck and helps produce better software faster (Salah et al., 2014).

2.4.2 Representation of UCD experts in Agile teams

The extent to which UCD professionals are included in Agile teams varies in dierent organisations, from dedicated to one team to shared between several.

For smaller organisations, sharing designers results in increased workload and productivity loss, and it is usually unavoidable due to lack of resources (Salah et al., 2014). For UCD members in Agile teams to be successful, they have to fully participate as a member of the teams they are in, take responsibility and juggle the demands from several teams at once (Beyer, 2010).

Among the roles that UCD experts can play in Agile teams, da Silva et al. (2013) name UX designer (responsible for understanding users), interaction designer (responsible for designing and evaluating user interaction with the product) and UI designer (responsible for the visual interface and graphical elements of the product) as most popular. They also agree with Beyer (2010) that designers should be considered a full member of Agile team, but organisational choices, one designer often has to handle too many projects at a time. The burden can be somewhat evened out by providing UX training to developers so that they understand the design perspectives better and can participate in UCD processes (Øvad & Larsen, 2016). However, the developers need to understand UCD culture and should be interested in the design process in the rst place for training to be viable.

(30)

3 Research methodology

With the literature background in mind, we conduct a study to explore the people and social challenges in integrating UCD into Agile software development, then verify and expand on current ndings. In this chapter, we will go through the research context, data collection methods and analysis methods that are used for the study.

3.1 Ethnographically-informed approach

Ethnographic study is a qualitative research strategy that, according to Robson (2011, p. 79), seeks to capture, interpret and explain how a group, organisation or community live, experience and make sense of their lives and their world. Classic ethnography involves long periods of researcher immersion into the group being studied, in order to observe and understand the people or phenomenon under study in their natural settings (Robson, 2011, p. 142-143). For the scope of this thesis, it is not feasible to get involved in the work environment of all participants and the timeline of the research is shorter than traditional ethnographic methods, so an adapted approach named ethnographically-informed was adopted.

Following the examples by Robinson et al. (2007), the study in this thesis is ethnographically informed because of the following:

The communication challenges we are interested in are not known a priori and we cannot make an assumption before analyzing the results.

Data collection happens without any control or interference from the researcher that might inuence the experience of participants. The researcher gained an understanding of participants' normal settings by working in similar environments themselves.

3.2 Research context

Ethnographically-informed studies are especially suited to answer how, why and what are the characteristics of questions (Robinson et al., 2007). In this

(31)

thesis, we are interested in the following topics:

How designers and developers communicate within a UCASD team Why they nd (or do not nd) such communication challenging

How communication aects the integration of UCD into Agile processes What is the role of a dedicated UCD person towards the integration process To select the participants for the study, a purposive sampling method named criterion sampling (Palys, 2008) is used. The criteria for selection are:

1. The participant has at least 2 years of working experience in the software business

2. The participant is currently working in or alongside a software team where Agile methodologies are adopted

3. The organisation the participant works at has dedicated teams or people responsible for product design and development

Ultimately, 14 software professionals agreed to participate. The participants are classied into 3 groups of roles which are described in Table 7. Each participant is assigned a label which is used to present the ndings in chapter 4.

Table 7: Study participants and their roles

Role Description Participants

Designers Directly responsible for the UCD aspect in

development process S1, S2, S3, S4

Developers Directly responsible for the implementa-

tion of the software product D1, D2, D3, D4, D5 Other roles Work closely with designers and develop-

ers but are not directly responsible for either design or implementation (e.g. tester, team leader, product owner)

O1, O2, O3, O4, O5

3.3 Data collection

Data collection for this thesis happened via semi-structured interviews with the 14 participants in December 2020. Interview sessions were online video calls

(32)

between the interviewer and each participant. Each session lasted from 30 to 90 minutes. They were recorded as audio and then transcribed for analysis.

3.3.1 Semi-structured interview

Semi-structured interviews are exible by nature. They allow the interviewer to explore the topics of interest while leaving considerable freedom for participants to expand the study focus (Galletta, 2013, p. 24). When performed as a data collection technique, they are suitable for small-scale projects where the interviewer is closely involved in the research process (Robson, 2011). In this thesis, the author is at the same time the researcher and the interviewer.

An interview script was prepared to try to answer the research questions for this thesis. The explicit questions are:

RQ1 What are the challenges in communication and understanding between design and development in a software team?

RQ2 How does having a dedicated UX designer in the development team address the communication challenges?

When designing semi-structured interviews, the interview questions must be open- ended enough so that participants have ample room to describe their experiences.

At the same time, they should be carefully directed towards the research topic so that the participant would provide answers that relate to the study (Galletta, 2013, p. 46-47). The nal interview script (Table ??) therefore only serves as a guide, the order and exact wording of the questions change according to the participant being interviewed and the ow of conversation.

(33)

Interview script, designed after Robson (2011, p. 284) Introduction

The interviewer introduced themselves and explains the purpose of the interview

The interviewer assures participant of condentiality and anonymity, then asks for consent to record the interview

arg1 Could you briey describe your team and the kind of product you develop?

What is your primary role in the team?

What kind of development methodology does your team follow?

Main body of interview Communication

How does your team communicate during everyday work?

Do you have problems/challenges while communicating with other roles in your team? If so, what kind of problems/challenges?

Integration of UCD into development process

How are design decisions communicated throughout your team?

If you could improve something in the communication of product design within your team, what would you improve?

Role of UX-people in a software team

Does your team have a designated person doing UX design? What are their tasks and responsibilities?

What kind of communication happens between the designated designers and other team members?

Cool-o

Would you like to say something outside the questions asked?

Wrap up discussions that might have come up during the interview Closure

Interviewer thanks the participant for participating

Document if participant has additional remarks when o recording

3.3.2 Interview process

Interview invitations were sent to prospective people during November 2020. The invitation includes a brief description of the research interest and indicates that

(34)

the interviews aim to collect insights from various roles in the development process about the topic. All interviews were conducted through online video calls with participants during December 2020 and recorded. The interviews were completely informal. Participants were informed before recording starts that they are free to answer to their understanding and own experience. In some cases, clarication of terms was necessary during the interview to make sure the interviewee was understood correctly.

Out of 14 interviews, 10 are in English, and 4 in Vietnamese. The recordings are transcribed by the researcher and translated into English when necessary.

According to the condentiality assurance with participants, all sensitive information that could be used for identication are censored (e.g. names of people, companies or products).

3.4 Data analysis

Thematic coding approach (Robson, 2011) is chosen to analyze the data. It is a general qualitative analysis method that is suitable for our purpose of exploring the meaning behind the experiences of interview participants. The coding process follows the phases described by Robson (2011, p. 469):

1. Familiarizing yourself with your data. Transcribing data (if necessary), reading and re-reading the data, noting down initial ideas.

2. Generating initial codes. Extracts from the data are given codes in a systematic fashion across the entire data set, with similar extracts being given the same code.

3. Identifying themes. Collating codes into potential themes, gathering all data relevant to each potential theme. Checking if the themes work in relation to the coded extracts and the entire data set. Revising the initial codes and/or themes if necessary.

4. Constructing thematic networks. Developing a thematic map of the analysis.

5. Integration and interpretation. Making comparisons between dierent aspects of the data using display techniques such as tables and networks.

(35)

3.5 Validity of the research

The validity of qualitative research is dicult to establish, especially in a exible design study. Robson (2011, p. 170) listed description, interpretation and theory as three major threats to the validity of a qualitative research. The approach to increase the credibility of this thesis is described below.

Description refers to the risk of inaccurate or incomplete data. In this study, all interviews are online meetings and recorded with at least two devices (e.g.

computer screen capture, voice recorder) to make sure the entirety of conversations are preserved. The recordings are then transcribed and translated when necessary, then checked with interview participants to ensure accuracy.

Interpretation means the ndings are inferred based on what is happening, rather than the researcher's own observation from their involvement with the research setting. To maintain a chain of evidence and avoid bias, contact with interview participants is kept regularly during the data analysis process. Par- ticipants are asked to verify the meaning of their answers when it is ambiguous, and additional quotes are sometimes requested to gain a deeper understanding of respondent perspectives.

Theory is the threat of not considering opposing theories for the issue being studied. In this case of exploratory research, it is hard to ascertain what are the alternative theories. To remedy this, the pool of interview candidates includes various roles from a software development team. The varied perspectives could potentially reveal dierent opinions about the same phenomena.

(36)

4 Findings

The ndings from data analysis are presented in this chapter, grouped into theme categories, and labeled according to chapter 3.2.

4.1 Communication methods within a software team

The methods for communication and collaboration identied through the interviews can be grouped into 5 categories.

In person meeting

Teams have regular face-to-face meetings or chat in their shared oce space to share ideas and update work progress. It is believed that this is the most ecient communication method.

I think the most valuables are usually shared face to face, or in between the lines when we talk about something product specic. (S2)

As many software companies have shifted towards remote working by the time of this study due to the COVID-19 pandemic, in-person discussion is very lim- ited. Participants indicated a preference for it, over alternative communication methods like instant messaging, or audio calls.

If not for the current pandemic, we would rather have daily stand-ups in the morning at the oce, face to face. (D3)

I think (...) written words is a poor way to communicate, and it is the only way nowadays. (...) Face-to-face, live conversation is a much easier way to communicate. (O5)

(37)

Online meeting

Google Meet¹, Microsoft Teams² and similar real-time meeting services are used together with or as a substitute for in-person meetings. They allow team members not working in the same oce space to discuss matters too complicated for text messaging only.

Direct messaging

Direct messaging tools, such as Slack³ or Telegram⁴, are used for quick exchange of information. They are praised for allowing instant and traceable conversations, although nding necessary information might sometimes be dicult due to the sheer volume of messages in group channels.

Most of those [daily] conversations are in Slack only. If you miss it there, it's almost impossible to nd afterwards, especially if you don't know the talk even happened. (O2)

Between designers and developers, direct messaging is particularly useful for clar- ifying decisions.

If something is confusing, I can ask the designer directly through Slack and they would answer shortly after. (D3)

Project tracking system

Participants reported using JIRA⁵, Pivotal Tracker⁶ both as means of work co- ordination and communication. Also known as ticketing systems, these tools can be used in every step of the development process, from conception, designing to implementation. Tasks are entered into the system as tickets and given a unique identier along with specications so that the assignee understands what to do.

The systems usually have comments or chat features, allowing team members to

1Google Meet is a registered trademark of Google LLC

2Microsoft Teams is a registered trademark of Microsoft Corporation

3Slack is a registered trademark of Slack Technologies, Inc.

4Telegram is a registered trademark of Telegram FZ-LLC

5JIRA is a registered trademark of Atlassian, Inc.

6Pivotal Tracker is a registered trademark of Pivotal Software, Inc.

(38)

further discuss about their assignments.

Team collaboration tool

Tools of varied complexity, including Google Drive⁷, Conuence⁸, Aha!⁹, is used for cross-team collaboration. The intention for these tools, according to participants in management roles, is to be a single source of information between groups in one team (e.g. design and development), or teams in one company (e.g.

dierent products).

4.2 Challenges in communication between design and de- velopment

4.2.1 Theme category 1: Inecient communication leads to loss of information

The most prominent theme identied throughout the interviews is that communication does not always reach all stakeholders, and information gets lost along the line.

Insucient communication

Participants in the designer group acknowledged that when the reason behind design decisions is not conveyed fully to the development side, it creates incon- sistency between design and implementation.

The biggest problem is when someone designs something (...) then hands it over. Developers start writing code but have no idea where that design comes from, what was the idea behind it, and the end product doesn't align with the design at all. (S1)

The problem is because we (designers) don't explain suciently why something was designed a certain way. (S4)

7Google Drive is a registered trademark of Google Inc.

8Conuence is a registered trademark of Atlassian, Inc.

9Aha! is a registered trademark of Aha! Software, LLC

(39)

Some participants are aware that they are missing out on information, but communication is not happening as much as they would like.

It [communication] is harder nowadays with remote work because people are not talking face-to-face and cannot use anything but written words. (S2)

I don't know how exactly, but we need to increase the amount of discussions. (O5)

Information overload

Too much communication happening is also one cause for information to be lost.

Some roles, development team leader or tester, for example, prefer to know as much about product design matters as possible, but nd it dicult to track relevant information.

We have multiple Slack channels and sometimes if a decision gets made or two developers decide on a way to do something, it can get lost in one of those channels and not documented anywhere. (O4) Information overload is my biggest challenge. I'm trying to keep tabs on pretty much everything and it's mission impossible. (O2)

The information is divided into so many places it is dicult to get the whole picture. (D5)

Lack of documentation

It is believed that having proper documentation promotes shared understanding and reduces the need for formal, direct communication.

When you don't have a single source of truth, when someone gets a task, they will have questions and they will have to ask around for answers instead of nding the decisions written down in the form of documentation. (D4)

(40)

In order to be truly useful, design documentation needs to be updated as frequently as there are new design specications. Participants reported that it is not a simple task in practice.

There is not always 100% documentation on reasons that decisions were made. Those things can drop completely from communication channels and sometimes get missed. (O4)

There have been issues when they [documentation sources] are not in sync, and I have to use channels outside of the ones we are supposed to use (D5)

4.2.2 Theme category 2: Communication issues due to organisational structure

Designers being shared between teams

In some cases, often larger organisations, the designer is shared between dierent development teams and has to divide their attention to multiple projects. De- velopers therefore cannot talk directly to the designers as often. One participant answered they only have design meetings directly with the designer once every 2 months. They added:

We rarely talk directly and have to go through the product owner as the connection. I'd love to see the engineers talking directly to designers to reach a common ground faster. (D2)

When designers rotate between projects and do not self-coordinate, they might have dierent opinions about the same matter and send out mixed messages:

Since they work in dierent teams, it often happens that two people [designers] think dierently about the same thing. We then have to hold meetings with both of them to make sure the whole team is on the same boat and understands the problem clearly. (D2)

(41)

Separation between design and development departments

The delay is also a problem when people responsible for design and development have their own team and work separately from each other.

There is a delay because they [designers] have a busy schedule (...) so getting an answer from them takes time, and you are stuck with your question. If it's something that blocks work completely, you have to nd something else to do while waiting. (D1)

Team separation also contributes to the loss of information, because internal communication within one group does not necessarily translate over to the other.

One tester noted that their quality assurance team was the last in a line of communication, which created extra work when testing product design.

(...) we would hear rumors that some big refactoring is happening or a new UI design is coming up, but we wouldn't get all the details. That is the problem because we have to do regression testing for everything included (...) and nobody is telling us. (O2)

Similarly, the design team might miss out on information when developers keep the conversation only between themselves.

It easily could be that someone is away for 2 weeks and I don't even notice. I don't know if it's a problem with communication channels, but the development side feels separated from my work sometimes.

(S2)

4.2.3 Theme category 3: Development team are not involved enough in early phases

In an ideal ASD process, stakeholders should be involved early and through every phase of development. Participants expressed concern that their team is not addressing this suciently, leading to many issues.

(42)

Development process falls back to waterfall fashion

When not working in parallel with developers, designers easily run ahead with full upfront design without iterating. When the development side joins in, product specications are considered done and changes are less likely to happen.

Unfortunately we are still working in kind of a waterfall-like process, where I hand o designs to developers and they implement it. (S4)

In addition, doing a large amount of design ahead create a surplus of work that the development side does not have the resources to pick up. Some participants consider designs that are left idle for too long wasted eort, as feature requirements might have been changed by the time of implementation and need to be redesigned anyway.

Those decisions are made ahead of time by only the product design team (...) so there could be many things ready to be developed but not enough developer resources to actually work on them. (O4)

We [testers] learn from the documentation what the idea behind the feature is. But by the time it is ready to test, it has been changed like four times in the development cycles and is totally dierent from what was initially written. (O1)

Missed opportunity for knowledge sharing

Participants indicated that including the development team in early product design opens up conversations and allows developers to share their technical knowledge that designers might not know. This sharing and collaboration is believed to be benecial to achieving product needs, but it is not always possible.

Some features need to be evaluated per the technical eort also (...) Maybe the designer wouldn't be able to see that, but developers would.

(S4)

It would be nice to have someone there to do rst reviews of the mock-

(43)

ups. That would help the designer see if there's any kind of [technical]

problem. (O1)

I think it would be good to have discussions before the implementation so we could get feedback from developers about the feature denitions.

But it's not possible with the current time constraints. (S2)

Another common sentiment between participants is that when the development side does not understand suciently the design decisions, it hinders their ability to perform their job.

It's really important to know the root cause and why we are doing something. You can easily make mistakes when implementing a design if you don't know why you're doing it (D1)

Even if something is obviously useful and straightforward to designers, developers wouldn't get it if not explained correctly. They then would not use the useful feature, or use it incorrectly. (S3)

Mixed interest from developers in joining the design process

Participants from the development side show a general desire to be more involved in the early conception of product design, but the extent of involvement that they want varies. Some feel that it is important and benecial for them:

If we were in from the rst design of features, then there would be no surprises for us. Then we don't have a huge backlog [of bugs] which we have no idea what they are. (O1)

If it's possible, it would even be fun to take part in design sessions at some point, but probably it's not possible with our current time constraints. (O2)

Others express interest in product design but do not think they must be part of the design process.

(44)

Do I need to be involved more? I do want to understand our users better, but to do my job, maybe not necessarily. (D2)

I think it's nice that we have separate teams for design and development. (...) I prefer that I don't have to do everything including design by myself. (D5)

4.2.4 Theme category 4: Communication gap because of dierence in background knowledge and personalities

Participants who nd design communications challenging for their work also point out several social aspects that contribute to the challenges.

Dierence in professional knowledge

Team members with dierent knowledge backgrounds have a hard time understanding and collaborating with each other. Issues arise most commonly when designer roles do not understand technical terminologies and limitations. Addi- tional time and eort are spent on clarications to bring the whole team to a common understanding.

The nal conclusions¹⁰ from JIRA reports have been completely in- comprehensible, consisting of technical gibberish that doesn't make sense to me at all. (O3)

Our team leader understands most of the time the technical limitations, but the product owner does not, and that leads to miscommuni- cation between the two of them. (D3)

Because of the dierence in our professions, things that might be obvious to me would not be obvious to my PO, and then communicating would be slow and takes time. (D4)

This problem is more apparent in teams where Agile practices are not well fol- lowed, designs are done too far ahead and handed o to developers in an almost

10Free text written by developers into JIRA software, to describe what has been implemented

(45)

nished state. Without taking technical challenges into account, the designs might not be feasible for developers to implement.

Normally [designers] don't understand the technical scope of the problem, they want a fancy solution but they don't know how much work it actually takes to make their design work. (D2)

Product design people (...) don't know too much about development stu. They might not understand what developers or QA talk about if the feedback go into a too technical level. (O5)

Attitude towards each other's role

Designers feel like their work is not taken seriously enough by some members on the development side. In those situations, developers tend to not fully trust in design decisions, which in turn makes communicating dicult for designers.

There's still the mindset that those who do the back-end development and take care of the databases are the cool and tough guys of software development. And then there are these designers who don't know anything but think that they do (...) and management tells [developers]

to just obey their design. (S1)

People still have the mindset that user research and usability practices are not that important. (...) I have worked in some teams where developers think that UX designers are not necessary at all and they can do all the designing themselves. (S4)

On the other hand, some developers feel that their opinions are not taken into account by designers when coming up with product decisions.

I've been in several cases of conicting opinions between development and design, and I usually ended up being wrong. (D1)

The decision is ultimately in their hands, and if my ideas are shot down then it is what it is. (D4)

(46)

The interview participants expressed concern that developers in training or junior positions could be discouraged, and would be less willing to consider UCD matters during implementation.

Dierence in personalities and other social aspects

Interview participants observed certain dierences between the personalities of people doing design and development. UX people are thought to be more socia- ble and willing to work in diverse groups and involve themselves in discussions.

Product design communication is often good within groups of designers.

I'm happy about the communication within the design team. We are quite open and we ask and share things quite easily with each other.

(S2)

In contrast, developers often stay within their own circle (e.g. small team of developers working on the same feature) and are reluctant to initiate conversations.

The direction of communication is often one-sided, coming from the design team.

Interview participants felt that this is one reason the frequency and quality of communication were not as good as desired.

We have to try ourselves to keep the communication with the developers as much as possible (S1)

In almost every conversation [with developers], the rst approach has to be from my side. (S2)

They have quite passive personalities, they don't talk much unless asked and don't actively participate in our brainstorming sessions.

(S4)

Sometimes I'm too straightforward when asking questions, and I don't want to interrupt [developers] when they don't want to be interrupted.

(...) I think my communication to the development team is more of a distraction than being helpful. (O3)

(47)

Another observed obstacle is the language barrier. Most participants have used English for work because either their teams are multinational or their products are branching towards international markets. It is noted by both design and development sides that the language barrier adds to the complexity of communication and teams have to spend additional time on clarications.

Our team members are not all uent in English. Sometimes miscom- munication happens because we misunderstand or simply don't understand each other. (D3)

We use English as ocial work language and it might be an issue, because it's not the mother tongue for most of our team. (O5)

4.3 Impact of having dedicated UX people in an ASD team

In this section, participants are asked to reect on their history of working in development teams both with and without dedicated UX roles.

4.3.1 Theme category 1: Added UX and UCD perspective to development process

Proper UCD practices help streamline the decision making process Product designers feel like their groups are more condent in making decisions if UCD or UX principles are applied during the process. Practices such as user research, usability testing and feedback analysis produce evidence to support the design team's decision and make it easier to convince management and the development side.

We should have someone responsible for UX design. (...) Dierent people want dierent things and have dierent opinions, so we need someone to say what is our process and how we should take care of UX matters in our product. (S2)

When designers only speak from their own experience without solid evidence to back themselves up, it is hard for developers to trust them.

Communication challenges in User-Centered Agile Software Development and the role of UX designers towards them