UI / UX dans un environnement de développement agile
Je travaille avec une entreprise sur une application Web de moyenne à grande échelle. L'application consiste à remplacer les applications existantes, les processus manuels et électroniques. Ce projet est dans un délai serré, et se développe dans un environnement agile.
Une autre chose à noter à propos de cette application, c'est que l'industrie/l'entreprise pour laquelle elle est construite est très nouvelle pour moi, et il y a relativement peu de modules/applications que je connais. Je veux dire par là, je sais qu'il y aura une section des finances et une section de suivi des employés, et j'ai une assez bonne idée de ce à quoi s'attendre pour ces exigences. Cependant, il existe également de nombreuses sections/modules liés au catalogage génétique, aux tests ADN et aux grands enregistrements/processus d'application avec une logique métier abondante.
Ma question est de savoir comment, en tant que concepteur UI/UX, on prévoit de créer une application de cette taille/complexité alors qu'ils ne connaissent pas la majorité des applications/processus. Au fur et à mesure que je termine les modules, ils sont transmis aux développeurs, et je continue de causer des problèmes lorsqu'un nouveau module arrive, et je dois changer le cadre/la conception existante pour les adapter.
Comment puis-je éviter ça? Aucune suggestion? Quelles sont les meilleures pratiques?
Premièrement, vous ne causez aucun problème, vous faites de votre mieux avec ce que vous avez et demander de l'aide montre que vous avez la tête bonne sur les épaules. Je ne vais donc pas recouvrir mes réponses sinon je ne pense pas que je vous rendrais justice.
Tout d'abord, jetez le terme agile. J'ai été dans l'environnement dans lequel vous vous trouvez et ils l'appellent agile parce qu'ils ne savent pas mieux. Agile ne signifie pas voler par le siège de votre pantalon et espérer le meilleur. Agile signifie, faire ce qui est la meilleure utilisation de votre temps en fonction de l'endroit où vous êtes dans le projet.
Deuxièmement, vous vous dirigez vers une épave de train. Ma suggestion serait de tirer le frein d'urgence maintenant. Vous pouvez craindre d'avoir des ennuis, mais ne le faites pas. Soyez juste cool et tout ira bien. Posez des questions et obtenez des réponses claires. Continuez à demander jusqu'à ce que vous soyez satisfait des réponses, mais soyez cool. Copiez tout le personnel concerné sur vos e-mails, mais soyez cool.
Si vous ne voyez pas la lumière au bout du tunnel, quelque chose ne va pas. La seule façon dont un environnement agile fonctionne est que tout le monde soit sur la même longueur d'onde avec des buts et des objectifs clairement définis. Vous devez avoir un plan de match général en place afin de savoir comment traiter chaque pièce et comment elle s'intègre dans un cadre global. Aucune pièce ne devrait être un mystère.
OK, donc si rien de tout cela ne fonctionne pour vous, voici ce que vous faites. Regardez vers l'avenir, prévoyez des heures supplémentaires et élaborez votre propre plan de match. Honnêtement, même si le train s'arrête, regardez en avant et trouvez le meilleur chemin. Faites votre propre recherche UX et trouvez un ensemble d'interactions qui peuvent être utilisées pour le reste du projet dans son ensemble. Réutilisez autant d'éléments que possible sans sacrifier l'intégrité du site.
Voici un lien pour vous aider à démarrer.
Vous devrez simplifier pour passer.
Bonne chance à vous. Si vous en avez l'occasion, laissez un commentaire, j'aimerais savoir comment cela se passe.
Sur Agile
Parmi les différents concepts liés à Agile, je voudrais en souligner deux:
- Il s'agissait de lutter contre la volatilité des exigences (évolution ou modification fréquente des exigences ou de leur priorité).
- Il augmente le temps de mise sur le marché .
Agile, lorsqu'il est utilisé dans le bon contexte (et suivi par la Parole), n'est rien de moins que de la magie. Le coût des changements au sein d'un projet Agile correctement géré peut être considérablement inférieur par rapport au paradigme de la cascade.
Mais Agile n'est pas une solution fourre-tout (qu'est-ce que c'est?), Et malheureusement, il est souvent considéré comme une solution miracle qui fonctionnera toujours. La réalité est loin de là.
Sur l'ingénierie des exigences
On sait depuis des années que plus tôt une exigence est prise en compte dans le processus de production (exigences, analyse, conception, codage, tests unitaires, déploiement), moins elle sera coûteuse à réaliser - les changements sont bon marché au début de la processus, très cher à la fin.
C'est quelque chose que tous les concepteurs de logiciels/UX témoigneront - plus vous connaîtrez les exigences avant le processus de conception, plus la conception sera solide.
Il semble y avoir une contradiction ici - d'une part, Agile prêche de courtes itérations de portée très limitée (y compris les exigences prises en compte); de l'autre, plus vous tenez compte des exigences, meilleures sont les conceptions.
Les 3 stratégies de conception
Il existe essentiellement 3 approches de conception (UX ou logiciel):
- Jetable (révolutionnaire)
- Lorsque vous avez peu de compréhension du problème et des exigences (niveau élevé d'incertitude)
- Vous concevez rapidement, testez rapidement et surtout pour apprendre ce qui fonctionne et ce qui ne fonctionne pas.
- Normalement, c'est un processus ultra-rapide, mais les conceptions sont susceptibles d'être rejetées (ce qui entraînera une refonte ou une refonte).
- Évolutionnaire
- Lorsque vous avez une certaine compréhension du problème/des exigences, mais qu'il est incomplet et susceptible de changer.
- Vous construisez la conception étape par étape, en tenant compte des nouvelles connaissances à chaque itération.
- Les conceptions servent généralement de base pour la prochaine itération.
- À chaque itération, la conception précédente nécessite souvent des révisions - parfois dramatiques.
- Le danger est que de mauvaises conceptions puissent persister.
- Incrémentiel
- Lorsque vous avez une compréhension claire du problème et des exigences.
- Vous concevez pour répondre à toutes les exigences.
- Ce processus peut être long.
Quand l'Agile est génial
Agile est idéal pour un projet où vous ne comprenez pas ou peu le domaine problématique. Pour un projet complètement innovant, la stratégie du jetable est souvent utilisée; cependant, la plupart des projets Agile utilisent une conception évolutive. Une conception incrémentielle est généralement anti-Agile.
Ce qui est important à mentionner, c'est que l'utilisation d'Agile doit s'accompagner de la prise de conscience que votre conception actuelle peut ne pas répondre aux exigences futures. C'est pour cela que vous avez signé en choisissant Agile! C'est pourquoi le code refactoring est absolument vital au succès d'un projet Agile. En termes Agiles, vous livrez sciemment juste assez ; rien de plus. Cela fonctionnera pour l'instant, dans la future révision sont probables.
Quand Agile est un désastre
Lorsque vous avez une compréhension claire du problème et des exigences du domaine. Vous généreriez beaucoup de déchets et retravailleriez en ne tenant pas compte de ceux-ci dès le début et en ne prenant pas la conception incrémentielle plus longue et non agile.
Un certain nombre d'entreprises ont une compréhension claire du problème - le système existe et est utilisé depuis un certain temps, avec toutes les fonctionnalités, mais la convivialité est faible. Il sera donc assez douteux de demander aux concepteurs d'ignorer les preuves, juste pour que le travail puisse s'inscrire dans un sprint de 2 semaines.
Suggestions
Pour commencer, il se peut que vos pairs essaient de manger le gâteau et de le laisser entier - on ne peut pas vous demander de produire des conceptions optimales à moins que vous ayez le temps d'examiner toutes les exigences. Le concept de juste-assez-maintenant-itérer-plus tard est la clé d'Agile.
Ensuite, vous pouvez évidemment essayer de regarder plus latéralement d'autres parties du système afin au moins d'avoir une idée de ce qui vous attend.
Mais dans l'ensemble, je suis désolé, mais je ne pense pas qu'il soit juste de demander à quelqu'un de faire une conception itérative qui, par définition, ne tient pas compte de toutes les exigences, puis de se plaindre que la conception doit être modifiée car elle ne tient pas compte de toutes les exigences .
Je pense que l'industrie a atteint un point où la conception UI/UX doit être faite d'une manière à la fois holistique et systématique. J'entends par là que les entreprises qui cherchent à développer de nouveaux produits et services dans le canal numérique doivent investir du temps et des efforts dans un cadre de conception ou une structure similaire qui vous permet de combiner les conceptions visuelles, de contenu et d'interaction afin qu'elles soient cohérentes et alignées à la marque de l'entreprise.
Pour en voir quelques exemples, consultez la page Google Material Design ainsi que les Atlassian Design Guidelines . Il fournit à la fois l'approche de conception de haut niveau ainsi que les composants et les règles de l'interface utilisateur de bas niveau pour aider les personnes à développer des applications en utilisant leur style et leurs modèles. Contrairement au Apple et au guide de style Windows, ces documents sont à la fois vivants et également plus interactifs afin de capturer tous les éléments essentiels de la conception en un seul endroit.
Si vous pouvez accéder à des personnes, je passerais un après-midi à discuter avec les utilisateurs pour comprendre ce que le système est censé faire.
Les utilisateurs ne sont pas seulement (à défaut d'un meilleur terme) l'utilisateur final du système. De nombreux autres utilisateurs sont impliqués: les développeurs, les entreprises et les utilisateurs finaux.
Parlez aux utilisateurs finaux du produit existant, découvrez leurs points faibles, leurs besoins et leurs objectifs. Utilisez ces informations comme levier. Le prototypage peut aider à vérifier rapidement les idées en dehors du cycle de développement. Prouvez votre hypothèse de conception sans impact sur le développement.
Parlez aux développeurs, comprenez les limites techniques. La technologie, en particulier dans une entreprise, comporte de nombreuses contraintes et généralement des méthodes spécifiques pour résoudre les problèmes.
Parlez aux prospects. Découvrez leur vision de l'avenir. Découvrez pourquoi ils veulent la refonte - la vraie raison, pas seulement un jargon philanthropique. Essayez de voir leur image de réussite.
Prenez ces choses et hiérarchisez vos batailles. Essayez d'obtenir l'adhésion des trois groupes, puis convenez de la meilleure façon de communiquer cela (protos interactifs, tableau blanc, croquis, wireframes, spécifications, etc.). Utilisez la méthode qui vous convient dans votre environnement.
Dès que vous remportez quelques victoires, vous serez étonné de voir comment l'atmosphère change en votre faveur - et, en fin de compte, en faveur de vos utilisateurs.
Bonne chance, continuez! K.