Pouvons-nous intégrer l'UX dans d'anciens grands systèmes hérités?
Pour les grandes applications d'entreprise, nous n'avons pas tendance à avoir le luxe de refondre l'interface utilisateur après avoir évalué l'UX du processus pris en charge par ces applications. Cependant, ce n'est pas parce que l'UX a été appliqué à l'application dans le passé que nous ne devrions pas le faire maintenant pour les nouvelles fonctionnalités que l'entreprise demande.
Je détesterais suivre ce qu'ils ont fait dans le passé juste pour des raisons de cohérence, mais en même temps, la cohérence UX est importante - nous ne voudrions pas que les anciens écrans continuent d'être maladroits et gris, mais les nouveaux écrans rationalisés et bleus.
Dans ces circonstances `` héritées '', est-ce le seul moyen d'appliquer l'UX à votre nouvelle fonctionnalité pour se concentrer sur la conception d'informations et d'interactions mais conserver la conception visuelle actuelle - peu importe à quel point elle est moche ou peu conviviale?
J'ai quelques conseils pour vous, après avoir fait cela dans le passé:
- saisir la complexité de la logique métier et UX de la page AVANT de commencer à travailler
- pensez à l'entretien avant de commencer votre processus de conception
- considérer le niveau de flexibilité et d'adaptation de l'UX dans ce système hérité
- introduire UX en tant que nouvelle couche et garder votre couche d'interaction héritée actuelle séparée (si possible)
- intégrez votre changement de manière itérative.
Vous pouvez fouiller Internet pour obtenir des informations. Des entreprises comme Paypal , Google , Uber et dropbox l'ont déjà fait.
Je suis d'accord avec Rayraegah que vous devez penser de manière itérative avec les projets hérités. Je dirige l'UX et la conception d'une refonte de l'héritage similaire.
Notre produit a deux luxes que vous ne pouvez pas: 1. Une suite de divers produits qui ne dépendent pas les uns des autres (les utilisateurs peuvent utiliser un ou une poignée des 20 disponibles, mais pas tous) et 2. une utilisation peu fréquente par utilisateur (1 à 5 fois par an).
Notre produit présente également certains inconvénients, que je suis sûr que le vôtre partage: 1. Syndrome de Frankenstein gigantesque (interface utilisateur produite en morceaux si nécessaire sur 10 ans, avec très peu de souci de cohérence); 2. Les utilisateurs techniquement non avertis qui rencontreront le changement avec confusion, même s'il est "plus utilisable";
Compte tenu de ces luxes et inconvénients, la façon dont nous procédons aux changements est une danse entre des révisions audacieuses et un compromis banal.
Nous avons utilisé un produit complètement nouveau comme terrain d'essai pour une interface utilisateur visuelle très différente. Il s'agissait de la catégorie "révision en gras". Cependant, puisque le nouveau look n'était lié qu'à un tout nouveau produit, il n'y avait pas de changement massif pour nos utilisateurs. Le plan est que ce nouveau design visuel soit appliqué à tous les produits à mesure qu'ils sont repensés. Ce type de "produit pilote" est également un moyen sûr de présenter de nouveaux choix d'interface utilisateur aux dirigeants internes. Faire quelque chose comme ça nécessite de construire des alliances internes, de sorte que lorsque les dirigeants voient quelque chose de très différent, tous les responsables du projet se soutiennent mutuellement.
Dans un petit projet, j'ai amélioré l'interface utilisateur en utilisant les anciennes contraintes d'interface utilisateur. C'est dans la catégorie "compromis sans particularité". Quelle que soit la laideur de l'interface utilisateur, un nouveau style visuel ne serait pas à sa place. Ce genre de projets que je considère comme un défi de conception amusant (les contraintes sont amusantes!) - pour voir combien je peux changer tout en restant dans les limites de ce qui sera autorisé.
Chaque projet devant être repensé doit être évalué quelque part entre ces deux, et la création d'un consensus sur le changement avec toutes les personnes impliquées est une bonne idée.