Agile UX : comment intégrer l'expérience utilisateur et la conception de produits dans Agile

DevOps est souvent défini comme les processus, les opérations, les méthodologies, les outils et la culture entourant le développement de logiciels et de systèmes d'une entreprise.

Mais l'ingénierie ne fonctionne pas dans le vide. Les plans, les idées, les conceptions et les concepts proviennent de spécialistes de la conception de produits qui décident des mises en page, des flux et de l'interactivité. Il s'agit d'individus et d'équipes non ingénieurs qui partagent les objectifs et les résultats souhaités de DevOps.

DevOps va bien au-delà de la manière dont les développeurs se connectent à l'informatique, dont l'infrastructure est gérée et dont les frameworks peuvent être améliorés. Il s'agit de reconnaître combien d'équipes sont réellement impliquées dans le processus de développement logiciel, à quel point leurs rôles et leur travail sont imbriqués, et de trouver de meilleures façons de s'assurer que tout le monde est à la table.

Les développeurs et les architectes d'ingénierie veulent être impliqués lorsque les équipes produit et créatives conçoivent le logiciel ou le système. Mais où est-ce dans la définition actuelle de DevOps ? Les équipes produit, UX et créatives veulent rester impliquées pendant les processus d'ingénierie, mais de nombreuses méthodologies les excluent. Ce sont de vieux silos que nous devons briser.

Vos clients ne voient que votre expérience utilisateur (UX). Ils ne voient pas combien de développeurs vous aviez ou si vous étiez Agile ou Lean. Ils n'ont aucune idée des outils DevOps utilisés. L'UX de votre entreprise est le produit, et il peut vous faire ou vous défaire. Ils se demandent qui a construit ce morceau de ferraille. Avec autant de concurrence et de gens heureux de désinstaller une application ou de quitter un site Web, aurez-vous une seconde chance avec le client qui vous a abandonné ?

Agile forme rarement sur UX ou travaille avec des spécialistes UX

De nombreuses équipes d'ingénierie trouvent souvent que l'expérience utilisateur est cloisonnée et difficile à collaborer. UX ne semble pas Lean et de nombreuses variantes d'Agile excluent les détails sur la façon de travailler avec UX. Certaines approches Agiles suggèrent spécifiquement qu'un propriétaire de produit décrivant une fonctionnalité est "assez bon".

SAFe Agile fait l'erreur de décider que la meilleure façon de résoudre le cloisonnement UX est de les exclure complètement. SAFe « permet aux équipes Agile » de faire leur propre « Lean UX ». Alors que de plus en plus d'entreprises comprennent la valeur de l'intégration de spécialistes UX et d'un processus UX complet, SAFe va dans la mauvaise direction.

L'absence d'explications sur l'UX et leurs processus dans les formations et les livres Agile a conduit des équipes du monde entier à exclure ou à minimiser l'implication de concepteurs de produits spécialisés.

• Lorsque vous imaginez à tort que UX ne fait que dessiner des cases sur les pages, il est facile de supposer "Je peux faire ce travail". Comme tant d'auditionnés d'American Idol sont sûrs d'être le meilleur chanteur de la planète, la plupart des chefs de produit et des ingénieurs s'auto-évaluent comme étant excellents en UX. Cela signifie normalement qu'ils pensent qu'ils sont doués pour disposer des écrans. Mais comme cet article explique ce qui se passe vraiment dans le travail UX, vous verrez comment un spécialiste UX ne verrait pas un développeur qui crée des wireframes comme quelqu'un qui devrait se voir confier des tâches UX.
• Les livres sur Scrum suggèrent que si un spécialiste UX devient un goulot d'étranglement, il doit former des rôles non UX pour faire son travail. Ce type de décision est rarement suggéré pour d'autres rôles dans le développement de logiciels ; personne ne voudrait qu'un développeur non formé ou inexpérimenté fasse le codage, même après un bootcamp ou la lecture d'un livre sur la programmation. Nous ne suggérons jamais que si un développeur devient un goulot d'étranglement, il doive former le chef de projet à faire du codage.
• Les responsables du recrutement qui croient à tort que l'UX est un travail artistique (UI) embauchent des artistes pour faire du travail UX. Il n'y a pas de chevauchement pédagogique entre un diplôme en UX et en UI. Les talents naturels ne se chevauchent souvent pas ; quelqu'un d'excellent en UX peut être un mauvais artiste et vice versa. L'embauche pour "UX / UI" vous offre souvent un grand artiste avec une expérience, une expertise, un processus ou une éducation UX minimale.

Ceux qui ne regardent que le résultat net aimeraient réduire le budget en confiant des tâches UX à des personnes qui pourraient manquer d'éducation, d'expérience, d'expertise, de compétences ou de talent naturel en matière d'UX. Mais cela est à courte vue et peut conduire à une productivité, une efficacité, une culture, un produit et une satisfaction client médiocres.

L'importance d'intégrer des spécialistes experts en UX dans Agile

Fin 2018, le cabinet de conseil en management McKinsey & Company a publié « The Business Value of Design », un rapport sur les recherches qu'ils ont menées auprès de plus de 300 entreprises.

Ils ont découvert que « le design est le seul moyen pour les entreprises de se démarquer de la foule ». Lorsque les concurrents ont des ensembles de fonctionnalités proches, qu'est-ce qui les distingue ? Le design est parfois considéré comme simplement l'esthétique ou ce qui fait que cela ressemble à notre marque. Mais lorsqu'il est utilisé avec "UX", le design signifie l'architecture des fonctionnalités et les décisions prises concernant les écrans, les étapes, les flux, les mises en page, les processus, l'organisation et les menus.

L'UX fait partie du processus d'amélioration continue, cherchant toujours à mieux comprendre les utilisateurs et à sélectionner et concevoir les fonctionnalités et le produit qui correspondent le mieux à leurs besoins, à résoudre leurs points faibles et à leur apporter une innovation significative.

McKinsey a également signalé que « les entreprises doivent adopter la conception de manière holistique et tôt dans le processus plutôt que de la considérer comme un petit outil qui s'intègre plus tard ». Les équipes qui supposent que l'attention portée à l'expérience utilisateur est quelque chose qui peut être minimisée, exclue ou effectuée après la sortie du produit adoptent la mauvaise approche.

McKinsey a collecté des données quantitatives et a constaté que les entreprises qui ont adopté la conception UX ont généré 32 % de revenus supplémentaires et 56 % de retours supplémentaires pour les actionnaires sur une période de 5 ans. Déclarer que votre entreprise est « centrée sur l'utilisateur » ne suffit pas. Vous devez suivre le chemin en intégrant les praticiens et les processus UX depuis la planification et le portefeuille jusqu'au développement et à l'assurance qualité.

Processus de développement logiciel avec et sans UX

Si votre entreprise n'inclut pas de spécialistes UX dans le processus de conception et de développement de logiciels, votre processus ressemblera probablement à l'image ci-dessous.

Un client, un chef de produit, un PDG ou une personne visionnaire dit à l'ingénierie ce qu'il veut. L'ingénierie le construit, le teste et le place sur un serveur intermédiaire ou de production. La personne qui a la vision la voit alors et, ne le savez-vous pas, elle n'est pas contente. Ils veulent quelque chose de différent ou ont changé d'avis.

L'ingénierie doit ensuite revenir au début, découvrir ce que cette personne veut maintenant, construire, tester et croiser les doigts pour que ce soit le charme.

Si vous avez des experts UX dans l'équipe, le processus est assez différent. Cette personne avec la vision vient à UX avec les idées, les données et les points faibles des clients. UX parcourt les tâches de son processus de conception centré sur l'utilisateur, puis teste ces concepts avant que l'ingénierie n'écrive une ligne de code. Cela garantit que le produit ou la fonctionnalité que nous envisageons de créer est la bonne exécution de la bonne idée pour nos clients cibles.

Les tests peuvent mettre en lumière certaines failles, ce qui permet à UX d'itérer et souvent de tester à nouveau. Après le processus UX, vous avez une conception entièrement vérifiée prête à être livrée à l'ingénierie.

Si quelqu'un change d'avis en cours de route, cette personne parle à UX plutôt que de le présenter comme une demande de changement aux développeurs. L'UX génère des interférences au cours de leur processus et rien n'est envoyé à l'ingénierie sans que l'UX ne soit impliqué dans les conceptions, les décisions et les tests sur des clients réels ou archétypaux.

Les changements d'avis à ce stade ne sont pas des catastrophes puisque le coût pour quelqu'un de changer d'avis à ce stade est minime. L'ingénierie n'a pas reçu les plans, ils n'ont pas commencé et n'ont rien à reconstruire. UX itère sur leurs conceptions et peut effectuer des tests utilisateur pour s'assurer que les idées correspondent bien à la clientèle. Les changements d'avis brûlent du temps, mais l'impact global sur le budget est faible.

UX a un processus formalisé

La conception centrée sur l'utilisateur (UCD) est un processus formalisé qui comprend des tâches qui dirigent les spécialistes UX vers la recherche, la conception, le prototype, le test sur des utilisateurs réels ou archétypaux, puis itèrent en fonction des enseignements tirés des tests.

En nous concentrant sur quelques-uns de ces domaines, nous commençons par les exigences et les premières discussions sur les fonctionnalités et les projets. Lorsque UX obtient pour la première fois les exigences et d'autres informations sur le projet, il est important de commencer à collaborer immédiatement. UX ne devrait PAS découvrir plus tard qu'il a conçu quelque chose qui ne peut pas être construit.

Commencez par faire appel à des travailleurs ou à des responsables UX lorsque les chefs de produit ou de projet décident des fonctionnalités et de la priorisation. Un projet sans valeur pour l'utilisateur peut être supprimé, ce qui permet d'économiser du temps et de l'argent. C'est là qu'entre en jeu la maximisation de la quantité de travail non effectué. Le produit et l'ingénierie doivent prendre en charge l'expérience utilisateur lorsqu'ils créent moins de travail pour l'ingénierie en réduisant ou en supprimant des fonctionnalités ou des projets entiers. Cependant, trop souvent, les projets ont un ego attaché et les coéquipiers excluent souvent l'UX de ces premières conversations afin que le projet soit financé.

La recherche est un élément important de ce que fait l'UX. Ce n'est pas centré sur l'utilisateur sans impliquer les utilisateurs. Les statistiques et les données quantitatives sont excellentes, mais rien ne remplace l'interview des utilisateurs, leur compréhension approfondie et l'obtention de données qualitatives. UX veut savoir le pourquoi et pas seulement le quoi.

La recherche UX met également les coéquipiers sur la même longueur d'onde en unifiant tout le monde autour de personas, archétypes de clients cibles. Sur la base d'entretiens avec des utilisateurs, nous regroupons ce que nous apprenons et réduisons tout le monde à 6 personnes ou moins. Qu'est-ce qui les motive ? De quoi ont-ils besoin ? Où sont les opportunités pour notre entreprise, produit ou service ?

La meilleure utilisation des personas serait de les inclure partout. Le produit imagine des fonctionnalités basées sur des personas (et de bonnes données). Conceptions UX basées sur des personas. QA teste en imaginant qu'il s'agit de ces personas. Le marketing peut ajouter ses détails démographiques et autres, mais il doit également tenir compte de la façon dont la voix de la marque, les médias sociaux et la publicité parlent aux personnages.

Les personas aident les travailleurs non UX à s'éloigner de "Eh bien, j'aime ça comme ça" ou "Le PDG aime ça comme ça". Nous concevons pour ces clients cibles et si vous ou le PDG ne correspondez pas aux personnages, alors UX n'est pas influencé par l'ego ou les préférences personnelles. L'UX doit rester centrée sur le client.

L'architecture de l'information concerne les hiérarchies, la structure et les taxonomies. Il peut s'agir de la navigation sur le site ou de la manière dont les produits sont classés dans une base de données de commerce électronique. Nous voulons nous assurer que les clients trouveront facilement des produits par catégories, métadonnées et filtres.

Le design d'interaction , parfois aussi appelé design d'expérience, est ce à quoi la plupart des gens pensent lorsqu'ils imaginent UX. Ce sont les wireframes et les prototypes, les plans des conceptions et des concepts. Ceux-ci montreraient les flux de processus, les mises en page, les menus, les interactions, les chemins, les choix et bien plus encore.

Les prototypes UX sont comme des wireframes qui prennent vie. Ce sont des maquettes numériques cliquables et interactives. Nous n'avons pas à écrire de code ; nous avons un logiciel qui nous aide à les créer rapidement. Les entreprises à la recherche de prototypes plus réalistes utilisent Axure car il dispose d'une logique conditionnelle, de variables, de gestes de balayage mobile, de glisser-déposer et de toutes sortes de déclencheurs d'événements. Vous pouvez prototyper pour à peu près n'importe quel type d'appareil.

Le prototypage UX est fait pour :

• idée de génie
• Collaborer
• Répéter
• Explorer les solutions
• Pitch aux investisseurs (pour les startups)
• Testez le prototype pour voir si la solution se connecte bien avec le ou les publics cibles.
• Fournissez un modèle interactif aux développeurs ou à d'autres coéquipiers, ce qui est souvent préféré aux pages de documentation (et pas de modèle cliquable).

Maintenant, il passe aux tests utilisateur , également appelés tests d'utilisabilité, qui se produisent pendant le processus UX et avant que l'ingénierie n'écrive une ligne de code. Vous devez tester les concepts et les conceptions pour vous assurer que l'idée et l'exécution sont fantastiques pour les clients cibles.

Les tests utilisateurs mettront en lumière tous les défauts, donnant à UX la possibilité d'itérer sur des idées, ce qui est peu coûteux à ce stade car il n'y a rien à construire ou à reconstruire pour l'ingénierie.

Il y a 5 raisons principales pour lesquelles UX exécute des tests avant de livrer à l'ingénierie :

1. Meilleure utilisation du temps et des ressources de l'ingénierie. Si vous voulez que les participants aux tests voient un produit fini créé par des ingénieurs, vous devez le construire et le tester pour détecter les bogues. Si les tests UX mettent en lumière les modifications nécessaires, les développeurs devraient reconstruire et le QA devrait re-tester. Si les tests UX ont montré un échec plus important du concept, cela pourrait signifier que le temps de l'ingénierie a été complètement perdu car ce n'est pas du code qui finira n'importe où. Le concept devrait être repensé, repensé et fraîchement testé.
2. Itérer dans les coulisses. Lorsque les entreprises se contentent de le construire, de l'expédier, de l'itérer, de le construire et de l'expédier à nouveau, cela signifie que les clients voient une variété de versions. Ils voient le travail en cours et regardent la fabrication de la saucisse. Il s'agit souvent d'une expérience frustrante et déroutante qui oblige les clients à réapprendre sans cesse un système en constante évolution. Il est préférable d'itérer dans les coulisses du processus UX et d'être clair avec les testeurs qu'il s'agit d'un prototype ou d'une version de démonstration.
3. Surveillance et mesure. Si un nouveau concept est publié en direct, les chercheurs UX n'ont pas un bon moyen de regarder les gens l'utiliser, de leur poser des questions et d'obtenir le type de commentaires dont UX a besoin pour déterminer si quelque chose est prêt ou nécessite une autre itération. L'UX veut toujours savoir le pourquoi, le qualitatif, et pas seulement le quoi ou le combien. Comment les utilisateurs dépensent-ils, convertissent-ils, interagissent-ils, etc. ? Éviter les tests UX appropriés rend plus difficile le diagnostic et la résolution des problèmes ou des points faibles des clients.
4. Les tests UX sont payants. Les tests UX ne représentent pas une dépense énorme. Certains outils de test tiers demandent moins de 100 $ par participant au test, certains exigent un engagement annuel minimum de milliers de dollars. Ce ne sont pas des dépenses énormes compte tenu du budget global de l'entreprise pour le processus de développement logiciel et de l'importance des retours d'information sur les tests précoces. Les séries de tests utilisateurs coûtent presque toujours moins cher et vont plus vite que de demander aux programmeurs de construire quelque chose que nous pourrions avoir à défaire ou à reconstruire.
5. Les tests utilisateurs résolvent les arguments. Si votre entreprise ne permet pas aux spécialistes UX de prendre la décision finale sur la façon dont le produit est conçu, alors vous pourriez trouver UX en conflit avec le produit, l'ingénierie ou une partie prenante lorsqu'il y a différentes idées de ce qui devrait être construit et publié au client. Ou que se passe-t-il si UX a deux idées fortes et qu'ils se demandent laquelle se connecte le mieux avec les clients ? La solution ici est le test utilisateur.

UX peut prototyper les concepts. Il est préférable de réduire la concurrence aux deux meilleurs designs, surtout si vous pouvez déjà trouver des compromis entre les idées et les membres de l'équipe. Cela signifie que nous ne testons pas ce que l'UX veut par rapport à ce que le produit aime par rapport à ce que le chef de l'ingénierie aime par rapport à ce que le scrum master pense être une bonne idée par rapport à ce que le partenaire de vie du PDG aime.

Les tests utilisateurs permettent aux clients de s'exprimer et vous aident à trouver la bonne direction pour les fonctionnalités ou le produit. Il résout les arguments en fournissant aux équipes des données quantitatives et qualitatives précises qui indiquent à chacun quelle idée est susceptible d'apporter le plus de satisfaction client.

Ce n'est pas une conception centrée sur l'utilisateur sans impliquer l'utilisateur. Cela signifie que nous recherchons et testons avec des clients réels ou archétypaux plutôt que de deviner, de supposer ou de « simplement l'expédier ». Nous devons nous assurer que ce que nous « livrons juste » a été vérifié par des tests utilisateurs et est une excellente exécution d'une excellente idée.

Que se passe-t-il lorsque l'UX est contournée ou réduite ?

Skype a récemment annoncé que sa refonte de 2017, qui visait à le faire ressembler davantage à Snapchat, était un échec. Les utilisateurs ne voulaient pas, n'avaient pas besoin ou n'aimaient pas les nouvelles fonctionnalités. Le contrecoup était suffisamment important pour que Skype annonce en 2018 qu'il reconcevoirait à nouveau Skype. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

Les experts UX auraient su à de nombreuses étapes de leur processus que ces fonctionnalités étaient susceptibles d'être indésirables ou d'échouer. Des recherches auprès des utilisateurs cibles auraient pu rapidement révéler qu'ils ne souhaitaient pas que Skype devienne Snapchat. Tuer le projet ou pivoter à ce stade précoce aurait pu faire économiser à Skype des millions de dollars, ainsi que la mauvaise presse et l'aliénation des clients.

Même si la recherche UX avait été contournée, tester un prototype UX sur les utilisateurs aurait clairement indiqué que les clients ne voulaient pas que Skype aille dans cette direction. L'UX étant toujours en cours de développement, l'ingénierie n'a pas encore écrit une ligne de code. Cela aurait pu économiser énormément de temps, d'argent et de ressources humaines, en célébrant la simplicité et le travail que l'ingénierie n'avait pas à faire.

Processus Agile UX

Rappelez-vous les principes du manifeste Agile. Votre priorité absolue est la satisfaction du client en créant des logiciels de valeur. Donnez aux travailleurs (UX) l'environnement et le soutien dont ils ont besoin, en leur faisant confiance pour faire le travail. Maximiser la quantité de travail non fait. Une attention continue à une bonne conception améliore l'agilité.

Les projets qui vont de l'avant doivent donner à UX une énorme piste afin que la recherche, la conception et les tests appropriés puissent commencer. N'invitez pas les UX à votre réunion de lancement et surprenez-les avec l'exigence que les wireframes finaux soient livrés dans quelques jours. Ce n'est pas UX.

Ne considérez pas cela comme Big Design Up Front (BDUF), qui est un terme conçu pour faire grincer des dents et déclarer que c'est quelque chose dont nous devons nous éloigner. Lorsqu'un projet ou une fonctionnalité est vaste ou nouveau, il est nécessaire que l'expérience utilisateur parcoure la plupart, sinon la totalité, du processus de conception centré sur l'utilisateur. Pour UX, la plus petite pièce possible pour une fonctionnalité plus grande est le flux de travail ou le processus de l'utilisateur. Si nous concevons et testons quelque chose de plus petit, nous courons le risque de ne pas avoir une vue d'ensemble de la véritable expérience utilisateur.

Par exemple, si nous concevons un flux où les utilisateurs s'inscrivent et achètent, nous ne pouvons pas simplement concevoir des champs de sélection de mot de passe et les soumettre à l'ingénierie. Si UX fonctionnait en petits morceaux, quand l'ensemble du processus serait-il testé ? Nous ne pouvons pas connaître la réaction de l'utilisateur à l'intégralité du flux sans tester l'intégralité du flux… ce qui signifie que l'intégralité du flux doit être conçue avant de passer aux tests d'utilisabilité.

Lorsque les fonctionnalités, les histoires ou les correctifs sont petits, les praticiens UX peuvent effectuer un sous-ensemble du processus de conception centré sur l'utilisateur et travailler plus rapidement. L'UX ira toujours aussi vite que possible, mais une grande spécialiste de l'UX fera tout son possible pour ne pas sacrifier la qualité du travail effectué. Dans la bataille rapide contre bon, UX choisira toujours le bon plutôt que le rapide… et vous devriez aussi.

Les budgets et les délais sont ce qui empêche l'expérience utilisateur d'obtenir des commentaires et des itérations rapides. Les praticiens UX veulent toujours des commentaires et la possibilité d'améliorer le produit, dans le but de concevoir ce qui fonctionne vraiment pour les clients. Faire intervenir des praticiens UX dès la gestion et la planification du portefeuille permet à UX d'estimer le temps et le budget dont ils auront besoin ; ceux-ci ne devraient pas être plus tard des surprises ou des causes de conflit.

Un praticien UX fait partie de l'équipe Agile

Intégrez votre UX Designer dans l'équipe Agile. Invitez-les à publier la planification, le stand-up, le rétro et toutes les réunions où l'UX pourrait être discuté. Permettez à UX d'estimer son temps lors de la planification des versions afin qu'il n'y ait pas de surprises quant au calendrier que les tâches UX nécessiteront. Ne prenez pas de décisions sans eux. Si votre coéquipier UX a manqué la réunion, attendez de pouvoir le trouver en personne, par chat, par e-mail ou par toute autre méthode utilisée par votre entreprise.

Attribuez des questions, des ambiguïtés ou des bogues à votre coéquipier UX dans JIRA ou tout autre système de suivi des bogues que vous utilisez. Assurez-vous que les problèmes UX sont dans le même système que les autres problèmes ; ne supprimez pas les problèmes UX dans un tableau Trello si vous utilisez VersionOne pour tout le reste.

Une fois que l'UX a eu sa longue piste, si cela était nécessaire pour cette fonctionnalité ou ce produit, une bonne pratique consiste à faire en sorte que l'UX ait 2 sprints ou plus avant l'ingénierie. UX peut sprinter avec vous. Obtenez de nombreuses histoires technologiques ou corrigez la dette technologique dans le carnet de commandes. De cette façon, si le processus créatif et cyclique de l'UX est en retard ou nécessite plus de sprints, les développeurs peuvent vraiment être agiles. Au lieu d'attendre l'UX, ils peuvent passer à des fruits à portée de main que le produit ou l'ingénierie a priorisés.

Tenez également compte des ressources, de l'affectation et de la dotation en personnel. Selon la taille du projet, n'attribuez pas plus de 3 projets à un concepteur UX. Si vous avez des chercheurs UX experts distincts, qui effectuent également des tests et des analyses, affectez un chercheur à pas plus de 3 concepteurs UX. Si votre praticienne UX est ce qu'on appelle en forme de T, ce qui signifie qu'elle est également qualifiée et excellente dans la recherche, les tests et d'autres sous-spécialités UX, alors assurez-vous qu'elle n'est pas accidentellement un goulot d'étranglement en étant affectée à trop de projets.

Mesurer les résultats

Sans la satisfaction du client, vous pourriez ne pas avoir de clients. Vous pouvez utiliser des mesures de satisfaction client pour déterminer comment l'amélioration de vos processus en intégrant UX a apporté des changements positifs.

• Moins de plaintes
• Meilleures critiques d'applications
• Meilleures évaluations des applications
• Moins de tickets d'assistance
• Moins d'appels au centre d'appels
• Sémantique plus positive des messages sociaux
• Plus d'installations d'applications, moins de désinstallations
• Augmentation de l'AOV (valeur moyenne des commandes)
• Taux de conversion plus élevé

Vous pouvez également mesurer les objectifs DevOps souhaités, tels que le délai de mise sur le marché et le temps entre les correctifs. Combien de temps faut-il pour que les histoires, les projets et les épopées arrivent sur le marché avant et après votre révolution UX ? Les estimations de temps des développeurs sont susceptibles d'être plus précises lorsqu'ils ont finalisé les conceptions UX sur lesquelles baser leurs estimations par rapport au travail à partir d'histoires ou de tout ce que vous faites actuellement.

Si UX fournit des plans et que ceux-ci sont suivis, nous espérons que l'ingénierie aura moins de travail en réduisant les changements et les reconstructions surprises. Une meilleure conception UX plus tôt, moins de correctifs plus tard.

Agile UX est un investissement plus que rentable

De nombreux chefs de projet voient l'UX comme une ligne budgétaire qui peut être supprimée ou réduite, et les responsables du recrutement s'enthousiasment à l'idée de combiner des tâches UX avec un autre rôle. Cependant, de plus en plus d'entreprises apprennent que rien ne remplace l'investissement dans un processus UX approprié entrepris par des spécialistes UX formés et expérimentés.

Eric Ries, auteur de The Lean Startup , demande : « Et si nous nous retrouvions à construire quelque chose dont personne ne veut ? Dans ce cas, quelle importance si nous le faisions dans les délais et dans les limites du budget ? » Même si votre organisation n'utilise pas la méthodologie Lean, l'avertissement reste vrai. Les résultats souhaités par DevOps font écho à cela lorsque nous visons à créer la bonne chose pour le client, à améliorer la satisfaction client et à développer des fonctionnalités à forte valeur client.

Connaître votre client, l'impliquer dans le processus et répondre à ses véritables besoins et préférences est finalement plus important que les délais, les budgets, les cadres et les outils. Ayez confiance que si vous construisez les bonnes exécutions des bonnes idées, les revenus seront là.