Limiter la liberté de personnalisation des utilisateurs
Le contexte:
Je travaille actuellement à la refonte d'une application de présence des employés utilisée par diverses entreprises. À l'heure actuelle, les entreprises qui utilisent l'application peuvent définir leurs propres statuts de présence en fonction de leurs besoins.
Par exemple La société X a créé et utilise les statuts de présence: Présent, Tardif, Absent. Alors que la société Y utilise: Présent, Absent, Absent sans préavis.
Nous donnons aux entreprises clientes un contrôle total sur le nombre et les options de présence qu'elles souhaitent utiliser, de sorte qu'il diffère d'une entreprise à l'autre.
Maintenant, tout va bien et dandy jusqu'à ce que vous regardiez l'interface utilisateur (je ne suis pas obligé de vous montrer et cela n'a pas de pertinence de toute façon puisque la refonte est bien en cours), ce qui est un gâchis complet car vous devez le faire si de nombreuses options possibles et ralentit inutilement tout le flux de travail.
Modifier en raison d'un commentaire expliquant davantage le point douloureux: Cela devient un gâchis complet parce que tous les clients ont vraiment besoin, fondamentalement, de voir s'ils étaient présents, absents (avec préavis), absents sans préavis, ou en retard. Certains clients ont 13 statuts différents pour ce qui semble être juste pour le plaisir car ils le peuvent et les utilisateurs finaux qui le marquent finissent par être terriblement confus comme à quel statut vérifier car ils finissent par être assez similaires. Il encombre également inutilement l'interface utilisateur avec toutes ces options.
En tant que tel, ce que nous voulons faire, c'est ...
... standardiser les options de présence pour toutes les entreprises clientes afin d'éviter la situation actuelle de prise en charge de centaines de variations de statuts différentes qui ont essentiellement la même signification. Nous prévoyons de définir un nombre limité mais suffisant de statuts disponibles et de supprimer toute option permettant aux clients de créer leurs propres statuts.
Notre préoccupation est ...
... que nous ferions face à un tollé de la part des clients existants au sujet de la limitation et de la réduction du niveau actuel de personnalisation et de contrôle qu'ils ont sur le système et qu'ils cesseraient simplement d'utiliser le système même s'ils pouvaient terminer leur travail flux beaucoup plus facile et plus rapide sans rien manquer de critique.
La question qui se pose:
Est-ce que limiter la capacité de personnalisation des utilisateurs et les forcer à adopter des pratiques standardisées est un chemin dangereux à suivre et pourquoi?
Et dans une autre mesure, comment persuader les utilisateurs d'accepter de renoncer à la liberté de personnalisation?
Je m'occupe de cela en ce moment à une assez grande échelle (de grandes zones d'un ancien système complexe sont évaluées et mises à jour). À juste titre, j'ai également récemment assisté à un débat/panel Atlassian Design où ils ont dit (paraphrasé) ...
"Réfléchissez bien à chaque fonctionnalité que vous mettez dans vos applications, car une fois qu'elles sont entrées, elles sont très difficiles à retirer".
Réduction des fonctionnalités
Vous dites que l'interface utilisateur en ce moment est un "gâchis complet", ce qui est subjectif - mais ce qui n'est pas subjectif est:
- Chaque fonctionnalité supplémentaire dans une application nécessite un travail de construction/mise à jour et un effort de maintenance de votre équipe ou d'autres personnes.
- Chaque bit d'informations non essentielles porte atteinte à l'essentiel.
- Fournir une abondance de choix augmente la charge cognitive d'un utilisateur
À mon avis, si vous avez la possibilité de supprimer du contenu/des fonctionnalités de votre application qui ne fournissent pas de valeur, leur suppression peut être elle-même utile.
... [notre préoccupation est] qu'ils cesseraient tout simplement d'utiliser le système même s'ils pouvaient accomplir leur flux de travail beaucoup plus facilement et plus rapidement sans rien manquer de critique.
Je pense qu'ici, vous avez partiellement répondu à votre propre question, Nice!
La solution est en deux parties:
Mener des recherches pour confirmer votre hypothèse selon laquelle la consolidation prévue des options sera globalement avantageuse pour les utilisateurs. Personnellement, je préfère reformuler cela et demander "De quoi les utilisateurs ont-ils réellement besoin/quels sont leurs objectifs finaux?".
Communiquer les modifications et s'assurer que la mise à jour est adoptée aussi facilement que possible.
Recherche - Les fonctionnalités offrent-elles de la valeur?
Idéalement, la première étape consiste à rechercher comment les utilisateurs utilisent actuellement l'application et comment ils utilisent les options disponibles.
- L'observation directe serait difficile étant donné que les personnes changent de statut sur une longue période (par exemple au cours d'une journée), mais vous pouvez avoir accès à une sorte de données analytiques ou de données de votre base de données (statuts actuels des personnes). Déterminez ceux qui sont utilisés fréquemment et rarement.
- Warren avait une bonne suggestion de procéder à un tri des cartes. Élaborer comment cela pourrait être fait ...
- Vous prendrez toutes les options actuellement disponibles et les noterez sur des cartes individuelles.
- Obtenez de vrais utilisateurs, dans des sessions individuelles, pour classer les cartes en groupes logiquement similaires.
- Demandez-leur de nommer les nouveaux groupes qu'ils ont créés.
- Il y a deux avantages à cela - le résultat final (le nouveau sous-ensemble plus petit d'options basé sur votre analyse de la façon dont les utilisateurs ont regroupé les cartes) et la conversation que vous pouvez avoir avec les utilisateurs lorsqu'ils effectuent la tâche (n'oubliez pas de leur demander ce qu'ils sont). en réfléchissant s'ils hésitent, et après avoir discuté avec eux de la façon dont ils utilisent l'application actuellement et explorent ce qu'ils essaient finalement de réaliser lorsqu'ils changent de statut).
Communication - Des changements arrivent
Si vous avez confirmé que les utilisateurs n'obtiennent pas de valeur des autres options, il vous suffit de leur communiquer les modifications.
- Envoyez des communications à l'avance indiquant que "les mises à jour arrivent ..." détaillant les changements, donc ce ne sera pas un choc lorsque l'interface utilisateur changera pour eux un jour.
- Puisqu'il s'agit d'un changement positif, faites-le tourner comme un exemple "Nous simplifions la façon dont vous ... Cela devrait vous faciliter la tâche ..."
- Si l'interface utilisateur de la fonctionnalité change un peu, envisagez d'ajouter une intégration simple expliquant le changement et la nouvelle façon dont il fonctionne. Cela ne doit être vu que par les utilisateurs qui existaient avant le changement, et non par les nouveaux utilisateurs.
Vous dites que cela fait également partie d'une mise à jour plus large, et que cela devrait donc apporter des avantages aux utilisateurs dans d'autres domaines, éclipsant probablement tout changement unique, car il s'agissait d'un changement éclairé basé sur les résultats de la recherche des utilisateurs.
Ma pensée est la suivante: si vous le limitez, vous affronterez le tollé des clients existants. Souvenons-nous qu'ils ont créé ces statuts pour les adapter à leurs besoins. En outre, il existe certaines données du passé dont ils auraient besoin pour être au moins comparables aux données futures. Et enfin, les gens se sont habitués à les utiliser après tout.
D'un autre côté, donner aux gens trop de liberté pour personnaliser les données peut en effet entraîner des dégâts dans certains cas, d'autant plus qu'il est sujet à des idées fausses sur la façon d'organiser les informations qu'ils saisissent.
Ayant cela à l'esprit, je rechercherais une solution dans décalage des statuts actuels à un niveau inférieur, ce qui en ferait des informations plus détaillées sur les nouveaux statuts que vous créez. Bien que ce soit encore une idée et doit être comparé aux données réelles qui sont là (à savoir: les statuts que certains de vos clients ont créés), cela pourrait être:
Nouveau statut normalisé 1
- sous-statut 1.1. (un statut existant qui répond aux critères du statut 1 = plus d'explications)
- sous-statut 1.2
Etc.
Dans le même temps, j'autoriserais les utilisateurs à sélectionner uniquement les statuts de niveau supérieur, sans avoir besoin de choisir les statuts inférieurs.
Dans votre cas, les statuts de niveau supérieur seraient probablement: les présences, les absences avec préavis, les absences sans préavis, le retard. Ensuite, par exemple, si une entreprise, par exemple permet de travailler à partir du bureau ou à distance ou les gens peuvent être en voyage d'affaires (mais toujours au travail ), cela pourrait être la ventilation supplémentaire du "Présent" état supérieur - et cela donne de la place pour bien le représenter sur un graphique en utilisant diverses nuances de vert par exemple.
Mais je commencerais par analyser en profondeur comment vos utilisateurs personnalisent les statuts et leur demander pourquoi, puis tester tout concept que vous proposez avec eux.
C'est une question fondamentale qui touche tous les aspects du design: flexibilité vs rigidité, liberté vs ordre. En tant que concepteurs, nous voulons plaire aux utilisateurs et leur donner les outils dont ils ont besoin et veulent. Cependant, être trop libéral et faire des compromis peut aboutir à une "conception de comité", qui à son tour se traduit par un produit très médiocre au final.
Les utilisateurs sont de tailles et de formes différentes: certains utilisent principalement le clavier et d'autres le font avec la souris, mais au final, ils ont tous mieux à faire que d'ajouter des options inutiles.
Dans votre cas, je donnerais les meilleures pratiques pour la participation que vous avez proposées (3-5 options), et cacherais la fonctionnalité "ajouter un statut" quelque part dans les paramètres généraux, ce qui rendrait plus difficile pour les utilisateurs de l'atteindre et les décourageant ainsi d'ajouter un statut inutile. Vos clients existants ne détesteront pas le changement, tandis que les nouveaux utilisateurs n'atteindront probablement jamais cette fonctionnalité épouvantable et resteront avec les valeurs par défaut, et nous savons tous combien les utilisateurs ont tendance à modifier les valeurs par défaut: P
Je pense que votre premier objectif doit être de limiter les options affichées dans l'interface utilisateur, pas celles disponibles dans les paramètres. Si vous affichez chaque statut de fréquentation de la personnalisation de chaque client, pas étonnant que les choses soient devenues un gâchis. Dans ce cas, la personnalisation n'est pas la cause principale du désordre, d'autres facteurs le sont. Maintenant, si un client décide qu'il souhaite 30 options de présence différentes avec des noms similaires à afficher à l'écran, il a besoin d'une conversation distincte.
Si pour une autre raison non mentionnée, vous devez limiter les choix, vous pouvez réunir un conseil de clients (peut être un sous-ensemble soigneusement choisi si vous avez trop de clients), leur expliquer le problème et leur demander quelles options seraient acceptables (en choisissant les options personnalisées les plus courantes et en les limitant, en n'autorisant qu'un seul statut personnalisé par organisation, etc.).
Je suppose que vous avez effectué les recherches de taxonomie nécessaires avec les utilisateurs/clients (via les tris de cartes, etc.) pour identifier les valeurs de statut de fréquentation les plus courantes. Il serait essentiel d'inclure les utilisateurs dans ce processus et/ou de communiquer à l'avance pourquoi vous effectuez le changement.
Cela ressemble en fait plus à une question de direction commerciale/produit qu'à une question strictement UX. Il existe des "dangers" inhérents à tout changement au sein d'un produit, en particulier en ce qui concerne le choix de l'utilisateur. La question est de savoir si votre organisation est prête à accepter le risque d'utilisateurs mécontents (et potentiellement partants) par rapport au contrôle de la vision du produit.
Si le produit est considéré comme précieux par les utilisateurs, le "coût" pour eux de tout changement serait probablement compensé par la valeur globale du produit.
Quel que soit le cas spécifique que vous avez mentionné, il s'agit d'une question courante et, à mon avis, très importante dans le monde du développement de logiciels et de produits: où est le véritable seuil pour arrêter d'appliquer aveuglément les demandes des utilisateurs et commencer à construire ce que vous pensez être vrai et mieux que les utilisateurs veulent?. Je traite ce problème depuis plusieurs années et je partage mon opinion et ma conclusion: il y a généralement trois groupes de peuples avec trois mentalités différentes:
- Des gens qui pensent que l'utilisateur est un dieu, et l'utilisateur est l'indicateur de nos travaux, de notre vision et seul l'utilisateur sait ce qu'il veut. La satisfaction immédiate de l'utilisateur est plus importante que tout autre aspect du travail. Cet état d'esprit est proche de l'état d'esprit de l'homme d'affaires. Des gens qui se concentrent sur aujourd'hui et ne pensent pas à construire des lendemains.
- Les gens qui ne se soucient pas de l'opinion des utilisateurs et essaient de résoudre les problèmes en tenant compte philosophiquement du problème et essaient de dicter et de publier leurs pensées en tant que rôles divins. Cet état d'esprit est proche des théoriciens et je suis le plus fin.
- À côté de ces deux groupes, il y a un autre groupe de personnes qui croient que les utilisateurs ne savent pas exactement ce qu'ils veulent. Les utilisateurs agissent en fonction de leurs expériences antérieures et peuvent rarement penser à ce qui pourrait être à l'avenir. Cet état d'esprit dit que vous devriez considérer le problème philosophiquement et tenir compte des besoins et des désirs des utilisateurs et enfin offrir une solution philosophiquement vraie et pourtant acceptable pour les utilisateurs. Cet état d'esprit appartient aux designers.
Vous devez agir comme un designer. Contrairement aux spécialistes comme les développeurs, les concepteurs ne se concentrent pas sur un aspect mais ont vu de nombreux aspects d'un problème et les combinent pour obtenir le meilleur résultat possible.
En cas de problème, si vous essayez de satisfaire tous les utilisateurs, vous rencontrez à coup sûr d'autres problèmes et finissez par vous retrouver avec des utilisateurs insatisfaits. vous devez considérer philosophiquement le problème de la présence des employés et essayer de regrouper tous les types de cas possibles, puis prendre en compte la culture de votre entreprise et extraire les cas critiques. Maintenant, en fonction des informations acquises, vous devez décider de choisir la stratégie et le seuil de liberté de l'utilisateur. c'est un processus interactif et qui fait perdre du temps. mais ça a coûté.