DRAFT Research Project Mid-term Paper

User-Centered_Agile_Method_----_Pg_33--42.pdf

Home >Business & Finance homework help >Operations Management homework help >DRAFT Research Project Mid-term Paper

Sources for this Work

For the purposes of our work on the construction of the User-Centered Agile (UCA) method, we have collected data, analyzed these data carefully and made considered observations on the basis of two different sources of data: a literature review and feedback gained from application of the UCA method in the process of its elaboration. In the first section, this chapter offers a state of the art on the schools of thought about the linking of User-Centered Design (UCD) and agile methods. Then, a second section describes the pertinent points raised by the application of the first version of the UCA method in projects. Finally, the third section presents those elements which we deemed most important to take into account when devising the UCA method.

3.1. State of the art

Research relating to the possibility of interlinking the UCD and agile methods to provide a greater ergonomic value of the products developed is a subject that has been under discussion since the time of E. Nelsen’s interview of K. Beck and A. Cooper [NEL 02]. The topic of this interview was the philosophical differences between the agile method eXtreme Programming (XP) and interaction design, with the aim being to highlight the points of consensus and the incompatible elements. This work reveals the divergences in time and in the understanding of the professional roles, which have an impact on the views of each of the two protagonists as regards the organization of the process of group work.

In the wake of this discussion, many research projects have been carried out in this domain. Of these, many highlight the relevance of bringing together UCD and agile methods [BLO 05; CHA 06; MEM 07a; MEM 07b;

Deuff, D., & Cosquer, M. (2013). User-centered agile method. ProQuest Ebook Central <a onclick=window.open('http://ebookcentral.proquest.com','_blank') href='http://ebookcentral.proquest.com' target='_blank' style='cursor: pointer;'>http://ebookcentral.proquest.com</a> Created from harrisburg-ebooks on 2020-11-24 14:04:58.

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

22 User-Centered Agile Method

AMB 08; HUS 08; FOX 10; SOH 10], on the basis of three common points existing between the two methods:

– processes constructed on iterative cycles;

– the need to have regular feedback by way of tests (unitary or integration tests versus user testing) in order to adjust the product to the requirements identified [AMB 08; HUS 08; SCH 09];

– willingess to cater for the users’ needs. It should be noted, however, that there is a difference here, because with UCD, the users are the end- users, while with the agile methods, it is the product commissioner (called the client) who indirectly represents the users [CHA 06; DUC 07; HUS 08]. This last point is important, because it enables us to highlight the value of the UCD in agile methods. A product designed using agile methods may satisfy a need, and be guaranteed to be correctly coded and work properly, but this does not necessarily mean that it will be usable by the end-users, because the usability will not have been assessed during the product’s development [JOK 04; BLO 05; DUC 07; WOL 08; SCH 09; SOH 10]. This point is stressed by T. Jokeda and P. Abrahamsson, who also show that, in the context of the agile method eXtreme Programming, given that the responsibility for usability is placed in the hands of the Product Owner – i.e. the client – the integration of this value into the product depends on the importance that the PO attaches to this approach [JOK 04]. The feedback of H. Asuncion et al. [ASU 11] is an example of the confusion between the product client (represented by the PO) and the end-users. This misunderstanding led the authors to create applications which were pleasing to the client but held no interest for the end-users. We can conclude, as do T. Memmel et al., that while agile methods are not user-centered methods, they are a keystone for integrated approaches [MEM 07a; MEM 07b].

Although the points of overlap between these two approaches are many, it is no easy task to bring them together in practice. For this reason, the existing body of literature contains a great many articles putting forward models for integrating the UCD approach with agile methods, comparative studies leading to recommendations, and a large number of feedback reports on experiments. The following sections describe several of these models, and then introduces the elements which occur time and time again in the recommendations made in the studies and feedback.

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Sources for this Work 23

3.1.1. Existing models

In this section, we begin by presenting the model advanced by D. Sy [SY 07], which is often cited in literature and which appears to be the most widely-accepted model in industrial circles, according to [FOX 10], and the best known according to [KOL 09]. We then go on to introduce four other proposals for models which differ in varying degrees from D. Sy’s model. Finally, we perform an evaluative comparison between these proposals, and draw the balance between them.

In the interests of understanding the models on a common basis, we propose to use the notation “UX team” (“User eXperience” team) to denote any team comprising ergonomists, designers, graphic designers, etc., and “UX expert” for a member of that team. Indeed, as the denominations1 in the literature are numerous, we thought that to give a literature review that retains the denominations used by the original authors would cloud the readers’ comprehension.

3.1.1.1. D. Sy’s model

The model put forward by D. Sy [SY 07] proposes an iterative flow of design and evaluation performed by a UX team, in parallel to the iterative flow of the agile team. The process can be described as follows (see Figure 3.1):

– cycle 0: in cycle 0, data are collected that relate to knowledge of the background of the users, in order to create a vision of the product needing to be designed which is shared by the two teams on the project. These data are obtained by way of interviews, observations, inquiries, and contribute to the construction of personas (profiles for fictitious characters used for product design) and scenarios. The length of this cycle depends on the type of project in question. However, the allotted time is counted in terms of weeks rather than months.

1 UI (User Interface) designer, UI team, UCD (User-Centered Design) specialist, UCD expert, UCD member, UCD team, usability expert, usability designer, usability practitioner, usability engineer, HCI (Human-Computer Interaction) expert, HCI specialist, UE (User Experience) expert, UEX (User EXperience) practitioner, UX (User eXperience) practitioner, UX team, User eXperience team, user interface designer, interaction designers, etc.

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

24 User-Centered Agile Method

– cycle 1: the UX team designs prototypes which relate to the items of the product, which will be coded in cycle 2, iteratively with the involvement of users internal to the company. In parallel to this, the team carries out research about the end-users in order to refine the available knowledge about their behavior towards the product, for design elements which will be implemented during cycle 3. Meanwhile, the development team codes the elements which do not relate to the product’s Human-Computer Interface (HCI), because this is still in the process of being designed.

– cycle n: the UX team designs prototypes which relate to the items of the product, which will be coded in cycle n+1, iteratively with the involvement of users internal to the company. In parallel to this, the team carries out research about the end-users in order to refine the available knowledge about their behavior towards the product, for design elements which will be implemented during cycle n+2. In addition, they evaluate the functional partial product created during cycle n–1, first with internal users and then with end-users towards the end of the release, when the product is nearly ready. Meanwhile, the development team codes the design elements constructed during cycle n–1, for producing the functional partial product n. The UX team can communicate with the development team to answer their questions about the elements needing to be implemented.

Figure 3.1. D. Sy’s model [SY 07]

In order to facilitate the realization of design in iterative cycles of this type, D. Sy points out that the design process needs to be broken down into design items. This is done on the basis of the shared global vision devised

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Sources for this Work 25

during cycle 0. Then, these design items are prioritized in such a way that those elements which will not be greatly affected by the successive addition of items will be dealt with first. These choices mean that the isolated elements are designed first, so that at the start of the project, in the author’s view, these choices make it difficult to carry out tests with internal users, and impossible to observe end-users operating a functional partial product.

Finally, D. Sy points out that although the teams are separate, there has to be communication between them on a daily basis in order to verify the proper implementation of the design elements, and for the members of the UX team to be able to stay abreast of the technical limitations of the product.

3.1.1.2. Other models

Rapid CD is a model put forward by H. Beyer et al. [BEY 04]. It stresses the importance of a preliminary phase to lay down the basic design of a product in advance of the developments, and for the development phase, the authors suggest an iterative model similar to D. Sy’s own [SY 07]:

– thus, the first phase of this model describes ten activities focusing on the user, which are to be carried out before development commences. The first activities are aimed at gaining an understanding of the users on the basis of interviews. On analysis of these interviews, it will be possible to configure user roles for the product being designed, and to establish the list of problems that need to be overcome. The objective of the subsequent activities is to put forward solutions to these problems in the form of “user stories”, which will be prioritized in conjunction with the whole of the development team. Finally, during this phase, the screens relating to the “user stories” which will be developed during the first iteration are designed on the basis of prototypes evaluated by end-users;

– the second phase relates to the iterative cycles of development, and is organized in the manner described by D. Sy [SY 07] – i.e. a development team and a UX team working in parallel and in a staggered way. Similarly as for D. Sy [SY 07], the screens are designed using mock-ups, tested by three or four users; in this model, however, the users in question are end-users. The functional partial products created at the end of the iterations are evaluated, but apparently not regularly with each and every iteration.

T. Memmel et al. put forward a four-phase model [MEM 07a; MEM 07b]. The first phase consists of determining the different users (roles) targeted by the product, and the functional perimeter (scenarios) with the

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

26 User-Centered Agile Method

aim of obtaining possible visions of the product. This phase lasts no longer than the demand analysis in the agile method eXtreme Programming, i.e. one to three weeks; this limits the opportunity to perform in-depth research regarding the users and their situation. The second phase is one in which the design of the HCI and that of the technical architecture take place in parallel, but with links still being preserved thanks to the scenarios created in the first phase. In this second phase, the end-user can be proactive in the choice of the design elements. In the third phase, development begins. This is the classic approach of eXtreme Programming, whereby evaluations of the product’s usability may be carried out on the request of the UX expert. The end of the third phase corresponds to the end of the release, and the development phase gives way to the deployment phase. In this last phase, the finalized product is used by the end-users, who are likely to come back with new demands or problems of design or usability. In this model, the UX team is able to intervene as, and when, required, using ergonomic tools which are simple, quick and relatively cheap to put in place.

The model devised by S.W. Ambler [AMB 08] is a model driven by an agile model called “Agile Model Driven Development” – AMDD. In this model, the UX expert is part of the agile team, and therefore must conform to the pace of the method. In order for this model to work, S.W. Ambler recommends that everyone involved make an effort to understand the philosophy of one another’s disciplines, in the interest of being able to work together. He also points out that the feedback relating to usability needs to be taken into account in much the same way as a technical problem.

S.W. Ambler’s model is composed of:

– an initial phase (iteration 0) the aim of which is to construct a global strategic vision on the basis of three elements: the representation of the organization of the HCI, which corresponds to the structure of the user tasks, a “map” of the organization of navigation through the system, and visual and interactive elements intended to harmonize the entire system. In parallel to this work, the development team determines the functional perimeter of the release and studies the technical architectures that need to be put in place;

– a development phase in which the iterations take place. This stage involves designing the screens and implementing them in the same iteration. The HCIs are coded, as is every other part of the system, during the iterations, without any prior in-depth study or pre-testing, apart from in exceptional cases. However, S.W. Ambler stresses that it is important to

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Sources for this Work 27

carry out user testing as often as the technical tests – that is, at every iteration.

Xiong and Wang’s model [XIO 10] is interesting, because it places the emphasis on UCD and does not separate the UX and agile teams. However, these authors play down the agile methods in the sense that, in order to put forward their approach, they separate the coding of the HCI from that of the functional parts of the system. This is done with the aim of being able to prolong the design time during the first iterations, without having to set aside a longer preliminary period for information-gathering. This method is broken down into four phases:

– the phase of researching the functionalities of the product, based on studies of the end-users performed by way of interviews and questionnaires. Once an initial list of functionalities and scenarios has been compiled, the whole team comes together to work on a final version of the functionalities of the product in a brainstorming workshop for new ideas. At the end of this phase there should be consensus within the team as regards the functionalities which need to be built into the product;

– the phase of design of the interactions of the system. This phase produces a model for the developers and a paper prototype of the system’s interaction for the UX experts. At the end of the phase, the prototype is evaluated by UX experts and users in order to give feedback on problems with usability before the commencement of the development proper;

– the phase of development of the core of the system. This phase takes place in parallel with the finalization of the screens for the product, on the basis of iterative evaluations performed by the team members (developers and UX experts);

– the final phase, relating to the implementation of the HCI and its integration with the system core. During this phase, user testing is performed in order to detect usability problems and unearth new functionalities. These new elements are integrated into the product backlog so they can quickly be taken into account in the product under construction.

3.1.1.3. Evaluative comparison of the models

In a study dating from 2010, D. Fox et al. [FOX 10] present the results of interviews with ten UX experts who have worked on projects combining UCD and agile methods. The common points between these ten projects

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

28 User-Centered Agile Method

relate to the presence of a preliminary phase lasting around four weeks. This is reminiscent of the models presented, in which there is indeed a first phase, sometimes referred to as cycle 0 or iteration 0, which takes place in advance of the developments and the aim of which is to glean information about the user and their “context”. This phase is considered to provide a solid base and a common vision which are necessary to envisage an appropriate design for a system or service. Nonetheless, it usually only lasts as long as prescribed by the particular agile method being used, i.e. between a few days and a month, which we feel is insufficient in order to be able to apply UCD in an optimal way.

Three out of the five models presented are based on an iterative phase comprising interwoven flows, much like that proposed in [SY 07] (see Figure 3.1). Two problems appear to emerge from this form of organization:

– according to D. Fox et al.’s study, the moment of document transfer (i.e. exchange of design documents to be developed and partial products for evaluation) between the two teams is not clearly defined in this type of model [FOX 10]. Hence, this aspect may give rise to misunderstandings and generate problems, unless communication between the two teams is clearly established.

– this interwoven model implies that during an iteration review, when a product n is delivered by the development team to the Product Owner, the UX team presents them with the results of the evaluation of the partial product n–1. However, between prototypes n–1 and n, some aspects of the HCI may have been changed and the issues highlighted by certain results may no longer be present. It seems to us that this may also give rise to tension between the teams, as the UX team may find themselves in an uncomfortable situation at every review, because they are presenting partly- obsolete results.

In the different models, the end-users are involved at different times. Mainly they are asked to pass comment on the paper prototypes, with the aim of designing a first working version of the product. They are involved less regularly for the evaluation of the functional partial products, unlike the approaches put forward by [AMB 08] and [XIO 10]. Thus, not all the attempts at integration, thus far put forward, properly take advantage of the benefits offered by the agile methods, as they do not systematically evaluate the functional partial products created at each iteration.

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

Sources for this Work 29

Amongst these models, the multidisciplinarity of the agile team is a matter for some debate. Some models separate the two teams: the UX team and the development team. Other models merge them to create only one team.

3.1.2. Recurring elements between feedback reports

The literature has proved abundant in reports on attempts to interlink UCD and an agile method. In the following sections, we present the points which seem interesting to highlight.

3.1.2.1. Phase prior to development

The trickiest question regarding the marrying of UCD and agile methods relates to the design done prior to the development phase. From the point of view of agile developers, it is pointless to focus too much on the design of a product, because the result of this design will inevitably be altered during the development stage. Thus, in a great many works such as the models presented in section 3.1.1.3, the members of the UX team have to adapt to the pace of the agile process, which allows only very little time before the commencement of the development stage. D. Fox et al. report from their examination of ten projects that the UX experts had at the initial phase before development to perform research about the user and create models in order to deliver the functionalities and the screen layouts for the first iteration. On the other hand, D. Fox et al. specify that the UX experts only had between a few days and four weeks to bring this work to fruition [FOX 10], which, as stated above, we believe unlikely to lead to an optimum application of UCD.

However, the time given over to the phase prior to development relates to elements of knowledge relating to the users and their context, which evolve less quickly than do the elements of design of a system [BEY 04]. This preliminary task is thus an investment and a solid basis for the design of a system, which can then take place far more quickly [BEY 04]. Many authors therefore highlight the need to have this preliminary phase under good conditions. Thus, in the wake of their analysis of projects integrating agile approaches with UCD, Chamberlain et al. also recommend giving the UX experts the time needed to determine the user requirements before development commences [CHA 06]. For D. Rosenberg [ROS 10], without

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .

30 User-Centered Agile Method

this phase, the contribution of ergonomics and design is compromised, because it can no longer bring any real added value to the product.

In order to have the time necessary for a study of the users and their context, and to obtain a stable and solid vision, J. Kollmann et al. point out that certain innovative projects need to be based on ethnographic research, which it is appropriate to perform outside of the framework of agile methods [KOL 09]. Similarly, D. Rosenberg in an article in the magazine “User eXperience” makes a case for the need to have a phase of product definition which is uncoupled from and precedes the agile phase, so as to facilitate the study of the users and the creation of a detailed design [ROS 10].

Hence, this preliminary phase is important, because it enables us to construct an overall view of the system or the product. Y. Xiong and A. Wang underline that having a good design for the product from the start also allows the developers to have a better view of the system in its entirety [XIO 10]. J. Kollmann et al. recommend allowing time to construct a global vision of the product to begin with before the development phase, in order to share and understand the objectives of each of the interested parties: technical, business and User eXperience. This shared vision should also improve communication between the members of the project team, and serve to prioritize the elements which need to be built in during the development phase, and construct a solid base of what the Product Owner is looking for [KOL 09].

In the eyes of M. Düchting et al. [DUC 07], it is risky not to have this global view of the product. Indeed, the lack of a stable global vision leads to an excess workload in terms of designing screen layouts, loss of direction markers in relation to the products needing to be designed, and also increases the time needed to finalize the product [KOL 09]. The UX experts do not have the time to stand back in the iterations and to put forward a coherent HCI as they do with a conventional project [BUD 09; KOL 09]. In order to overcome this complication (loss of direction due to a lack of a global vision), several articles suggest having an iteration that is regularly devoted to the global coherence of the product [BUD 09; KOL 09].

It seems important to note a final point relating to the resources. It appears that the more the UX experts have to march in step with the developers, the less time they have in advance of the development phase to carry out their work, and the greater are the resources which must be

C o p yr

ig h t ©

2 0 1 3 . Jo

h n W

ile y

& S

o n s,

I n co

rp o ra

te d . A

ll ri g h ts

r e se

rv e d .