Guide complet de création de wireframes d’applications mobiles

Temps estimé : 1 à 2 heures. Je recommande de faire cet exercice avec les principales parties prenantes.

Démarrons en partant du principe que vous avez été chargé de créer une application mobile. La première chose que vous devez vous demander est : « Quel est le problème que je résous et pour qui je le résous ? ». Les réponses à cette question composée jetteront les bases de votre conception, car elles fourniront des indications qui pourraient orienter les caractéristiques et les fonctions de vos conceptions. Ces réponses vous aideront aussi certainement à décider quel sera le MVP (produit minimum viable) pour votre conception.

Par exemple, vous pouvez avoir beaucoup de fonctionnalités sur la feuille de route du produit, mais vous devez seulement vous concentrer sur les fonctionnalités essentielles pour réussir le lancement de la première version de l’application. Vous pouvez commencer par vous demander  » Quelles caractéristiques et fonctions devons-nous créer pour que notre population cible puisse réaliser son objectif/ sa tâche ? « 

Pour répondre à cette question, vous pouvez créer un flux utilisateur basé sur le  » chemin heureux  » de votre utilisateur principal (vous pourrez vous concentrer sur tous les cas limites plus tard). Je recommande un tableau blanc où vous écrivez d’abord toutes les étapes clés de l’utilisateur. Une fois que vous avez écrit ces étapes clés, vous pouvez commencer à créer des croquis de haut niveau de ces étapes. Cela vous aide à déterminer quelles sont les affordances dont l’utilisateur a besoin à chaque étape et permet de garder le scope creep à distance.

Note : Essayez de vous empêcher de faire des croquis sans avoir d’abord écrit le flux utilisateur. Notre esprit peut devenir très créatif et hors piste si nous sautons directement dans le croquis.

Voici à quoi peut ressembler cet exercice après que vous ayez écrit votre flux d’utilisateurs et créé des croquis bruts en dessous. Rappelez-vous, cela n’a pas besoin d’être joli, mais cela doit transmettre vos idées suffisamment pour que vous passiez à l’étape suivante, les wireframes numériques.

Exemple 1

Exemple 2

.

Exemple 3

Deuxième étape : Wireframes numériques de basse fidélité

Durée estimée : 2 à 3 jours, en fonction de l’étendue du MVP.

Une fois que vous avez déterminé les wireflows de votre MVP, l’étape suivante consiste à créer des wireframes légèrement plus détaillés. Vous pouvez créer un prototype papier ou passer directement aux wireframes numériques (si la vitesse est essentielle, je saute généralement aux wireframes numériques).

Note : Si vous travaillez avec une marque établie, il pourrait être possible d’utiliser des composants d’un système de conception existant et vous pourriez passer directement à la haute-fidélité, étape 3, ci-dessous.

Je recommande de créer des artboards pour les écrans clés que vous avez découverts dans votre exercice de croquis. Le nombre d’écrans dont vous avez besoin augmentera au fur et à mesure que vous évoluerez dans le processus de wireframing d’esquisses, de wireframes basse fidélité, à des wireframes haute fidélité.

Pour les wireframes numériques basse fidélité, utilisez l’outil de conception de votre choix pour créer des formes simples et utilisez des polices de base pour créer vos wireframes. Il existe également de nombreux kits d’interface utilisateur qui peuvent accélérer ce processus et créer des conceptions de basse fidélité un peu plus attrayantes visuellement. Je recommande également d’utiliser une taille médiane de tableau d’art qui pourrait fonctionner sur la plupart des tailles d’écran de téléphone. Si vous avez les données de votre démographie cible et quelle taille de téléphone est principalement utilisée par eux, alors allez avec cette taille d’écran.

J’utilise une taille d’artboard de 875 x 667px lorsque j’utilise Adobe XD (ou n’importe quel outil de conception car la plupart ont des tailles prédéfinies intégrées) car c’est le « chemin médian » des tailles d’écran (en particulier pour l’iPhone). Je trouve que cette taille fonctionne bien pour l’iPhone 8 et l’iPhone X, et je trouve que cela fonctionne bien pour Android également.

Voici un exemple d’écrans de basse fidélité en action:

Une fois que vous avez créé vos écrans à basse fidélité, testé vos conceptions avec des utilisateurs et reçu l’approbation des parties prenantes, vous êtes maintenant prêt à créer les écrans à haute fidélité.

Etape trois : wireframes numériques à haute fidélité

Durée estimée : 1+ semaines. Cela dépendra de si vous avez un système de conception en place ou si vous le créez à partir de zéro au fur et à mesure. Cette étape est également plus longue car il y aura probablement plus d’écrans ajoutés que dans la phase de basse fidélité.

Cette étape est celle où vos conceptions prennent vie ! C’est aussi la phase où vos conceptions commencent vraiment à ressembler à une application mobile fonctionnelle que vous pouvez prototyper, tester, itérer, faire approuver, puis, finalement, remettre à l’équipe de développement.

Considérations :

• Si le produit sur lequel vous travaillez a déjà une marque établie, vous tirerez très probablement les couleurs, les icônes et les polices des directives de la marque.
• Si le produit sur lequel vous travaillez n’a pas un look and feel de marque complètement établi, vous pouvez utiliser trouver et utiliser un kit UI pour accélérer votre processus de conception.

La considération suivante est de savoir par quels écrans vous commencez. Vous pouvez commencer par :

• Des écrans clés pour chaque section de votre navigation principale, ou ;
• Des flux d’utilisateurs clés pour l’utilisateur, ou ;
• Prioriser les écrans que vous concevez en fonction de l’ordre du calendrier de développement (c’est généralement là que je commence, afin de pouvoir travailler dans une méthode agile, en m’assurant d’avoir des écrans prêts à être transférés lorsque l’équipe de développement en a besoin).

Dans cet exemple, je vais montrer le processus d’utilisation d’un kit d’interface utilisateur établi dans Adobe XD. Et je vais commencer par la connexion/signature des utilisateurs et la création de profils parce que les équipes de développement avec lesquelles j’ai travaillé commencent généralement par la gestion des utilisateurs dans leur processus de développement d’applications.

Le kit UI que j’ai choisi a déjà une palette de couleurs établie, des styles de caractères et des éléments UI communs (aka composants) qui peuvent être copiés et collés tout au long des wireframes.

Note : Au début, je recommande de transformer tous les éléments que vous prévoyez de réutiliser en composants (ou symboles). De cette façon, si vous avez besoin de changer la flèche de retour d’une flèche  » ←  » à une carotte  » <« , vous pouvez le changer via le composant maître et le faire mettre à jour à travers tous les wireframes vs avoir à copier et coller l’édition sur chaque écran qui doit être mis à jour.

Exemple de couleurs, de styles de caractères et de composants :

Pour commencer le processus, je commencerais à construire les écrans d’accueil, de signature et de profil d’utilisateur :

Puis, je commencerais à construire les éléments de navigation globale :

Après cela, je commencerais à créer des fils haute-fidélité pour tous les flux d’utilisateurs de l’application, en commençant par les flux priorisés en fonction de la livraison au développement (ou pour tous les éléments qui nécessitent encore des tests utilisateurs).

Je recommande de créer des fichiers de conception distincts pour chacun des flux d’utilisateurs clés afin que vous puissiez facilement prototyper et partager avec le développement lorsque vous travaillez dans une méthode agile (c’est-à-dire un fichier pour l’inscription de l’utilisateur et la création de compte, un fichier pour la messagerie, un fichier pour l’expérience de recherche, etc.).

A mesure que les conceptions sont approuvées et remises au développement, je recommande de créer un fichier maître avec tous les écrans et les composants maîtres. Lorsque vous travaillez en équipe, je recommande généralement qu’une personne soit en charge du fichier maître afin de réduire la confusion. De cette façon, chaque membre de l’équipe sait qu’il puise dans le fichier maître approuvé lorsqu’il travaille à la création de nouvelles fonctionnalités et de nouveaux flux pour l’application.

Par exemple, voici une vue d’ensemble d’un fichier maître pour l’un de mes projets. Notez que j’ai regroupé et ordonné les écrans par flux d’utilisateurs et par priorité de développement. Je continuerai d’ajouter à ce fichier maître au fur et à mesure que je construirai la prochaine séquence de flux d’utilisateurs.

Quelques principes directeurs pour créer de meilleures applications mobiles

Maintenant que vous savez comment commencer à schématiser vos expériences numériques, il est temps de mettre à niveau votre approche de conception. Si vous créez une expérience pour les appareils mobiles, sur des systèmes d’exploitation comme iOS et Android, il y a quelques considérations clés à garder à l’esprit. Voici quelques conseils généraux (et quelques opinions personnelles) sur la conception d’applications mobiles et sur la manière de passer moins de temps à concevoir pour chaque type d’appareil sur le marché. Si vous cherchez davantage d’inspiration, vous pouvez également consulter ces exemples de wireframes pour les sites Web et les applications mobiles.

J’ai la ferme conviction qu’un design doit être aussi omniprésent que possible. Donc, dans la mesure du possible, j’encourage une conception agnostique du système d’exploitation. Voici pourquoi :

• Si un utilisateur passe d’un téléphone Android à un iPhone, il ne devrait pas avoir à apprendre deux façons différentes d’utiliser une application qui résout le même besoin. La solution devrait rester la même. Je sais qu’il peut y avoir des différences gestuelles et des possibilités spécifiques à un appareil, mais je pense qu’une application doit offrir la même interface utilisateur et le même flux d’utilisateurs quel que soit le système d’exploitation. Et les fonctions importantes ne devraient pas être cachées trop profondément dans des menus contextuels ; c’est juste une mauvaise UX.
• C’est coûteux de concevoir, développer et maintenir deux (ou plus) expériences totalement différentes (surtout quand l’expérience pourrait être la même quelle que soit la plateforme).
• Lors de la conception et du maintien des différentes expériences, celles-ci peuvent commencer à devenir très différentes. Cela peut nuire à la marque et rendre le suivi et la mise en œuvre des commentaires et des fonctionnalités plus difficiles.

Alors, comment créer des conceptions omniprésentes et être agnostique au niveau des appareils ? Voici comment je le fais :

1. Traiter mes conceptions mobiles comme si je concevais pour le web mobile. Mes conceptions sont réactives car il existe une infinité de tailles d’écran et de densités de pixels (celles-ci changent aussi vite que les entreprises peuvent les concevoir). En tant que concepteurs, nous n’avons pas le temps de concevoir pour chaque densité de pixels et je ne pense pas que mes clients veuillent payer pour ce temps, de toute façon. J’utilise donc une largeur de planche d’art de 375, ce qui fonctionne pour la plupart des modèles d’iPhone modernes et Android.
2. Je gère la forme bizarre de l’écran de l’iPhone X et de l’iPhone 11 en disant à l’équipe de développement de simplement étendre la couleur d’arrière-plan de l’en-tête vers le haut.
3. J’ai la chance d’avoir plusieurs types de téléphones différents à ma portée, de sorte que je peux ensuite tester mes conceptions via l’application mobile XD en utilisant une USB. C’est utile car je peux tester les tailles de police, les points de contact de l’interface utilisateur et la visibilité du contenu de l’écran lorsque le clavier est relevé. Je peux également tester la ligne de  » pliage  » et m’assurer que le contenu important, comme les CTA et le contenu important, reste visible et ne disparaît pas au bas de l’écran.
4. J’essaie de n’utiliser que des gestes qui sont universels, par exemple tapoter, glisser, appuyer et maintenir. Je pense que nous devrions pouvoir nous concentrer sur la meilleure expérience utilisateur, quel que soit le système d’exploitation.
5. J’utilise des SVG pour toutes les icônes et tous les logos afin qu’ils aient une belle apparence sur n’importe quelle résolution d’écran.
6. J’utilise des structures de navigation et de menu qui sont universelles et pas trop spécifiques au système d’exploitation.

La seule fois où je dois concevoir des wireframes qui sont spécifiques à un appareil est lorsque je fais un prototype et que j’appelle une fonction native de l’appareil, comme l’appareil photo. Même cela peut varier d’un téléphone à l’autre et d’un OS à l’autre.

La plupart de mes clients commencent avec iOS. Nous testons et validons le design et, une fois que c’est sur la bonne voie, alors nous développons pour Android. Et vous savez quoi ? Nous essayons de ne pas changer du tout l’interface utilisateur, ou les flux d’utilisateurs. Nous nous concentrons plutôt sur l’image de marque, l’aspect et la convivialité, les caractéristiques et les fonctions, et les flux d’utilisateurs. Tout revient à la chose la plus importante : l’expérience utilisateur de base.