Réduction + divulgation progressive pour améliorer l'expérience utilisateur
Il y a eu beaucoup de discussions sur la pratique de la divulgation progressive pour réduire la complexité pour les utilisateurs en termes de contenu et d'interactions. D'autre part, la réduction progressive est également devenue populaire avec la tendance à la simplification des conceptions d'interface utilisateur. Je me demandais si les deux approches ont été combinées de manière sensible pour améliorer l'expérience utilisateur non seulement pour le contenu (car c'est là que la plupart des messages et des exemples se sont concentrés), mais aussi pour l'interaction avec l'utilisateur. Par exemple, si j'effectue généralement des clics pour effectuer une action, l'application peut plutôt créer un raccourci pour moi. Ou si une option de menu particulière n'a pas été utilisée, elle se déplace plus bas dans la liste. L'idée d'essayer de créer une application unique pour tous semble créer des maux de tête pour les concepteurs UX, alors pourquoi ne pas adopter l'approche inverse d'adapter les fonctionnalités de l'application en fonction des informations d'utilisation?
Cela ne veut pas dire que l'application entière doit être entièrement adaptative, car alors vous perdez les principes de conception de base. Mais dans les domaines où il y a des débats sans fin sur la façon dont les gens pensent que les utilisateurs utiliseraient quelque chose qui, même après les tests, ne fournit pas de réponse définitive, je pense qu'une combinaison des deux approches résoudrait le problème d'avoir à faire un compromis ou à concevoir uniquement pour un groupe d'utilisateurs. Existe-t-il de bons exemples où les deux approches sont utilisées pour équilibrer la complexité des préférences/comportements des utilisateurs?
Eh bien, n'importe quel menu standard est un exemple classique de divulgation progressive, où vous voyez d'abord juste le titre "Fichier" et ensuite vous voyez les options qu'il contient. "Progressive Reduction" est apparemment un nouveau nom pour ce qu'on appelait auparavant "Adaptive UI" ou simplement "Personalization". L'exemple classique ici est MS Office 2003, où ils ont fait exactement ce que vous avez décrit - si un élément de menu n'était pas utilisé, il se déplacerait vers le bas de la liste. AFAIK, cette approche a misérablement échoué, les utilisateurs n'ont jamais pu prédire où une option spécifique rarement utilisée sera située dans le menu, et aussi pourquoi leurs options souvent utilisées ont tendance à se déplacer. MS a abandonné l'idée dans Office 2007, apparemment, ils sont arrivés à la même conclusion.
La réduction progressive ne sonne pas comme si elle jouait bien avec la mémoire musculaire et pour cette raison je l'éviterais.
D'autres méthodes pour gérer la complexité consistent à utiliser une interface en "langage naturel", en tapant ou en disant des commandes au lieu d'avoir un mot ou une icône spécifique lié à une action, vous pouvez ensuite associer plusieurs mots à une action. Contrairement à une ancienne interface de ligne de commande, il ne s'agit pas de savoir comment rédiger une action d'une manière que l'ordinateur comprend, mais d'exprimer une action et de vous faire comprendre par l'ordinateur ou peut-être d'inviter en cas de doute. Attendez-vous à voir cette zone se développer comme Apple siri, MS Cortana et des initiatives telles que ibm watson se développer.
Une méthode que nous utilisons au travail pour un programme compliqué consiste à configurer une série de types d'utilisateurs par défaut. Tout comme les espaces de travail des produits Adobe, il réduit un ensemble plus large de contrôles à ceux utilisés uniquement pour une tâche ou un rôle particulier. Ceux-ci peuvent ensuite être personnalisés davantage si la valeur par défaut ne correspond pas à vos besoins spécifiques. Des éléments supplémentaires peuvent être trouvés via une recherche et épinglés, ou en utilisant une page maître de toutes les commandes.