Éviter les mauvaises pratiques dans la conception iOS et Android

Combien de personnes moyennes avez-vous vues utiliser à la fois des appareils iOS et Android ? Les chiffres officiels selon cette étude varient entre 10% et 20%, mais le chiffre inclut également les utilisateurs de Mac, pas seulement les utilisateurs mobiles. En pratique, les gens ont tendance à n'utiliser qu'un seul téléphone ou une seule tablette sur une période donnée. S'ils utilisent deux appareils, le plus souvent, les deux exécuteront le même système d'exploitation.

Cela signifie qu'il n'est pas nécessaire de faire des copies au pixel près de la conception de l'interface utilisateur d'une application, en essayant de s'adapter aux deux plates-formes, avec des dizaines de tailles d'écran, de rapports d'aspect et de résolutions différents (n'évoquons même pas les encoches, les barres d'état , barres de navigation, boutons matériels, etc.).

Au contraire, même si un utilisateur regarde la même application sur iOS et Android, il y a de fortes chances qu'il préfère ressentir le sentiment natif sur les deux. C'est pourquoi l'approche adoptée par de nombreux chefs de projet et propriétaires de produits dans le développement mobile est souvent sous-optimale et doit être affinée.

Pourquoi est-ce toujours un problème ?

Mais pourquoi les parties prenantes et les responsables prennent-ils encore des décisions qui dégradent fréquemment l'expérience utilisateur, compromettant ainsi leurs propres produits ? C'était compréhensible au début de la décennie alors que tout le monde se familiarisait encore avec le développement d'iOS et d'Android, mais ce problème ennuyeux persiste à ce jour.

La principale raison de cette situation pourrait être la crainte exprimée par les chefs de projet et les développeurs mobiles que leurs utilisateurs puissent être confus s'ils voient la même application sur une autre plate-forme et se rendent compte qu'elle ne fournit pas exactement la même sensation et la même interface utilisateur. Il est juste de dire que dans une certaine mesure, cette ligne de pensée a du sens, car un certain degré de similitude est nécessaire et bienvenu. Cependant, aller trop loin et, dans les cas extrêmes, créer des clones exacts d'applications pour différentes plates-formes a en fait tendance à faire beaucoup plus de mal que de bien.

L'objectif ultime devrait être de trouver le bon équilibre : ne forcez pas la cohérence au pixel près, mais respectez les idées de conception communes et gardez la carte de navigation de votre application similaire pour les deux plates-formes ; fournissez les mêmes fonctionnalités et le même flux de travail, mais essayez de vous en tenir au comportement natif dans la mesure du possible.

Tout le monde aime un bouton personnalisé ou une animation fantaisiste ici et là, mais les éléments natifs sont ce à quoi les gens sont habitués et qu'ils trouvent plus faciles et plus intuitifs à utiliser.

Concentrez-vous sur les utilisateurs, pas sur l'apparence

Afin de trouver une bonne approche pour résoudre ce dilemme, nous devons commencer par la fin de la ligne - l'utilisateur final. La recherche nous indique que les utilisateurs d'Android et d'iPhone sont des personnes très différentes et si nous visons une UX optimale, nous devrions essayer d'entrer dans leurs habitudes d'utilisation.

En partant du budget moyen que les gens décident de dépenser en technologie par mois ( iPhone : 100,88 $, Android : 50,83 $ ) , en passant par le nombre de selfies qu'ils font par jour iPhone : 12, Android : 7 et en passant par les SMS qu'ils envoient tous les jours iPhone : 57, Android : 26 , il est facile de constater que les différences sont substantielles, au point que nous pouvons conclure qu'il existe une divergence dans le comportement, qui détermine la façon dont les gens utilisent leurs appareils.

Alors, sur quoi devrions-nous nous concentrer lors de la conception d'applications pour les deux plates-formes en même temps ?

Tout d'abord, optez pour des éléments natifs dans la mesure du possible. Même si vous utilisez un framework multiplateforme, la plupart des composants sont basés sur des vues natives pures ; Donc, à moins que vous n'ayez vraiment besoin de quelque chose de personnalisé, respectez les bases. Les gens aiment utiliser ce à quoi ils sont habitués et vous gagnerez du temps de développement pour des fonctionnalités plus importantes (et des révisions de code !).

Les vues personnalisées peuvent certainement apporter du caractère et de l'unicité à votre application, tant qu'elles conservent les mêmes idées générales et la même utilisation que les génériques - trop peu et votre application est ennuyeuse, trop et inutilement flashy et difficile à utiliser.

Parfois, même une petite touche avec une vue personnalisée légèrement différente peut changer la donne pour votre application, mais si vous remplissez tous les écrans avec de nouveaux éléments à explorer pour les utilisateurs, ils peuvent être submergés et se perdre en recherchant des informations importantes. Ce n'est pas un hasard si ces petites touches s'appellent "polonais !"

Comment aborder différents composants de conception

En règle générale, rappelez-vous toujours que chaque plate-forme a ses propres directives de conception. L'ensemble d'approches d'Android s'appuie sur la conception matérielle, tandis qu'Apple fait confiance à la conception d'interface humaine. En ce qui concerne les composants spécifiques que nous devons prendre en compte lors de la planification de notre conception, nous devons nous concentrer sur plusieurs éléments principaux :

1. Style général : à moins que nous ne parlions d'une application multiplateforme, nous devrions envisager de suivre les directives générales de style pour chaque plate-forme. Dans l'ensemble, les conceptions iOS ont tendance à être plus plates, tandis qu'Android opte pour une approche plus en couches.

   Historiquement parlant, les plates-formes mobiles s'influencent mutuellement depuis une décennie ou plus, et vous pouvez facilement repérer certains concepts Android dans iOS et vice-versa. Par exemple, lorsque les capteurs d'empreintes digitales ont commencé à apparaître dans le monde mobile, les fabricants expérimentaient ( et continuent d'expérimenter) la taille et l'emplacement du capteur, en essayant de le rendre confortable pour le plus grand nombre d'utilisateurs possible. Dans le même temps, les concepteurs et les développeurs s'adaptaient également à la nouvelle fonctionnalité, de sorte qu'au final, les éléments visuels et les commentaires sont pour la plupart identiques sur les deux plates-formes (à l'exception de certaines approches exotiques).

2. Spécificités matérielles et modèles de navigation : il s'agit probablement de l'un des exemples les plus frappants des inconvénients du clonage pur et simple de votre application. La plupart des appareils Android ont toujours le confort d'une barre de navigation supplémentaire (qu'elle soit matérielle ou logicielle sur différents appareils), y compris un bouton de retour. Étant donné qu'iOS ne fournit pas cela, les applications doivent déterminer où et quand fournir le bouton de retour, généralement dans le coin supérieur gauche de chaque écran.

   Le bouton de menu (le bouton carré dans cet exemple) peut également fournir des fonctionnalités supplémentaires pour les applications Android. Où est-ce pertinent? Par exemple, lors de l'ouverture du menu des paramètres ou d'une fonction de navigation similaire.

   

   Jusqu'à récemment, les iPhones comportaient également le bouton d'accueil traditionnel d'Apple, mais depuis l'introduction de l'iPhone X, il a été mis de côté et le flux dans iOS est désormais basé sur des gestes. Si le balayage est une partie importante de votre application, assurez-vous de laisser suffisamment de coussin entre le bord du conteneur de l'application et la zone de balayage que vous autorisez pour éviter les coïncidences de balayage délicates.

   Si votre application s'appuie sur des fonctionnalités spécifiques au matériel telles que Bluetooth, NFC ou des écouteurs filaires, vous devez toujours tenir compte de la gamme de spécifications matérielles différentes que vous prenez en charge. Essayez de fournir des commentaires appropriés à l'utilisateur lorsqu'il essaie d'interagir avec une fonctionnalité spécifique. Si, pour une raison quelconque, vous devez fournir une fonctionnalité spécifique au matériel pour une seule des deux plates-formes, assurez-vous d'informer vos utilisateurs de la différence.

3. Éléments globaux (barres d'état, en-têtes, etc.) : les composants qui apparaissent sur toutes les pages de votre conception, comme la barre d'état, l'en-tête de navigation, etc., doivent viser strictement à offrir une sensation native, nous ne devrions donc pas changer la hauteur et le style de ces barres. Il existe des différences mineures dans la façon dont les éléments globaux sont stylisés sur les deux plates-formes. Par exemple, Android utilise du texte aligné à gauche tandis qu'iOS opte pour un titre centré. La barre d'état est un composant natif, vous n'avez donc pas à vous en soucier, mais gardez à l'esprit les différentes encoches et proportions d'écran lors de la planification de la section supérieure de votre application.

   

   

4. Navigation : les bonnes vieilles directives de conception de matériaux de Google suggèrent d'opter pour la navigation dans les menus des tiroirs dans les applications Android, la navigation par le bas venant derrière, mais restant une option viable. iOS a tendance à utiliser uniquement une barre d'onglets, ce qui peut limiter vos options de navigation de niveau supérieur, mais offre une vue claire de toutes à la fois. Dans ce cas, les deux systèmes d'exploitation fournissent des composants similaires qui peuvent être utilisés en fonction de la complexité de votre application, mais la différence visuelle entre les deux systèmes devrait naturellement vous diriger, par exemple, la barre de navigation globale dans Android et son absence dans iOS.

   L'évolution rapide du matériel mobile au cours des dernières années a introduit de nombreuses variables et inconnues : téléphones tout écran, encoches de formes et de tailles différentes, utilisation accrue des gestes pour la navigation à l'échelle de l'appareil, etc. Tous ces changements offrent une puissance sans précédent à l'utilisateur, mais peuvent être pénibles lorsque nous essayons de comprendre tous les cas d'utilisation d'un écran donné dans notre application. Compte tenu de ces préoccupations, une bonne approche pour éviter toute confusion pour nos utilisateurs serait de garder des modèles de navigation simples et cohérents, sans surcharger l'application avec trop de gestes, de barres et d'options de balayage multidirectionnel.

   

5. Typographie : les deux plates-formes ont leurs polices de caractères par défaut : San Francisco pour iOS et Roboto pour Android. Sauf si vous optez pour une police personnalisée, étroitement adaptée au style général de votre application, vous devez vous en tenir aux valeurs par défaut. Gardez à l'esprit que les utilisateurs peuvent modifier leur police système par défaut et cela n'affectera pas les vues que vous avez personnalisées avec une police de caractères spécifique.

   Par exemple, les utilisateurs dyslexiques risquent de ne pas profiter pleinement de votre application s'ils ont remplacé la police par défaut par une police qui répond spécifiquement à leurs besoins. Si vous prenez en charge des utilisateurs susceptibles d'utiliser des polices non latines (comme le cyrillique, l'arabe, etc.), assurez-vous que vos polices personnalisées fournissent également ces caractères supplémentaires. Si vous aimez les jeux, vous avez probablement vu ces classements avec des scores élevés obtenus par des joueurs russes dont les noms se distinguent par leur police différente. Il ne s'agit que d'une erreur mineure commise au cours de la phase de développement, et non d'une « fonctionnalité » pour des joueurs spécifiques, et bien que cela n'oblige probablement pas les utilisateurs à abandonner votre application, cela peut certainement entraîner une expérience utilisateur dégradée ou entraîner des plaintes ou de mauvaises critiques.

   

6. Les autres composants : les boutons, les transitions d'écran, les animations, les micro-interactions, les fiches d'action, les alertes et tous les autres types de contrôles de flux sortent du cadre de cet article, mais ils doivent suivre le principe général que nous avons appliqué à d'autres éléments de conception jusqu'à présent : les deux plates-formes découragent les éléments personnalisés excessifs, car ils pourraient distraire et confondre l'utilisateur ; lorsqu'il s'agit de design, la première impression est généralement la dernière pour de nombreux utilisateurs et c'est pourquoi il est si important d'attirer l'attention des utilisateurs dès le début et de les faire se sentir chez eux, pour ainsi dire.

Dans le monde réel, vous pouvez voir quelques exceptions très populaires aux règles dont nous avons discuté - les applications iOS qui suivent les directives de conception matérielle et certains produits Android qui suivent les directives d'interface humaine d'Apple, mais ces applications ont leur propre style éprouvé. Les utilisateurs connaissent les applications et leur conception, et pour eux, il est logique de fournir une sensation légèrement plus personnalisée.

Approche multiplateforme bien faite

D'un autre côté, si votre projet est basé sur une solution multiplateforme (comme React Native, Flutter, Xamarin, etc.), vous devez considérer quelle serait la plate-forme principale sur laquelle vous souhaitez vous concentrer et commencer à partir de là.

Ces dernières années, ces nouveaux frameworks ont apporté des améliorations massives de la productivité dans le développement d'applications multiplateformes. De plus en plus d'entreprises adoptent ce paradigme de développement, car il offre un délai de mise sur le marché plus court, une meilleure rentabilité et moins d'obstacles techniques, les principaux inconvénients étant une prise en charge limitée des fonctionnalités et une UX sous-optimale dans certains cas.

Alors que pratiquement toutes les anciennes solutions de développement multiplateforme étaient basées sur des vues Web et rencontraient donc de sérieux problèmes de réactivité sur de nombreux appareils, nous pouvons aujourd'hui utiliser des composants natifs même dans des approches multiplateformes. Cette amélioration majeure a affecté le marché à bien des égards et a rapproché toutes les plateformes mobiles d'un pas de plus vers l'unification de l'expérience visuelle de l'utilisateur sur divers appareils et plateformes.

Si vous décidez d'opter pour une solution multiplateforme, vous pouvez commencer comme dans une application native standard en créant le squelette de votre application. Une fois que vos principales priorités sont opérationnelles (configuration des dépendances de base, création d'un MVP, atteinte des jalons spécifiques au projet, publication de votre première version, etc.), vous pouvez facilement séparer vos conceptions principales pour les deux applications, en utilisant la plate-forme- outils spécifiques fournis par chaque framework. Selon la taille de votre équipe et le délai disponible, vous pouvez même envisager d'inclure ces modifications dans la version 1, juste pour éviter toute confusion future lorsque les choses ne se ressemblent plus dans une version de plate-forme donnée.

Après tout, vous devez évaluer lequel de ces principes sera valable pour votre application. Comme dans presque toutes les entreprises de notre industrie, vous devriez essayer de suivre les directives, tout en les ajustant légèrement pour répondre à vos besoins spécifiques. Par exemple, si la navigation dans les tiroirs est ce qui a vraiment du sens pour votre simple application à cinq écrans, vous n'avez pas besoin de trouver des solutions compliquées pour chaque plate-forme. Faites en sorte qu'il soit évident et facile pour l'utilisateur de reconnaître vos boutons et outils personnalisés, qu'il s'agisse de composants clés ou de personnalisations mineures.

Une bonne conception respecte les habitudes des utilisateurs

Pour résumer, nous pouvons répéter quelque chose que nous savons déjà : un bon design est un design qui respecte les habitudes des utilisateurs dans chaque système d'exploitation. Juste un peu de polissage à la fin pourrait faire la différence entre une application moyenne et une excellente application.

Souvent, votre application ne fournira pas suffisamment de fonctionnalités uniques pour convaincre les utilisateurs uniquement avec du contenu. La plupart des gens décriront leur décision de choisir un produit plutôt qu'un autre avec "une intuition". Cette catégorie d'utilisateurs fonde ses choix principalement sur la façon dont ils se sentent lorsqu'ils utilisent l'application en évaluant implicitement la réactivité, le choix de style général, la palette de couleurs et les composants visuels individuels qu'ils voient à l'écran.

Par conséquent, essayez de vous assurer que votre produit se démarque non seulement par ses caractéristiques étonnantes, mais aussi par un emballage de haute qualité correspondant à la qualité des services qu'il fournit.