Design centré sur l’utilisateur et développement Agile: perspectives de réconciliation

1. Bujold, A. et Morin-Paquet, S. Design centré sur l’utilisateur et développement Agile : perspectives de réconciliation 1
Design centré sur l’utilisateur et développement
Agile : perspectives de réconciliation
Alexandre Bujold, Sarah Morin-Paquet
Université Laval
alexandre.bujold.1@ulaval.ca,
sarah.morin-paquet.1@ulaval.ca
Introduction
La popularité grandissante des méthodes de développement
Agile préoccupe certains designers d’expérience utilisateur qui
veulent s’assurer que les produits informatiques, peu importe la
méthode utilisée pour les concevoir, soient conçus pour l’utili-
sateur (SY 2007 : 113). En effet, les techniques utilisées par les
développeurs qui suivent la méthode Agile sont souvent, selon
les spécialistes en design centré sur l’utilisateur, inadéquates
pour documenter les comportements complexes des utilisateurs.
LedéveloppementAgileestungroupedeméthodesquipartagent
une philosophie commune. Cette philosophie met de l’avant
l’individu, l’interaction, le logiciel fonctionnel, la collaboration
avec le client et l’adaptation au changement. Elle s’oppose aux
méthodes traditionnelles de développement, dites Waterfall, qui
sont accusées par les adhérents des méthodes Agiles de mettre
l’emphase sur les procédés, les outils, la documentation exhaus-
tive, la négociation de contrats et l’adhésion à un plan.
Les méthodes de design centré sur l’utilisateur, traditionnel-
lement, fonctionnent plutôt dans des processus utilisant une
méthode Waterfall. Ceux-ci impliquent deux grandes phases
au début du processus : une phase d’étude sur l’utilisateur et
son contexte, puis une phase de design. Les méthodes Agiles,
au contraire, n’ont pas de phase dédiée au design. En théorie,
chaque phase contient une part de recherche et de design, mais
en pratique, les techniques de recherche et de design utilisées
se basent surtout sur l’opinion des utilisateurs et la rétroaction,
alors que l’observation et d’autres techniques de design centré sur
l’utilisateur seraient plus adéquates pour certains problèmes (SY
2007 : 113).
Étant donné la popularité grandissante des méthodes Agiles
et l’incompatibilité apparente de ces deux approches, il semble
pertinent de s’intéresser aux tentatives de rapprochement entre
celles-ci en contexte d’entreprise. Premièrement, afin de mieux
comprendre la problématique, nous allons nous attarder aux
différences entre les deux approches. Ensuite, pour voir où elles
sont compatibles, nous ferons ressortir les points communs
entre celles-ci. Finalement, afin d’avoir un aperçu des manières
utilisées pour les réconcilier, nous allons nous intéresser aux
démarches entreprises en contexte réel pour intégrer le design
centré sur l’utilisateur aux méthodes de développement Agile
Différences entre les deux approches
La méthode Agile et la méthode traditionnellement utilisée par le
design centré sur l’utilisateur sont fondamentalement différentes
sur divers points.
Dans un premier temps, le cycle de conception fonctionne d’une
manière très différente. Avec la méthode Agile, le cycle est di-
visé en de nombreux morceaux qui sont appelés « sprints ». Ces
derniers durent généralement de deux à quatre semaines (SY
2007 : 113). Ils donnent naissance à une série de petits livrables
incrémentiels qui sont basés sur la réalisation d’une fonction-
nalité en particulier. Chacune des fonctionnalités possède sa
propre analyse des besoins, sa conception, sa réalisation et sa
phase de test (SY 2007 : 113). Du côté de la méthode Waterfall,
souvent utilisée dans un contexte de design centré sur l’utilisa-
teur, les morceaux du cycle sont beaucoup plus longs et moins
nombreux, d’une durée variant entre plusieurs mois à plusieurs
années (SY 2007 : 113). Les phases de ce cycle sont plus orientés
vers la réalisation du projet final que la réalisation de fonctionna-
lités. Un autre point où le cycle de conception diffère est la façon
dont l’itération est traitée. En effet, la méthode Agile itère sur la
programmation à l’aide de tests automatisés et de la rétroaction
du client concernant des versions fonctionnelles, alors que le
design centré sur l’utilisateur itère principalement sur l’interface
en utilisant des prototypes de basse fidélité. Alors que l’itération
en Agile dure des semaines, l’itération en design est plus courte,
et dure généralement quelques heures ou, tout au plus, quelques
jours (FERREIRA et coll. 2007 : 50). De plus, le processus itératif
de l’Agile est présent à chaque sprint jusqu’à la fin du projet, alors
que dans le design centré sur l’utilisateur, il est principalement
présent en début de projet.
Dans un deuxième temps, l’ordre dans lequel les différentes
phases sont réalisées en l’intérieur du projet global diffère beau-
coup entre les deux méthodes. Tout d’abord, le commencement
d’un projet est très différent principalement en raison des res-
sources qui lui sont attribuées (FOX et coll. 2008 : 67). Du côté du
design centré sur l’utilisateur, le début d’un cycle de conception
est caractérisé par de nombreuses recherches et analyses (FOX et
coll. 2008 : 63). C’est durant cette première phase que les besoins
sont déterminés par l’analyse d’une série de recherches menées
avec l’utilisateur final. Cela est suivi d’une phase de design où
toutes les fonctionnalités sont conceptualisées et intégrées à une

2. Bujold, A. et Morin-Paquet, S. Design centré sur l’utilisateur et développement Agile : perspectives de réconciliation 2
interface qui est par la suite codée (SY 2007 : 114). Idéalement,
dans ce type de méthode, les programmeurs devraient attendre
que les designers aient terminé l’élaboration des interfaces et les
tests d’utilisabilité avant de commencer la programmation, mais
il en est rarement ainsi (SY 2007 : 116). C’est pourquoi, du côté
de la méthode Agile, tout est mis en branle pour réduire, voire
même éliminer la phase de recherche et d’analyse (FOX et coll.
2008 : 63). Le but est de produire le plus rapidement possible une
fonctionnalité qui peut être utilisée plutôt que de produire de
la documentation, qui, à terme, n’est pas toujours utilisée par
les programmeurs puisqu’elle arrive trop tard (SY 2007 : 113).
Bien entendu, les designers sont rarement en accord avec cette
solution, car la modification du code, une fois qu’il est construit,
coûte très cher. Cela mène souvent à l’abandon de certains
critères importants pour l’utilisateur puisqu’ils n’ont pas été pris
en compte dans la première écriture du code et qu’il couterait
désormais trop cher de le modifier (NELSON 2002 : 4). Le déve-
loppement de maquette à basse fidélité est beaucoup moins long
et coûteux que le code et permet de repérer les erreurs avant qu’il
ne soit trop tard (FERREIRA et coll. 2007 : 50). De cette manière,
les interfaces peuvent être testées et il est ainsi possible de s’assu-
rer de leur utilisabilité (FOX et coll. 2008 : 63).
Dans un troisième temps, la relation avec le client est perçue
d’une manière différente dans les deux méthodes. Tout d’abord,
dans l’Agile, une bonne relation avec le client est essentielle au
bon fonctionnement de la méthode. Pour y arriver, une collabo-
ration étroite avec le client, appuyée avec un système de livrables
fréquents, est mise en place (SY 2007 : 113). Le but est d’éviter
les contrats qui nuisent souvent à l’avancement d’un projet et
qui créent des frictions. Dans l’optique d’intégrer le client aux
prises de décisions, un focus group est utilisé pour déterminer
les fonctionnalités qui seront réalisées, et évaluer celles qui ont
déjà été faites (SY 2007 : 113). Par contre, du point de vue du
design, un problème majeur survient lorsque les spécifications
proviennent essentiellement du client. En effet, le client n’a pas
toujours une perception juste des besoins réels des utilisateurs
(NELSON 2002 : 9). Cela conduit à l’élaboration d’un système
qui ne résout pas les problèmes des utilisateurs finaux (NELSON
2002 : 5). Ainsi, le design préfère laisser moins de place aux
clients et prioriser les utilisateurs finaux.
Dans un quatrième temps, la place que l’utilisateur final prend
dans le processus est très différente. Pour commencer, dans le
design centré sur l’utilisateur, l’utilisateur prend un rôle central
dans le développement d’un projet. L’observation des compor-
tements des utilisateurs finaux, notamment à l’aide de tests
d’utilisabilité, est essentielle dans cette méthode (SY 2007 : 117).
Elle doit être faite avant le début de la programmation puisqu’elle
permet de repérer les endroits ou le système ne répond pas aux
attentes de l’utilisateur (NELSON 2002 : 3). Pour le design centré
sur l’utilisateur, la compréhension de l’utilisateur doit permettre
d’établir une liste de critères auxquels les programmeurs doivent
répondre en fonction du budget qu’ils ont. Le code, de par son
coût, ne devrait pas établir ces critères, il devrait plutôt être au
service de l’utilisateur final (NELSON 2002 : 5). Le but ultime
du design est de concevoir une interface utile et utilisable qui
résout les problèmes des utilisateurs finaux et qui répond à leurs
besoins, mais pour arriver à ce résultat, une phase de recherche
avec l’utilisateur est essentielle. Du côté de l’Agile, la place laissée
à l’utilisateur final est assez différente, en partie en raison de la
relation étroite qui est entretenue avec le client. Comme vue
précédemment, le client prend énormément de place dans le
processus et c’est en bonne partie de lui que viennent les idées
pour les fonctionnalités. Dans le but de tout de même répondre
aux besoins de l’utilisateur final, un membre de l’équipe Agile
prend le rôle de customer. Cet individu doit, avec les connais-
sances qu’il possède, représenter l’utilisateur final dans la prise
de décision (SY 2007 : 114). Malheureusement cette technique ne
permet pas d’effectuer des tests d’utilisabilité. Il est donc admis
que la méthode Agile ne conduit pas toujours à un système dont
l’interface est utilisable (Patton d’après FOX et coll. 2008 : 63).
Plusieurs projets Agiles ont toutefois recours au design d’interac-
tion, mais l’intégration de celui-ci dans le processus est encore
mal comprise (FERREIRA et coll. 2007 : 50). Les tests utilisés par
l’Agile ne sont pas réalisés par des experts. Ils sont conduits de
manière automatique et ils ont pour but d’inspecter le code afin
de s’assurer que toutes les fonctionnalités puissent fonctionner
ensemble (FERREIRA et coll. 2007 : 50). Si cela n’est pas un gage
d’utilisabilité, les développeurs peuvent au moins s’assurer du
bon fonctionnement de l’ensemble.
Dans un cinquième temps, la flexibilité des deux méthodes varie
énormément. L’Agile est reconnu comme étant une méthode
très flexible. L’une des règles mères est d’ailleurs de répondre
aux changements plutôt que de suivre un plan comme c’est le
cas dans le Waterfall (SY 2007 : 113). Cette méthode, basée sur
la rétroaction (SY 2007 : 115), lui permet d’atteindre de meilleurs
résultats puisque le contrôle sur le processus est plus grand
(NELSON 2002 : 2). Il est ainsi possible de réorienter le projet au
fur et à mesure que de nouveaux éléments sont découverts dans
le processus (NELSON 2002 : 10). Du point de vue de l’Agile, le
danger du design centré sur l’utilisateur, avec la méthode Water-
fall qui l’accompagne, est de rendre très difficile les changements
une fois que la phase de design est terminée, et ce, même si de
nouveaux éléments de connaissances du problème se sont ajou-
tés (FERREIRA et coll. 2007 : 51). En effet, la méthode Waterfall
est axée sur la réalisation d’un plan conçu en début de projet,
provenant des études préliminaires (NELSON 2002 : 6).
Points communs entre les deux
approches
Malgré les différences fondamentales qui éloignent la méthode
Agile et le design centré sur l’utilisateur, quelques points com-
muns sont apparents et laissent penser que ces deux méthodes,
avec des efforts, pourraient peut-être un jour se réconcilier.
Premièrement, la méthode Agile et le design centré sur l’uti-
lisateur sont tous deux perçus comme étant des processus
itératifs (SY 2007 : 115 ; FERRAIRA et coll. 2007 : 1). Les deux
méthodes sont axées sur l’amélioration, le changement et le raf-

3. Bujold, A. et Morin-Paquet, S. Design centré sur l’utilisateur et développement Agile : perspectives de réconciliation 3
finement ; elles le font tout simplement d’une manière différente
(FERREIRA et coll. 2007 : 57). L’itération dans l’Agile est à la base
du fonctionnement de cette méthode. Elle se retrouve autant
dans la courte durée de sprints que dans le choix des livrables.
L’objectif est d’améliorer le système tout au long de sa construc-
tion. Du côté du design centré sur l’utilisateur, l’itération se
produit principalement lors des tests d’utilisabilité qui ont pour
but l’amélioration des maquettes avant leur production (FOX et
coll. 2008 : 64).
Deuxièmement, le design centré sur l’utilisateur et la méthode
Agile mettent tous les deux l’accent sur l’importance des tests,
des livrables et de l’humain, mais ils le font différemment
(FERREIRA et coll. 2007 : 50). Pour ce qui est des tests, tel que
vu précédemment, les deux méthodes les emploient. Ils font
partie du processus itératif et ils sont nécessaires pour assurer un
produit fini de qualité (FERREIRA et coll. 2007 : 55). La qualité
et la valeur du livrable sont d’ailleurs un autre point commun aux
deux méthodes (FERREIRA et coll. 2007 : 50). Le but de l’Agile
est de livrer des fonctionnalités de qualité et qui fonctionnent
bien, et ce, à une fréquence rapide. Pour le design centré sur
l’utilisateur, il est également important que le livrable soit de
qualité, mais cela passe par une interface utilisable (FOX et coll.
2008 : 63). Finalement, les deux méthodes mettent l’humain au
cœur du processus. Du côté du design, cela nécessite de toujours
garder l’utilisateur final en tête. C’est également la façon de pen-
ser de l’Agile, mais plutôt que de compter sur des tests utilisateurs
et sur une phase de recherche préliminaire pour y arriver, il
donne la responsabilité à un membre de l’équipe, le customer, de
représenter l’utilisateur final et de donner ainsi une rétroaction
sur la fonctionnalité développée (FOX et coll. 2008 : 64).
Réconciliation entre les deux
approches
Les points communs mentionnés précédemment offrent une
bonne base pour intégrer les deux méthodes, et plusieurs en-
treprises à travers le monde essaient de le faire afin de profiter
des avantages des deux méthodes. Quelques chercheurs se sont
attardés à l’étude de leurs cas, et plusieurs designers ont écrit sur
leurs expériences.
Adaptation du design centré sur l’utilisateur aux
échéanciers Agiles
Étant donné que les plus grandes différences entre le dévelop-
pement Agile et les méthodes de design centré sur l’utilisateur
concernent le temps et le concept de sprints, plusieurs auteurs
ont étudié la réconciliation des deux domaines sur ces points.
Par exemple, pour mieux intégrer le design centré sur l’utilisa-
teur aux méthodes Agiles, toutes les entreprises étudiées par Fox
et ses collaborateurs (2008 : 67) font appel à une phase dédiée au
design qui précède les phases de développement. Lors de cette
phase initiale, les designers mènent des enquêtes contextuelles
et conçoivent des prototypes basse-fidélité qui permettent
d’orienter les développeurs au niveau du design de l’interface et
de l’utilisabilité.
Sy (2007 : 114) rapporte un phénomène similaire, qu’elle nomme
Cycle Zéro. Cette phase peut impliquer de la collecte de données
afin de raffiner les buts stratégiques du produit, des enquêtes
contextuelles, de la validation de marché, de l’analyse d’enquêtes
précédemment effectuées, ou de la création de personas et de
scénarios.
Toutefois, même si cette étape n’est pas sans rappeler l’étape
initiale d’une méthode de type Waterfall, elle se déroule sur une
échelle de temps beaucoup plus courte et typique des méthodes
Agiles. Selon Fox et ses collaborateurs (2008 : 67), ainsi que Sy
(2007 : 119), le cycle zéro peut durer de quelques jours à plusieurs
semaines, et non quelques mois comme dans un projet de type
Waterfall.
Une fois cette étape passée, les développeurs commencent leur
série des sprints itératifs. Étant donné que l’étape initiale était
plus courte et donc moins productive qu’en Waterfall, le desi-
gner continue d’être impliqué dans le processus. Il doit toutefois
s’adapter au rythme cyclique et rapide des développeurs. Selon
Sy (2007 : 119), il doit devancer les développeurs d’un ou deux
sprints. Par exemple, lors du sprint 1, le designer pourrait être
en train de concevoir et de raffiner des maquettes pour les fonc-
tionnalités du sprint 2, et en train de mener des enquêtes et des
entrevues pour mieux prévoir les fonctionnalités du sprint 3.
Lorsque le sprint 2 arrive, les maquettes sont données au déve-
loppeur, et le designer effectue des tests sur les fonctionnalités
du sprint 1 en plus de travailler sur les sprints 3 et 4. Ce cycle est
ensuite répété jusqu’à la fin du projet.
Fox et ses collaborateurs (2008 : 68) proposent un modèle
semblable à celui de Sy (2007), à la différence près que, selon
Fox, l’échange d’information entre les deux branches ne se fait
pas qu’à la fin de chaque sprint. Ferreira et ses collaborateurs
(2007 : 50) citent aussi Patton et Miller comme étant d’autres cas
où le design d’interaction a été adapté ainsi pour concorder avec
les itérations rapides des méthodes Agiles.
Selon Sy (2007 : 120), le designer doit aussi, pour accommoder
les courtes périodes d’itération de l’Agile, être capable de diviser
son travail en morceaux qui peuvent être terminés pendant un
sprint et qui, éventuellement, formeront le design complet. Étant
donné que les designers centrés sur l’utilisateur ont tendance
à s’intéresser à l’expérience globale d’un design, ce processus,
appelé « Design chunking », peut être difficile pour plusieurs.
Cette idée était centrale au premier projet décrit par Ferreira
et ses collaborateurs (2007 : 52), ou l’interface et les scénarios
d’utilisation étaient générés au fur et à mesure.
Intégration du design centré sur l’utilisateur dans les
structures de travail
Même si les développeurs Agiles et les designers travaillent
en parallèle, Sy (2007 : 127) maintient qu’ils doivent être en
communication tous les jours. Cela permet, non seulement au
designer de s’assurer que ses recommandations sont appliquées
correctement, mais aussi de bien comprendre les contraintes
technologiques qui pourraient avoir un impact sur le design. Un

4. Bujold, A. et Morin-Paquet, S. Design centré sur l’utilisateur et développement Agile : perspectives de réconciliation 4
des designers d’interfaces interrogés par Ferreira et ses collabo-
rateurs (2007 : 57) note que la communication quotidienne entre
les développeurs et le designer change profondément la relation
entre les intervenants de ces deux disciplines. Contrairement à
un projet de type Waterfall, le designer n’a pas à produire un de-
sign complet et final que le développeur doit ensuite réaliser. Le
processus est beaucoup plus collaboratif et le designer est mieux
intégré au reste de l’équipe.
Il existe plusieurs façons pour intégrer un designer, ou toute per-
sonne qui pratique le design centré sur l’utilisateur, à une équipe
de travail Agile. Fox et ses collaborateurs (2008 : 68) dénombrent
trois grandes approches, qui diffèrent quant aux rôles dans
l’équipe de développement qu’occupe la personne responsable
du design centré sur l’utilisateur.
La première approche est l’approche spécialiste. Dans celle-ci,
l’équipe comporte un spécialiste en design centré sur l’utilisateur
qui oeuvre séparément des développeurs et qui sert souvent de
pont entre ces derniers et le client. D’ailleurs, Miller (d’après SY
2007 : 4), suggère que le designer peut travailler en collaboration
avec une équipe Agile en jouant le rôle du customer, c’est-à-dire la
personne sensée représenter l’utilisateur final du produit auprès
de l’équipe de développement.
Dans la deuxième approche, l’approche généraliste, l’équipe ne
comporte pas de spécialiste en design centré sur l’utilisateur
(FOX et coll. 2008 : 68). En son lieu, des développeurs qui pos-
sèdent une expertise informelle en design remplissent ces fonc-
tions. Habituellement, plusieurs développeurs jouent ce rôle.
Cette approche a pour avantage que les personnes responsables
de détecter des problèmes d’utilisabilité sont aussi capables de
les réparer sans délai. La dynamique de l’équipe est beaucoup
moins formelle que lorsqu’un spécialiste dédié au design centré
sur l’utilisateur est présent.
Enfin, la troisième approche, l’approche généraliste-spécialiste,
est à mi-chemin entre les deux autres approches. Dans celle-ci,
un membre de l’équipe avec autant d’expertise technique que
d’expertise en design agit comme pont entre les développeurs
et une petite équipe de spécialistes. Cette approche est surtout
utilisée dans des entreprises de grandes tailles.
Adoption de la philosophie Agile dans les méthodes
de design centré sur l’utilisateur
En plus de devoir ajuster sa pratique professionnelle en adaptant
ses échéanciers aux sprints itératifs de la méthode Agile et aux
nouvelles dynamiques d’équipe amenées par cette méthode, le
designer doit aussi adapter certaines de ses façons de penser et
de travailler.
Par exemple, même si une phase initiale de collecte de données
et de prototypage est possible, le designer devrait être conscient
que, étant donné la nature itérative du développement Agile,
l’interface changera probablement au fil du projet à cause de
fonctionnalités annulées ou changées.
Le designer doit aussi composer avec quelques difficultés en
ce qui concerne les tests utilisateurs. En effet, la nature incré-
mentale de l’Agile rend difficile tout test qui voudrait s’attarder
à une utilisation globale et naturelle de l’interface, et la courte
durée des itérations limite le nom de tests possibles pendant
un sprint (SY 2007 : 12). Afin de remédier à ce problème, il est
possible d’appliquer la philosophie Agile aux tests utilisateurs.
Par exemple, le designer peut créer un test de base et le bonifier à
chaque itération pour tester les nouvelles fonctionnalités. Il peut
aussi rassembler plusieurs problèmes de design en un seul test
afin de sauver du temps (SY 2007 : 14)
Il se peut aussi que le designer doive changer ses habitudes de
présentation de l’information aux développeurs. Par exemple, il
pourrait réduire le nombre de longs livrables écrits en faveur de
discussions quotidiennes avec les développeurs (SY 2007 : 15).
C’est ce qu’a fait Sy après avoir réalisé que les informations utiles
pour l’équipe de développeurs (par exemple, les résultats de tests
d’utilisabilité, sur quels designs elle est en train de travailler, les
recommandations ou les corrections, les informations sur l’uti-
lisateur et sa tâche, et les designs à implanter au prochain sprint)
n’avaient de valeur qu’avant d’être utilisées et n’avaient donc pas
besoin d’être mises sur papier.
Conclusion
En conclusion, le design centré sur l’utilisateur et la méthode
Agile sont différents sur de nombreux points. Il est possible de
trouver ces différences notamment au niveau de la longueur que
chaque phase prend à l’intérieur du projet, ainsi que le moment
où celles-ci sont effectuées dans le cycle global. De plus, de
nombreuses différences sont également présentes au niveau de
la relation avec le client, de la place de l’utilisateur final dans le
processus et la flexibilité de chacune des méthodes. Malgré ces
différences, le design centré sur l’utilisateur et la méthode Agile
partagent des caractéristiques communes. Les deux approches
reposent notamment sur un processus itératif. Aussi, elles
accordent beaucoup d’importance à la qualité des livrables, à
la place de l’humain dans le processus de création et aux tests.
Ces similarités mettent la table pour une possible réconciliation
entre les deux approches. Pour y arriver, le designer adapte son
approche afin d’être capable de suivre le rythme plus rapide d’un
projet Agile. Ensuite, plusieurs méthodes potentiellement sont
utilisables pour intégrer le design centré sur l’utilisateur dans les
structures du travail Agile. Finalement, pour que la réconcilia-
tion soit efficace, le designer doit adopter la philosophie Agile.
Malgré que la pratique du design centré sur l’utilisateur ne soit
pas encore très répandue au sein des organisations dites Agiles,
il est certainement possible de le faire. Toutefois, cette réconci-
liation entre les deux approches ne se fait pas sans heurts. Pour
le designer, de grands changements dans ses méthodes de travail
sont à adopter. Certes, les techniques présentement utilisées
sont encore jeunes, mais celles-ci montrent déjà des résultats
satisfaisants. Cela laisse présager un avenir resplendissant pour
l’utilisation conjointe de ces approches qui offrent toutes deux de
grands avantages (FOX et coll. 2008 : 71).

5. Bujold, A. et Morin-Paquet, S. Design centré sur l’utilisateur et développement Agile : perspectives de réconciliation 5
Bibliographie
NELSON, E. (2002). « Extreme Programming vs. Interaction De-
sign » [page Web archivée], Fawcette. Retrouvé le 22 avril 2014 à
http://web.archive.org/web/20031206035039/http://www.faw-
cette.com/interviews/beck_cooper/page10.asp
SY, D. (2007). « Adapting Usability Investigations for Agile
User-centered Design », Journal of Usability Studies, 2 (3),
p. 112-132.
FOX, D., SILLITO, J. et MAURER, F. (2008). « Agile Methods
and User-Centered Design : How These Two Methodologies Are
Being Successfully Integrated In Industry », Agile 2008 Confe-
rence, p. 63-72.
FERREIRA, J., NOBLE, J., et BIDDLE, R. (2007). « Agile
development iterations and UI design », Agile Conference 2007,
p. 50-58.