Design centré sur l’utilisateur et développement Agile: perspectives de réconciliation
6 j'aime11,863 vues
Ce document examine la tension entre les méthodes de développement agile et le design centré sur l'utilisateur, mettant en lumière leurs différences fondamentales en matière de cycles de conception, d'itérations, de relations client et de place de l'utilisateur final. Bien que ces approches semblent incompatibles, il existe des points communs qui pourraient permettre une réconciliation, telles que l'importance des tests et la nature itérative des deux méthodes. Des efforts sont en cours dans certaines entreprises pour intégrer ces pratiques, notamment par la mise en place de phases de design accélérées avant le développement agile.
![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.](https://image.slidesharecdn.com/bujoldmorin-paquetsynthese-140724105657-phpapp02/85/Design-centre-sur-l-utilisateur-et-developpement-Agile-perspectives-de-reconciliation-5-320.jpg)
Contenu connexe
![Porque se recomienda el uso de[1]](https://cdn.slidesharecdn.com/ss_thumbnails/porqueserecomiendaelusode1-130313113751-phpapp02-thumbnail.jpg?width=560&fit=bounds)
Similaire à Design centré sur l’utilisateur et développement Agile: perspectives de réconciliation (20)
![[lecture] Faut-il mesurer la bande passante du design ?](https://cdn.slidesharecdn.com/ss_thumbnails/bandepassante-160827092121-thumbnail.jpg?width=560&fit=bounds)
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 [email protected], [email protected] 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.