IN
DEGREE PROJECT
COMPUTER SCIENCE AND ENGINEERING,
SECOND CYCLE, 30 CREDITS
,
STOCKHOLM SWEDEN 2019
Integrating UCD with Agile
Methods: From the perspective of
UX-Designers
THUJEEPAN VARATHARAJAH
KTH ROYAL INSTITUTE OF TECHNOLOGY
Integrating UCD with Agile Methods:
From the perspective of UX-Designers
Master of Science Thesis
Thujeepan Varatharajah
tvar@kth.se
Supervisor: Anders Lundström
Examiner: Haibo Li
Abstract
With the increasing popularity of Agile methods in software development projects, an emerging
question is how Agile incorporates user needs to their process – which is the staple of User Centered
Design (UCD). Existing reports indicate that integrating Agile and UCD has shown to improve the
process and end product and that they are a natural fit. However, there is also a general lack of
guidelines of how an effective integration may be done, and further research is requested. This study
aims to provide that by portraying some aspects of how Agile and UCD may be integrated in practice,
but also some factors that may affect such an integration. This is done through an empirical study, by
gaining insights from the perspective of UX-designers who are part of Scrum teams. Ten
UX-designers took part in semi-structured interviews, and based on a thematic analysis, results are
portrayed in terms of suggested factors to consider when integrating Agile and UCD methods.
Sammanfattning
Samtidigt som Agila metoder ökar i popularitet inom mjukvaruutvecklingsprojekt, så uppstår även
frågan om hur Agilt arbete integrerar användarcentrerade krav i sin process - ett område som är i
fokus inom Användarcentrerad Design (ACD). Tillgängliga rapporter indikerar på att integrationen av
Agilt och ACD har givit förbättrade processer och slutprodukt, samt att båda processer är kompatibla
med varandra. Det anses dock finnas en brist på riktlinjer i hur man kan integrera båda processer, och
det efterfrågas vidare studier i ämnet. Denna studie ämnar till att erbjuda just detta genom att
Acknowledgement
Integrating UCD with Agile Methods: From the
perspective of UX-Designers
Thujeepan Varatharajah
Royal Institute of Technology
KTH
Stockholm, Sweden
tvar@kth.se
ABSTRACT
With the increasing popularity of Agile methods in software development projects, an emerging question is how Agile incorporates user needs to their process – which the staple of User Centered Design (UCD). Existing reports indicate that integrating Agile and UCD has shown to improve the process and end product and that they are a natural fit. However, there is also a general lack of guidelines of how an effective integration may be done, and further research is requested. This study aims to provide that by portraying some aspects of how Agile and UCD may be integrated in practice, but also some factors that may affect such an integration. This is done through an empirical study, by gaining insights from the perspective of UX-designers who are part of Scrum teams. Ten UX-designers took part in semi-structured interviews, and based on a thematic analysis, results are portrayed in terms of suggested factors to consider when integrating Agile and UCD methods.
Author Keywords
Agile; Scrum; User-Centered Design; User Experience; UX-designer;
ACM Classification Keywords
H.5.m. Human Computer Interaction (HCI) K.6.1 Project and People Management
INTRODUCTION
The Agile methodology for software development projects has steadily been increasing in popularity, and its manifesto adheres to a principle of prioritizing the customer through iterative and continuous delivery of valuable software. In particular it welcomes changing requirements, which is in contrast to traditional waterfall methods. However, for software to be valuable, it may be argued that it should also be a product that offers a high degree of usability. This goal is also the staple of a user-centered design (UCD) approach, which promotes an iterative process that welcomes changing requirements based on the user needs to bring forward an optimal user experience (UX). Consequently, it is also becoming more common that specialists within UX (UX-designers) are being deployed in projects to tackle these tasks, which has also shown to increase the usability and quality of the end product [1,2,3,4,5,6].
With these aspects in mind, the need to optimally integrate UCD with Agile methods emerges. At first glance, their similarities may simplify such an integration as they both prioritize the user/customer in their stance, and both are
iterative in nature in order to welcome changing requirements. However, Agile processes do not define a UX-role and lacks guidelines for how or when such activities should be conducted making the integration difficult [6,7].
It is within this spectrum that the study field of Agile and UCD integration investigates how they should be integrated. In a systematic review conducted by Silva et al. [6], they showcase a model where UX-designers and developers work in parallel with each other, but where UX-activities lie one or more iterations ahead. The authors also conclude that whilst there is a growing amount of papers within this subject, the amount of research is limited and more empirical studies within this field is needed.
The objective of this research is to perform such an empirical study from the perspective of UX-designers working in real life projects in different organizations. This is to provide further empirical research of how UX and Agile can be integrated, but also present what factors that can promote or hinder UX-designers in an attempted Agile/UCD integrated environment.
PURPOSE AND RESEARCH QUESTION
The purpose of this study is to provide further empirical research on Agile/UCD integration, but from the perspective of some UX-designers and how they may perceive their workflow in an Agile process. Since Agile methods do not generally define a designer role, understanding how UX-designers perceive this workflow may provide valuable insights. This includes understanding how they work but also what factors that may promote or hinder integration and the fulfilment of their role as a UX-designer.
The research question for this study is:
From the perspective of some designers, how is UX-designers working in Agile processes and what factors may affect an effective integration of Agile and UCD methods?
Limitations
BACKGROUND Agile
Agile methods are a class of software development processes that adheres to a manifesto which asserts its highest priority is to satisfy the customer through early and continuous delivery of valuable software [9]. Abrahamsson et al. [10] provides a definition of what may constitute such an Agile method: ”when software development is incremental (small software releases, with rapid cycles), cooperative (customer and developers working constantly together with close communication), straightforward (the method itself is easy to learn and to modify, well documented), and adaptive (able to make last moment changes)”.
One such Agile method is called Scrum and it aims to produce increments of a product in a time-boxed and iterative manner - through iterative cycles called Sprints [11]. The main roles of a scrum team consists of the Product Owner (PO), the Development team (DT) and the Scrum Master (SM). The PO is responsible for managing a Product Backlog (PB) which contains the product requirements and their order of priority. The DT is cross-functional and self-organizing in how to reach the goals set for that sprint, and the SM has a management role. The general workflow of a sprint consists of an initial planning meeting where the PO goes through the top prioritized features from the PB with the entire team, and based on input from the DT the Sprint Goal is set for that iteration [11]. During development, daily meetings are held to update the team of the progress, and the output of a completed sprint should be a “potentially releasable product increment”. The concluding parts of a sprint include demonstrating what has been done and going through the PB with the entire team and stakeholders to adapt it or make changes to the upcoming sprints.
The need for Agile/UCD integration
Agile methods purpose to be adaptable, iterative and with a focus on customer satisfaction marks some similarities with UCD which focuses on user satisfaction and also follows an iterative path that is refined by using empirical information from previous iterations [4,6]. However, whilst both aim to produce high quality software, they approach it from different perspectives. Agile mainly describe activities for working code (functionality or features) whilst UCD describes activities for increasing the usability and user experience of the product [8,12]. Additionally, it should also be noted that the customer is not necessarily an adequate representative for the users of the product.As such, the integration of Agile and UCD can be seen as a complementary approach.
Agile alone is seen to lack an awareness of usability issues, and the integration of UCD activities into Agile can improve the product by incorporating ways to evaluate the needs of end users. Similarly, Agile can aid an UCD approach by providing a structure to turn design into working software with an iterative approach that allows for more frequent usability evaluations. Whilst their perceptions and priorities may be different, integrating UCD into Agile can thus offer an improved product with
higher usability. Several reports mention such benefits including increased product quality and development processes, as well as improved communication and collaboration between development and design teams [1,2,3,4,5,6].
Challenges in Agile/UCD Integration
Agile methods do not define a specific designer role, and therefore integrating UCD with Agile becomes a challenge. Specifically, there is a lack of guidelines of how to establish UX-designer roles in relation to developers [6,7,13]. This also includes problems of how to coordinate design activities with development activities and the synchronization of these. As both are iterative in nature the timing and scheduling of these activities in relation to each other is a challenge [5,12]. Additionally, Agile methods define and measure progress through working software, and this can also introduce difficulties in how to prioritize UX-related decisions [8,14].
Another aspect that challenges the Agile/UCD integration are their views on how resources should be allocated in terms of upfront design and requirements gathering work. Agile discourages extensive upfront work in order to be more adaptable for changing requirements throughout the process of several iterations. On the other hand, UCD promotes extensive upfront user research and analysis prior to development begins in order to gain a holistic view of what requirements may affect the user experience. These differing philosophies creates further obstacles of how to integrate both processes [3,4,5,6].
Related work
Chamberlain et al. [15] conducted an ethnographic study by studying three project teams with the purpose to identify issues that may arise in an attempted integration of UCD and Agile development. Part of their conclusions were that Agile and UCD are compatible together, but issues that can cause them to be at odds include: communication issues and power struggles between developers and UX-designers, that development takes more time than creating prototypes, a reluctance from team members to understand the needs of other elements of the project, and the rate of user involvement throughout the project.
Kollman et al. [16] conducted a qualitative study in which they interviewed UX-designers and observed teams to understand their role in Agile projects. They identified two themes that are perceived by UX-designers to be important for a successful integration of UX and Agile: the UX-designers understanding of their job role in an Agile process, and the need to establish and maintain a shared team vision that contains goals from a technical, business and UX perspective. Furthermore, Kollman suggests that UX-designers should become design facilitators and partake in generating and prioritizing requirements for the product, and that the use of “lightweight” tools(e.g. paper prototypes) makes UCD more agile.
gathered but in which UX-designers were not part of, there was a mutual understanding between UX-designers and developers to adapt their processes to support each other, and that the projects that followed a Scrum methodology had processes that were similar to the Parallel Track model (See “Systematic reviews and Parallel Track Model”)..
Raison et al. [17] conducted five case studies in different project teams to observe how an attempted integration is applied in practice, but also to study what factors may promote and hinder such an integration. Their common findings include a methodology of UX-designers working at least one iteration ahead of developers similar to the Parallel Track model. Furthermore, UX-designers being co-located with the development team was also regarded as an important factor for successful integration. A significant problem with integration was that UX-work was often seen as an “add-on” and lacked strategic support.
Systematic reviews and Parallel Track model
Silva et al. [6] conducted a systematic review in 2011 on the topic of integrating UCD with Agile methods and the three most common artefacts from their referenced literature include:
1. Little Design Up Front (LDUF) - incorporating the up-front work related to UCD, before development begins, but in a much more reduced manner.
2. Agile/UCD integration improves collaboration between UX-designers and developers.
3. Using Low-fidelity prototypes in the process. Based on this and further common findings of their review, they showcase a variation of a “Parallel Track” model for how UCD and Agile can be integrated. Whilst several variations of this model has been presented in both experience reports, e.g. [3,18] and empirical research, e.g. [4,8], the model as presented by Silva et al. is detailed here [6].
The model includes an initial Sprint 0 before development begins and is supposed to be where initial user research including clarifying requirements and creating initial low-fidelity prototypes can be done. Once development begins in subsequent sprints, UX-designers and developers work in separate but parallel tracks where UX-designers work at least one iteration ahead of developers. The reason for this is that UX-activities such as user research, gathering requirements, prototyping, usability evaluations etc. should occur up-front and then be handed on to developers in subsequent sprints to then be implemented - thus integrating UCD work into the developed features. During software development, UX-designers should also provide feedback on what is being developed in that sprint. The implemented features may also then also be user tested and/or evaluated by UX-designers one sprint after development to raise any issues. Silva et al. concludes that all of their referenced papers mention that Agile and UCD are a natural fit and an integration can work well[6]. However, they also conclude that there is a need for more empirical studies in this topic,
and that most of their findings were based on experience reports. This is further corroborated by a subsequent review conducted in 2014 by Jurca et al.[5], in which they highlight that there has been an increase in empirical studies compared to when Silva et al. conducted their review but that it is still lacking. Jurca et al. also mention that in the empirical research they reference, they could not conclude that some core aspects of the Parallel Track model, including a Sprint 0 and UX-designers working one sprint ahead, was highly used in practice as per their research.
METHOD
In order to answer the proposed research question, an empirical study was performed. The study was done by conducting semi-structured interviews with 10 UX-designers (P1-P10) who had current and previous experience working in Agile projects.
The participants were spread across 9 different organizations and were active in organizations from Sweden (P1-P6, P9-10) and Canada (P7, P8). The Canadians was working in the same organization albeit in different departments. The aim was to gain a wider spectrum of responses that was not tied to a specific organizations structure.
Respondents P3, P4, P7, P8, P10 all had at least 2 years of experience working as UX-designers, whilst P1, P2, P5, P6, P9 all had at least 7 years of experience. All respondents were currently (or recently) active in working as a UX-designer in Scrum projects. They all also had previous experiences working in Agile projects. It should also be noted that all respondents were specifically working as UX-designers in their teams - thus not combining other roles in their projects.
Interviews
Each interview lasted between 45-60 minutes and most were held face to face (P1-P5, P7, P8, P10), while two was conducted using video conference calls (P6, P9). They were of in-depth semi-structured nature, which allowed for open-ended questions to be used in conjunction with an interview guide. This allowed the interview to focus on aspects related to the research question and also making the participants reflect on each question and allowing for follow-up questions. This methodology was relevant to this study in order to gain a realistic understanding of the complex dimensions that are part of the participants work process when being part of an Agile/Scrum project. The interview guide was formed with questions that would aid in answering the proposed research question, but it was also supported by a conducted literature study in order to draw comparisons with ideas mentioned in available research and experience reports. In particular, when attempting to understand the general work process of each participant, a descriptive diagram of the Parallel Track model [6] was presented in order to find any similarities and differences to their own workflow.
The interview guide aimed to uncover the following aspects:
2. Their experience in working with UX-activities in Agile environments and their latest such project. 3. Their work process as a UX-designer in an Agile project. What differences are there to the Parallel Track model. What responsibilities they have and how and when they perform UX-activities. 4. The relation between UX-designer and
developers but also other members of an Agile team.
5. Their opinion of Agile processes and whether it fits an UCD/UX-designers approach.
Each interview had a primary focus on understanding the process, and their opinions, of the project they are currently active in, or the latest Agile project they were part of. However, in cases where it was relevant, the respondents previous experiences in Agile projects was also discussed in order to gain more insights.
It should also be noted that since all respondents had their recent experiences in Scrum projects, the results is biased towards that Agile process.
Data Analysis
All interviews were recorded, with permission, and later transcribed in order to conduct a thematic analysis on them. The aim of a thematic analysis was to identify, analyze and report emerging patterns and themes within the data [19]. A thematic analysis was seen as a viable option to identify patterns that could potentially answer the research question of how UX-designers may perceive the integration of Agile and UCD methods.
The thematic analysis in this study was conducted by going through each transcribed interview, finding emergent themes and organizing them by coding themes and grouping data of each participant for each theme. This process was conducted several times in an iterative manner in order to find common themes across the participants which forms the results presented in the subsequent section.
RESULTS
Based on the conducted thematic analysis, six common themes emerged. These themes cover topics that include the upfront work done, the workflow during sprint cycles, relationships between members, and their opinions on working in an Agile process. The results of each theme is detailed below.
Upfront Work
The amount of upfront work UX-designers conduct before development cycles begin was discussed with all respondents. Most respondents (P1-P3, P5-P9) commented on an initial phase in which overall requirements are gathered and understood to produce an initial backlog - and which may be called the planning phase before the project officially begins. Many respondents (P2, P3, P5-P8) state that they had participated in this early phase in their recent projects, albeit in different measures across the respondents. process when being part of an Agile/Scrum project.
As an example of such a planning phase, P2 details a process in which P2 partakes in an initial analysis with
three other members, to conduct research and gather requirements - and this occurred before developers and the rest of the team were brought in. These requirements were then transformed into user stories and discussed with the Product Owner in order to produce a “User Story Map” which was intended to be communicated with the team before and during the sprint cycles (it is refined during the sprint cycle process). The user story map was separated from a scrum board and was intended to provide a holistic overview of the product and how the user stories tied together with regards to the user journey, along with their priority. The intention was that it could then act as a reference point during the sprint cycles.
“User story map is about where are we heading? [..] User story map maintains the picture of how everything ties together. This means when developers work on a story during a sprint they can already visualize how it ties together with future sprints” - P2
Respondents P3, P5, P6, P7, P8 also partake in initial planning phases, starting before the sprint cycles begin, where they conduct generative research to gather and analyze initial requirements as well as aiding in determining and the prioritizing of them in the product backlog. This is typically done in conjunction with the Product Owner and other relevant members and stakeholders.
“When I started in this project, I did a lot of research to understand different user needs. And that work became a base for the prioritizations that we started doing, and which we still do in the project now for upcoming sprints. Some of these requirements are very far away in the future and are quite vague so that they can be adapted in the future.” - P3
P5, P6, P7 also specifically mentioned that they tend to create high-level designs and iterate towards initial clickable prototypes (P5, P6) or low-fidelity wireframes (P7) of the product during this phase.
“First UX does a analysis of the situation. That’s what you tend to do first. Based on that analysis you start to build one or more prototypes of the entire product in conversation with the stakeholders, and this occurs before development begins”. - P5
Both P5 and P6 expressed that it is important to have a high-level design before the sprint cycles begin
“I feel that if you are going to design a system it is an entity. It is very difficult to sit during a sprint X and Y and only design something isolated, because everything needs to tie together conceptually. I don’t think you can get a good user experience like that. You also need to take time beforehand and work on the wholeness of it” - P6
Furthermore, respondents P6 and P7 specifically mention that the initial planning phase may also determine whether a project should move forward or not and thus act as a part of the product strategy:
leadership team know that this is the wrong path to go down” - P7
It should be noted that respondents P2, P3, P5, P6, P7, P8 mentioned that their work in the initial phase (detailed above) is generally not confined to the length of a single sprint, i.e. a Sprint 0, but typically done in a longer phase before sprint cycles and development begins. The time needed for this was not mentioned by all respondents. However, P2 mentioned it was a period of three months whilst the other respondents simply mentioned that it was a longer phase. The respondents also mentioned sentiments that they value that UX-designers are part of a planning process to form the initial backlog, allowing them to partake in the visioning of the project.
“The projects I like to work the most with are when there is a focus on analyzing and prototyping in the beginning before you actually start to develop something [..] This is where you bring forward a concrete vision of where we are heading. Then you will adapt it and adjust it once the sprints with the agile process begins” -P5
In contrast to the respondents above, P1, P4, P9, P10 were not part of a specific planning phases before the project officially began. Instead they were introduced through a Sprint 0 in which initial requirements and goals were already brought forward by PO and stakeholders (or including other members). The work conducted in Sprint 0 was then regarded as a pre-work phase to clarify requirements and/or create new ones based on the initial visioning, leading to the creation of initial prototypes. However, P4 mentioned that they have separate “Hypothesis meetings” in which UX, Product Owners, Stakeholders and other relevant members from the entire department partakes to work on a separate backlog of requirements for how to improve their customers experience. These user stories can then be feeded into the roadmap for new projects thus allowing UX-designers to some extent partake in defining the initial visioning for new projects.
Respondents P1 and P9 mentioned that the lack of UX-designers being part of a planning phase is a flaw in their process.
“My experience is that, especially in larger organizations, the scope and resources are already set, the amount of developers, UX-designers and the backlog. It’s only afterwards that UX-designers are brought in and are supposed to work a sprint before development. But shouldn’t we include the UX resources when we are setting the initial backlog instead? Shouldn’t we evaluate the needs?” - P1
P9 specifically emphasize an opinion that the stage at which organizations introduce UX-designers, could speak of their general maturity in terms of working with UX. “I believe UX should be introduced from a strategic level to determine what to build.[..] Many organizations are still very immature in working with UX, and I would say the ones that are the furthest behind are ones that introduce UX-designers at a Sprint 0. Whilst the ones that are more
mature introduce UX-designers from a planning phase”- P9
P1 and P9 further mentions some issues arising from this as they have experienced that projects tend to be more oriented towards reaching feature-focused goals rather than user-centered goals. P1 also mentioned that this could lead to work between developers and UX-designers to be out of sync with each other.
“If you put a UX-designer in a Sprint 0 and ask them to do user research and conceptual tasks that should be developed in the next sprint. Then they then start to question the backlog, and you end up in a situation where you already start to fall behind.” - P1
P1 specifies that it is not about getting more time to do pre-work or extending the time of a Sprint 0 in which they can start work from a provided backlog. The respondent still mentioned that most of their work was done there. Rather it is about having user-centered goals in the backlog to measure on, so that the flexibility to make design-oriented decisions throughout the project exists. This includes when setting the initial backlog from the beginning of the project.
Workflow
When the project team is set and the sprint cycles begin, all respondents, except P4, mentioned that the intention is to work at least one sprint/cycle ahead of development with work to clarify requirements and producing prototypes to hand over to developers in subsequent sprint. This work could include contextual inquiry, producing and iterating on prototypes and user flows, receiving feedback from developers on prototypes, and user testing on prototypes.
P2, and P10 specifically mentioned that as a UX-designer they generally need to be focused on the outcome of three simultaneous sprints whilst developers could be more focused on one sprint at a time. This typically include researching and gathering requirements from two sprints ahead, designing prototypes for the upcoming sprint and giving feedback whilst developers are implementing. However, whilst many respondents (P2, P6, P7, P8, P9, P10) indicated that they often work 1-2 sprints ahead, how far ahead all respondents worked throughout a project could vary depending on the estimation and sprint planning.
“Usually we work one to two sprints ahead. But sometimes if it’s something bigger we might even start to work 3-4 sprints ahead because there is a lot that the UX and requirements people will have to do”. -P6
stories can vary. P4 exemplified this by saying that in a two-week sprint the first few days might focus on providing prototypes on user stories to the development team, and the rest of the sprint might focus on explore stories whilst also being available for feedback and usability testing for the developers.
Time estimation for working ahead
All respondents said that they generally have sufficient time to stay ahead (or in parallel in the case of P4) in their current projects. However, P7 and P10 mentioned that it can be difficult to estimate the time for UX-related work which can challenge staying ahead. P10 also mentions an opinion that the challenges with time estimating could be improved if previous experiences for UX-related tasks would be made more visible.
“I think there should be some work done to estimate UX-work better based on previous experiences. Not just to see that a user story took more time than anticipated, but more specifically what kind of UX-related tasks that took more time. So that we can use that knowledge for upcoming sprints” - P10
Additionally, P7 and P4 mention that they have had experiences where they have been assigned to many different projects or products, which can be a challenge when trying to work ahead. Hence they also mentioned that UX-designers should preferably be able to be focused on one product or project rather than being assigned to several.
Prototypes & User Testing
A common comment amongst most respondents (P1-P8) was that the prototypes provided to developers need to be closer to high-fidelity rather than low-fidelity as this often leads to a better understanding for developers of what to do. The use of wireframes and lo-fi prototypes was mentioned by some respondents (P2, P4, P5, P6, P7, P8) as an initial starting point that could be used when working internally with clarifying requirements in the upfront phase and/or during the sprints to then be iterated on - but that delivery to developers need to be closer to hi-fi.
“The closer you are to high-fidelity, the more satisfied developers are. However, when working with clarifying requirements it can be of more low-fidelity so that you don’t focus too much on graphical parts like color etc. But once you deliver to developers, you need to be ready to hand over something of more high-fidelity. You can’t just hope for the best and expect developers to understand low-fidelity sketches in the same way you do” -P2
In terms of user testing, many respondents (P3-P8) mention that it is often conducted on high-fidelity prototypes initially, although it may also occur on implemented versions at later stages. How often testing occurred was varied between the projects and respondents, as no one mentioned testing to occur during or after each sprint. Some respondents (P2, P3, P4, P5) mentioned that testing was fully or partially done by other dedicated members of the team or outsourced, and P8 specifically mentioned the lack of a dedicated tester in their team as a
flaw because it leads to doing less user testing than what is desirable.
“If we do testing it’s very minimal. I’ll do it before locked [finished] designs, by getting some feedback from customers and then changing things based on that. But for projects we normally make a lot of assumptions[..] I would love to do more user testing but we don’t have someone dedicated to it so it’s hard for us to do because there is already so much other things to do in two weeks[sprint length] and often it’s not enough time” - P8
Relationship with Developers
As mentioned in the method, the collaboration between UX-designers and developers was discussed with all participants. Most respondents (P1-P5, P7-P10) specifically emphasized that they would want more consistent communication between developers and UX-designers throughout the sprints. This is important to both discuss prototypes and offer feedback during development in order to gain a mutual understanding of technical constraints and UX requirements.
“I think it is important to involve developers from early on. So that I also design effectively and become aware of technical constraints and opportunities. But also to communicate with them continuously when they implement it, so that we don’t become isolated to each other. Otherwise, if they ask me something about the design after a while, I might have forgotten it since I worked with it during the previous sprint. But that’s not how it should be so continuous communication is important” - P10
Whilst continuous communication was highlighted by many respondents, some factors were mentioned which could affect the collaborative nature, and these are detailed below.
Being Co-located
Most respondents (P1, P2, P5-P10) have been co-located with the developers in their recent projects. P2 mentioned that the use of a user story map alleviated the communication between developers and UX-designers because it was always physically available in the workplace and created a better understanding for developers of relationship between features that are being developed and upcoming ones. P2 also expressed that upcoming user stories and designs were discussed with developers to determine technical feasibility but added that UX-designers should seek communication with developers during development as well.
“As we sit close to the developers I am able to see whilst
they are working on something and see if there are disparities from what was intended from the UX-side. If so, we can discuss and they can fix it directly, and the developers are also good at checking with us[...] You need to take space as a UX-designer. If the communication is missing be the one that communicates” - P2
“Usually our intent is for the designers to be embedded within the teams. So that there is constant communication and we’re not only designing in a bubble where they can’t carry out something from a code perspective or vice versa” - P7
P8 gave an example of how they improved their process by introducing scheduled “brainstorming sessions” early on in a sprint where UX-designers and part of the development team take part to discuss early prototypes both from a technical perspective and UX perspective. However, in addition to a scheduled session, being co-located aids in having continuous communication when needed.
“The brainstorm is normally when I first receive feedback from developers. For instance, there was something I was working just a little while ago where they thought the flow was a little bit weird. So between brainstorm and the final stages of the sprint, I had a lot more communication with them and they sit close by so it’s easy.” - P8
Not being co-located
P3 and P4 were the only respondents that mentioned to not be co-located with the developers in their recent projects. P4 expressed that they generally felt that communication during the sprint worked well and also expressed that it is important for developers to understand the role of UX and also give continuous feedback on designs, in addition to the technical feedback.
P3 also mentioned that they discuss designs that they are working on during the sprint, but that feedback was mostly from a technical perspective to understand what is technically feasible. However, P3 also expressed that not being co-located meant it is more challenging to have fluid feedback whilst a provided prototype is being developed. “It can happen sometimes that prototypes I provide don’t take the same form in production, with smaller details differing. What I could wish for is that if we were working at the same place, then we could communicate and provide feedback more fluidly. Now, it is a slight effort to check if someone has time and then call them, and so the work flow can feel a bit stiff sometimes. Like, I create prototypes, talk to them, they develop it and then I get to look at it afterwards” - P3
P5, who has had previous experiences working with offshore developers, expressed similar sentiments that it can create a bigger separation between UX-designers and developers, especially if the developers are not used to working with UX-designers before.
Understanding & Mindset
Some respondents commented on the level of understanding that developers might have of the role of UX, as a factor that could affect how well the collaborative nature between developers and UX-designers becomes(P1,P3,P4,P5,P7,P8).
P5 mentioned that it is important for developers to understand that design is also an iterative process that will continually evolve and change. P5 also mentioned that in their experience many developers do not have that mindset
and rather want to be handed a design and then be done with it.
P7 also expressed similar sentiments but with a focus on some developers not wanting to work as collaboratively: “I’ve worked with great developers which I’ve had back and forward communication with[..] But I’ve also had other developers who were like ‘you do your work and when you’re done give it to me and I will do my thing. And if I cannot, you will have to figure something out’. We tend to fight back a lot in those cases and we continually strive to make things more collaborative”. -P7
P8 mentioned that in their current project they work quite collaboratively, but P8 have also noticed other teams in their organization where developers seem to want to work more separated.
Another aspect P7 mentioned was that generally developers might have a different way of thinking than designers and gave an example of a challenge this may present where developers give feedback that are based on their own perspective, rather than being open for new ideas and letting the users drive the decisions. P1 expressed a somewhat close sentiment that in “engineering-focused” organizations it is more common that they receive feedback from developers of something not being feasible. However, P1 also believes this is a result of the product backlog and requirements being too feature focused (rather than considering user-centered goals) thus giving less room for flexibility in UX-related decisions.
Relationship with Product Owner
All respondents talked about a continuous relationship with the PO throughout the project. In this context, some respondents (P1, P2, P3, P4, P8) specifically mention that it is important to have a PO that values the importance of UX, as that tends to allow user needs to be more valuable in the project. Furthermore, the respondents mention that there can be conflicts of interests with a PO that is more focused on other perspectives (technical or business perspectives were mentioned) whilst undermining usability factors.
“I think one of the key factors to integrate UX and Agile is to have a PO that understands the need and role UX. Because I’ve had previous experiences with PO that are more focused on getting products and features out rather than promoting and understanding the need to focus on producing more user value in the products.” - P4
P1 specifically emphasize that a closer collaboration between UX-designers and PO can be important to incorporate requirements into the project that have been validated.
“I think the PO and UX needs to be working closer with each other. In my experience PO is often more technical, but if the PO understands the value of validating ideas then we will also have requirements in the backlog once they have a clear worth” - P1
Opinions on Agile
process, almost all respondents (P1-P4, P6-10) were positive. Many respondents (P2, P4, P6, P7, P8, P10) emphasize aspects of Agile that supports close collaboration between different members of a project. “Once you’ve done the upfront discovery work and start working in sprints I think Agile is great. Because for instance you can collaborate with developers much more at that moment in time[...]If design was instead to figure everything out and then passing it off to development, then issues come up later and it’s a lot of rework”. -P8
P4 further exemplifies that Agile also allows them to collaborate with decision makers to affect the projects path.
“When working agile, I’ve experienced that you work much closer to the people who are responsible for the decisions. This also means that I can get my deas through more effectively. For instance. I work near our stakeholders and it makes it much easier to get my visions incorporated throughout the project” - P4
Furthermore, the respondents also highlighted how Agile allows for requirements to be adaptable which aids the UX-process.
“I’m very positive to working Agile. It requires more work but the end result becomes much better. It allows people to gain knowledge throughout the project which they can implement to the end product. It is rare that you in the planning phase already know everything. Instead new things will come up, and you can now refine it during the projects lifespan. -P6
P3, whilst being positive towards Agile, also mentioned that the lack of guidelines of how to incorporate UX-activities to Agile brings challenges and exemplified this in how P3 initially had scheduled sessions to motivate to developers their role and try to suggest how to incorporate their role to the work process.
In contrast to other respondents, P5 provided some sentiments of not preferring to work in an Agile process. P5 was mainly critical towards time-boxed methods in Agile, e.g. Scrum, and expressed that such processes hinder a fluid workflow.
“For instance, if we decided that something should be done in a sprint, and then realize that we will not be able make it - then suddenly the team starts losing motivation[..] And you have the opposite as well, you over-estimate and what do you do then? I think Agile in that sense is not very suited to a more fluid or effective workflow.[...] Sprints feel more like a tool for project leaders to have control.” - P5
P5 also expressed opinions that Agile methods can be very rigid, in how it in practice wants to deliver something specific after each sprint and thus may not be that suitable for iterative design development.
Summary of most common findings
The table presented below summarizes the most common findings, categorized under each theme that emerged from the thematic analysis and further reports the frequency of
respondents mentioning them. It should be noted that the table does not outline all findings but rather includes topics where the frequency was at least five respondents - with one exception being under the Upfront Work theme where the table also shows how many respondents indicated to start from a planning or pre-work phase in their recent projects.
Theme Frequency Upfront work
Starts from Planning 6 Starts from Pre-work(Sprint 0) 4 Preference to start from planning 8
Workflow
At least one sprint ahead 9
Prototypes & User testing
Hi-fi prototypes to developers 8 Using lo-fi prototypes during the
requirements phase
6 Initial user testing on hi-fi prototypes 6
Relationship with developers
Need for continuous feedback during prototype and software development stage
9 Co-location can improve communication 8 Developers understanding of UX can affect
collaboration
6
Relationship to PO
PO that understand and values UX 5
Opinions on Agile
Positive 9
Close collaboration 6 Adaptable requirements 6
Table 1: Table indicating the most common factors mentioned by each respondent categorized under the
six themes that emerged from the thematic analysis.
DISCUSSION
An initial starting point from the results is that almost all participants of the study had a positive opinion of working as a UX-designer in an agile development process. In particular it was highlighted that agile methods has the premise of introducing closer collaborations between team members, allowing UX-work to be more effectively integrated to the project. This is coherent to Silva et al. review where improved collaboration between UX-designers and developers were amongst the most common artefacts of UX/Agile integration. Additionally, it should be noted that in this study respondents also indicated that it allows for closer collaboration with other members and parties of the project, e.g. PO and stakeholders, which are further valuable reasons for integrating UCD with Agile. As detailed in the background, a conflicting concept between Agile and UCD is how much upfront work should be conducted before software development begins. In Silva et al. review they mention Little Design Up Front as a common artefact and portray it in their parallel track model with a Sprint 0, and in this study all participants mentioned the existence of a Sprint 0. However, an important distinguishment should be made on what constitutes the initial upfront phase and when UX-designers are introduced at first. Two cases, based on the results, are provided below.
1. Pre-work: UX-designers and the project team start working from overall requirements that has been provided to them by e.g. POs and stakeholders. Work starts from Sprint 0 in which UX-designers are tasked with supporting in clarifying requirements for upcoming sprints and performing UX-related work.
2. Planning: UX-designers are part of a longer project planning phase where they together with POs and other relevant parties aid in setting the overall requirements and perform UX-related work as part of this. This phase may start before the team is set, and before the project officially begins. It is generally longer than the timeframe for a single sprint. This also leads to the start of a project and sprint cycles(which could also include a sprint 0) with the now assembled project team. The second case would arguably be more preferred from a UX-designers perspective since it allows user needs to be incorporated into the products visioning right from the beginning. The results from this study also support this, since almost all respondents mentioned similar sentiments. Furthermore, six respondents in this study mentioned that they have been part of such planning phases in their recent projects, indicating that it may have become more common for organizations to introduce UX-designers in a project planning phase. This could also suggest that more organizations are willing to introduce UX aspects from an early strategic viewpoint. These results are in contrast to Dahls study [8] where they observed that UX-designers were not part of the planning phase in the five cases studies they performed prior to 2013. However, while much may have happened in this area since their study, one should be cautious in drawing too general conclusions based on the small sample of this study.
It may be argued that a project planning phase as above should not be regarded in terms of an agile context - as it may bring forward elements of a waterfall approach. The official Scrum Guide, for instance, doesn’t mention the existence of planning phases (nor does it mention the existence of a Sprint 0 for that matter). However, in practice it seems plausible that there is an initial period where the project is being planned in terms of scope, resources and budget. Whether this is seen as a project in itself, or part of strategic management, the existence of such a phase in some kind is at least supported by the respondents in this study. By including UX-designers in the process of setting the initial requirements and vision of it, the project is also set up for inducing user needs from the beginning, as well as taking advantage of the UX-designers role. Furthermore, this may also lead to a better understanding of UX-aspects throughout the project team since UX-factors becomes a core requirement for the products strategy.
It should also be noted that UX-designers should not only be included in this context in the beginning, but also getting space to partake in it during the lifetime of the project, i.e. being able to affect the requirements and their prioritizations throughout the project. In this aspect, agile methods such as Scrum support UCD since it has dedicated spaces for the entire team to adapt the requirements throughout the project. It should also be emphasized that since the PO (in Scrum) is the one responsible for maintaining the Product Backlog, the relationship and workflow between the PO and UX-designer becomes an important factor to integrate UCD to the process. The results of this study also support this, since many respondents mentioned the value of a continuous relationship with the PO, and that a PO that has a higher understanding of UX can be a beneficiary factor.
changes to already coded features takes more time - thus focus should be on providing feedback while it’s being implemented instead.
Whilst it is important to allow UX-designers to incorporate user needs to the projects vision - as discussed further above - it is also important that UX-work is communicated effectively and continuously within the team. This include a shared understanding with PO and stakeholders (and other relevant members), but also with the developers of the team. The need for continuous communication between developers and UX-designers was also highlighted in Silva et al. parallel track model, although it mainly puts an emphasis on UX-designers providing feedback once developers starts implementation [6]. Most of the respondents in this study expressed an importance of communicating with developers both when working/iterating on prototypes but also whilst it is being implemented. This is both for the sake of UX-designers and developers to give and receive feedback, but also to promote a shared understanding between the parties in terms of technical feasibility and understanding of the UX. This can occur both through scheduled sessions, but also ad hoc during the process. Furthermore, many respondents suggested that UX-designers should be active in seeking communication with developers, indicating that it may be an important factor to be aware of in the UX-designer role. The results in this study suggest that being co-located with developers eases the possibility for continuous communication, which is coherent with the findings of Raison et al. study[17]. Three respondents in this study had experience working with offshore developers, and two of them indicated this could limit the amount of effective communication and create a larger separation between the two parties. However, due to the limited amount of respondents in this regard, it may not be viable to draw any drastic suggestions of how big of a problem this stipulates. Another aspect that emerged from this study, was that the understanding developers might have of the role of UX can affect the collaboration between both parties, and this is coherent with some of the findings of Chamberlain et al. study[15]. It would be interesting in future studies to understand how such issues can be mitigated. One suggestion could be the use of a User Story Map, as detailed by one of the respondents in this study. A User Story Map could showcase how different features of the product are connected from a user-centered perspective and based on user needs - thus increasing the understanding of UX across the team.
Limitation and Discussion on Method
The conducted study was aimed to follow a qualitative approach in which semi-structured interviews were being held to capture aspects that could answer the proposed RQ. This approach allowed the conducted interviews to have some structure, whilst also allowing the participants to express ideas and opinions in an open-ended fashion which was beneficiary for this study. However, one aspect that should be mentioned was that some of the interviews became more emphasized on certain topics as the participants were inclined to discuss them more. This also
meant that not every aspect presented in the results was discussed with each respondent. Thus, one should be aware that if a participant is not referenced in the results, it does not necessarily mean that the respondent did not agree - as it instead could mean that it just was not discussed with that participant.
The specified target group of respondents was decided as UX-designers who solely work with that role in Agile projects, and have them be from as many different organizations as possible. This resulted in 10 participants from 9 different organizations. The intention was that this methodology would allow the conducted thematic analysis to produce results from a UX-designer viewpoint, as well as not being biased towards a selected few organizations and their organizational structure. Instead a more general overview of UX-designers perception of how they work and what important factors there are in an Agile/UCD integration could be given. However, there are some aspects of this approach which could have been improved in order to get better results.
One such factor is that there was not any particular consideration done to whether the type of projects the respondents were part of could affect the results. This was neither done when recruiting interviewees nor when analyzing the results. The types of projects in this study varied from developing whole new products to maintenance or partial new development of existing products. There was also a variation in terms of whether the product was for commercial use or for internal use within an organization. Such factors and differences could affect the way the project team is set up and therefore also the results in this study. An improvement of the method could thus be to target UX-designers working in specific field of projects to get more viable results for that field. Another factor that could have affected the results in the study, is that the Parallel Track model was shown to each respondent before asking them to brief the structure of how they work. This was done as a way to drive the interview, since there was an assumption that it would be difficult for the respondents to explain their work process. However, showing the model could have skewed their responses in a way that might not have happened without having a model for reference. A remedy for this could have been to present the model after they had presented their own process.
Future research
For future studies one can research how organizations in practice could include UX-designers from a project planning phase. Whilst this study has provided cases of UX-designers being part of such a phase, it did not delve deeper into the factors of how UX-designers co-operate with PO, stakeholders and other relevant parties during this initial phase. A study focusing on how these parties can work together before the development project officially begins can be interesting for anyone seeking to involve UCD from a strategic phase.
continuous communication between the two parties, and advices UX-designers to seek communication, it would also be interesting to delve deeper into some practical ways of how this can be done. As discussed earlier, a User Story Map could be one such example, and further studies could delve deeper into more such artefacts or methods. Finally, further empirical research should be conducted in the topic of Agile/UCD integration. Whilst this study focused on gaining insights from the perspective of UX-designers, it would be viable to to conduct studies with other parties of an Agile team as well.
CONCLUSION
The study was conducted in order to answer the proposed RQ: From the perspective of some UX-designers, how is UX-designers working in Agile processes and what factors may affect an effective integration of Agile and UCD methods?
Based on the conducted study and thematic analysis, the following are a summary of findings in respect to the RQ, and may be regarded as suggestions or factors that can be considered for integrating Agile and UCD processes:
• Introducing UX-designers from a project planning phase - where they can aid in setting the initial PB and vision of the project - may aid in making use of a UX-designers role fully and inducing user needs to the project from the beginning. Thus, it may improve an integration of Agile and UCD.
• During development, UX-designers can follow a workflow where they work at least one sprint ahead of development with work to clarify requirements and produce prototypes to hand over to developers in the subsequent sprints. This can typically be working 1-2 sprints ahead, but may require more flexibility in terms of how far ahead.
• Low-fidelity prototypes may be used at an initial stage whilst understanding and clarifying requirements internally. However, when delivering to developers, using high-fidelity prototypes may ease the discrepancies between a designers intention and what is being implemented.
• A shared understanding between UX-designers and developers can be aided if they are in continuous communication throughout the project. This includes UX-designers getting feedback on prototypes from developers, but also giving feedback to developers whilst it is being implemented to avoid ambiguity. In practice, this may require UX-designers to facilitate a responsibility to seek communication with developers throughout the project.
• A mutual understanding between UX-designers and developers in regards to their respective needs can improve the process. This can be in terms of UX-designers understanding the technical feasibility from developers standpoint, but also for developers to understand the role and
function of UX and how UX-designers work and what they produce.
• A PO that is aware of UCD, its goals, and values it equivalently to the technical and business perspectives of a project can be an important factor for integration of Agile (Scrum) and UCD. This may allow a designers work and UX-related factors to be more effectively integrated and considered for the project and the PB.
Finally, as indicated by most respondents of this study, Agile and UCD can be compatible as they share many ideas in terms of an iterative/adaptable workflow and allowing team members to work closely together. Incorporating the above mentioned factors (including further findings mentioned in the results) may improve such an integration and allow the project to gain the benefits of an improved user experience in the end product.
REFERENCES
1. McInerney, P. and Maurer, F. UCD in agile projects. interactions 12, 6 (2005), 19-23.
2. Hussain, Z., Slany, W. and Holzinger, A. Investigating Agile User-Centered Design in Practice: A Grounded Theory Perspective. HCI and Usability for e-Inclusion, (2009), 279-289.
3. Sy, D. Adapting usability investigations for agile user-centered design. Journal of Usability Studies 2, 3 (2007), 112-132.
4. Fox, D., Sillito, J. and Maurer, F. Agile Methods and User-Centered Design: How These Two Methodologies are Being Successfully Integrated in Industry. Agile 2008 Conference, (2008).
5. Jurca, G., Hellmann, T. and Maurer, F. Integrating Agile and User-Centered Design: A Systematic Mapping and Review of Evaluation and Validation Studies of Agile-UX. 2014 Agile Conference, (2014). 6. Silva da Silva, T., Martin, A., Maurer, F. and Silveira, M. User-Centered Design and Agile Methods: A Systematic Review. 2011 AGILE Conference, (2011). 7. Salah, D. A framework for the integration of user centered design and agile software development processes. Proceeding of the 33rd international conference on Software engineering - ICSE '11, (2011).
8. Dahl, A. Agile/UX Integration: how user experience-related practices and processes are integrated with Agile development processes in real-world projects. 2012.
11. Schwaber, K. and Sutherland, J. The Scrum Guide. 2017.
12. Ferreira, J. Agile Development and UX Design: Towards Understanding Work Cultures to Support Integration. Progress in Pattern Recognition, Image Analysis, Computer Vision, and Applications, (2012), 608-615.
13. Kuusinen, K., Mikkonen, T. and Pakarinen, S. Agile User Experience Development in a Large Software Organization: Good Expertise but Limited Impact. Human-Centered Software Engineering, (2012), 94-111.
14. da Silva, T., Silveira, M., de O. Melo, C. and Parzianello, L. Understanding the UX Designer’s Role within Agile Teams. Design, User Experience, and Usability. Design Philosophy, Methods, and Tools, (2013), 599-609.
15. Chamberlain, S., Sharp, H. and Maiden, N. Towards a Framework for Integrating Agile Development and User-Centered Design. Extreme Programming and Agile Processes in Software Engineering, (2006), 143-153.
16. Kollmann, J., Sharp, H. and Blandford, A. The Importance of Identity and Vision to User Experience Designers on Agile Projects. 2009 Agile Conference, (2009).
17. Raison, C. and Schmidt, S. Keeping User Centered Design (UCD) Alive and Well in Your Organisation: Taking an Agile Approach. Design, User Experience, and Usability. Design Philosophy, Methods, and Tools, (2013), 573-582.
18. Budwig, M., Jeong, S. and Kelkar, K. When user experience met agile. Proceedings of the 27th international conference extended abstracts on Human factors in computing systems - CHI EA '09, (2009).
