Concevoir pour la cohérence des applications ou suivre la convention du système d'exploitation?
Lorsque nous concevons des applications à utiliser dans le nouveau monde du cross-channeling, nous devons prendre en compte de nombreux facteurs différents. Nous devons non seulement déterminer dans quel environnement l'application est utilisée. Les applications de bureau sont souvent utilisées dans un mode axé sur l'utilisateur, tandis que les applications mobiles sont utilisées en mouvement, dans des délais courts et éventuellement en effectuant des tâches dans un mode non cohérent.
En regardant à l'intérieur, il est facile de penser qu'une application de bureau et une application mobile doivent être cohérentes dans leur comportement et leur conception. Plus la conception est centrée sur l'application, plus il est facile pour l'utilisateur de trouver son chemin et d'effectuer des actions.
En regardant dehors, le contraire est vrai. L'utilisation d'une application de bureau sur les ordinateurs Apple, Windows et Linux doit suivre les conventions de chaque système d'exploitation. Il en va de même pour les appareils mobiles où une application Android est différente d'une application iOS, etc.
J'ai toujours enseigné à cette dernière méthode que suivre la convention du système d'exploitation est toujours correct (jeux exclus). Comme ce commentaire d'hier:
"... dans mon livre, Unified Design est centré sur les applications et brise les conventions sur les appareils. Au lieu de cela, la conception centrée sur l'utilisateur est la voie à suivre. Les utilisateurs connaissent leurs appareils, mais pas votre application. C'est pourquoi Snapchat est si difficile à apprendre."
L'afficher m'a fait réfléchir. Et si c'est faux? La cohérence des applications peut-elle être préférée à la convention du système d'exploitation?
Comme vous le feriez, je pencherais généralement pour la cohérence du système d'exploitation. Mais voici quelques questions qui peuvent éclairer les compromis.
À quelle fréquence vous attendez-vous à ce que les utilisateurs accèdent à l'application à partir de plusieurs plates-formes? Si vous constatez que vous avez des audiences distinctes utilisant la version mobile par rapport à la version de bureau, la cohérence entre ces versions est moins importante.
Dans quelle mesure les interactions avec votre application sont-elles spécialisées? Si cela implique principalement des actions standard du système d'exploitation comme remplir des formulaires ou sélectionner des éléments dans les menus, les utilisateurs bénéficieront davantage du respect des conventions du système d'exploitation. Si les actions qu'ils effectuent sont plus spécialisées pour votre application, le système d'exploitation fournira moins d'indices contextuels et ils seront plus susceptibles de tirer parti des connaissances d'autres interactions avec votre application.
Les utilisateurs utilisent-ils les versions de bureau et mobile pour les mêmes tâches? Si c'est le cas, il y a plus de cas pour la cohérence multiplateforme. Si les activités les plus courantes diffèrent entre les plates-formes, les utilisateurs sont moins susceptibles de remarquer ou de se soucier s'ils diffèrent.
Je pense qu'il y a une distinction à faire entre les conventions de conception visuelle de la plate-forme et ses conventions de conception d'interaction.
Prenant iOS 7+ comme exemple, les applications sont généralement composées en Helvetica Neue et principalement blanches avec relativement peu d'éléments de marque. Les boutons sont généralement sans bordure par défaut et utilisent la couleur par défaut de l'application comme indice que les éléments sont cliquables.
Mais je dirais qu'il existe des applications très bien conçues sur la plate-forme qui vont à l'encontre de chacune de ces conventions.
Cependant, les modèles de conception d'interaction établis ne devraient probablement pas être violés par une seule application. Cela signifie que vous devriez probablement éviter les menus hamburger sur iOS, ou rouler votre propre clavier ou sélecteur de date, ou changer les animations pour indiquer une hiérarchie de contenu différente.
Bien qu'il existe sans doute des applications qui ont réussi à implémenter un mécanisme d'interaction étrangère sur iOS (Google Maps en est un, tout comme YouTube), mais elles ont le luxe de fournir un accès exclusif à un type important de contenu en ligne; les utilisateurs sont à peu près obligés de contourner ce qu'ils obtiennent de Google. Ajoutez à cela le fait que Google a sa propre plate-forme mobile et son langage de conception assez matures, ils sont donc plus motivés que la plupart des concepteurs à violer la plate-forme cible pour renforcer leur façon de faire.
Nous avons des discussions similaires pour nos projets ces jours-ci (également il y a quelques années) et l'une des rares questions qui ont été soulevées était
1) Le même utilisateur qui a utilisé l'application sur une plate-forme (disons Windows) ne sera-t-il pas irrité/confus s'il ouvre la même application sur une autre plate-forme (disons Mac ou Android), car les tâches vont être similaires? Après tout, l'application Gmail devrait toujours ressembler à l'application Gmail sur toutes les plateformes (iPhone ou Android).
De plus, les conventions du système d'exploitation peuvent être modifiées/évoluer avec ses versions. Vaut-il la peine de passer des heures à faire ressembler la même application à celle de ce système d'exploitation sans vraiment ajouter d'autre valeur à l'application?
2) À moins que le système d'exploitation ne l'impose à ne pas faire vis-à-vis de la conception (et de l'apparence) de l'application qui devra être respectée et mise en œuvre pour obtenir la certification de l'application (comme Apple Store), pourquoi voudriez-vous même suivre les conventions du système d'exploitation? Votre application doit avoir sa propre identité, pas l'identité du système d'exploitation.
Un membre senior de notre équipe a en fait indiqué à l'équipe UX que l'application devrait PAS ressembler à une application iPhone ou à une application Android ou une application Windows.
Spécifique à l'interaction avec les appareils et compte tenu du point de vue des utilisateurs: ma préférence pour l'approche est "Quand à Rome (faites comme les Romains)".
Je préconise cette approche parce que les utilisateurs développent le confort en utilisant une plate-forme d'appareil spécifique et en suivant la convention d'interaction de la plate-forme d'appareil réduit la charge d'apprentissage. Les utilisateurs ne veulent pas avoir à apprendre le modèle d'interaction d'une autre plateforme pour utiliser l'application sur leur propre appareil.