Sélectionner une page
Comment rendre son produit économiquement viable avec  Firebase Analytics et Google Analytics … sans être un expert

Comment rendre son produit économiquement viable avec Firebase Analytics et Google Analytics … sans être un expert

Quels indicateurs mettre en place pour commencer à utiliser les Analytics sur son produit ? 

Comment identifier les améliorations ou évolutions à apporter pour augmenter sa valeur ? 

Comment bien vérifier qu’une évolution porte ses fruits ? 

Chez Sirup lab, cela fait plusieurs années que nous utilisons Google Analytics, et sa version simplifiée pour mobile : Firebase Analytics. 

Nous les utilisons pour aider startups et entrepreneurs à rendre leur produit économiquement viable. Nous les aidons à croître beaucoup plus rapidement. 

Nous avons déjà doublé le chiffre d’affaires de plusieurs partenaires en appliquant des évolutions simples aux bons endroits. 

Explorer des tableaux de bord réels reste le meilleur moyen de bien comprendre comment configurer la collecte de donnée, mais ces tableaux sont confidentiels et donc difficiles à partager (sans flouter 90 % des images).   

Pour bien illustrer cette démarche nous étudions donc ici 2 tableaux de bord conçus par Google. Ils sont entièrement disponibles pour tous à des fins éducatives :

Emplacement du projet de démo

Nous ferons ensuite une synthèse sur une méthode simple, accessible à tous, à mettre en place sur votre propre projet. 

Conversions

Il s’agit de définir les indicateurs en forte corrélation avec la valeur de l’application, et donc souvent avec les revenus. 

Firebase 

L’application connectée à ce tableau est un jeu gratuit. Les revenus proviennent principalement de la publicité et un peu d’achat dans l’application. Convertir les visiteurs en utilisateurs actifs, c’est-à-dire des utilisateurs qui reviennent, est donc la priorité.

Liste des indicateurs de conversion

18 indicateurs sont configurés, mais uniquement 6 sont actifs. 

Parmi eux : 

  • “app updated” peut être utilisé pour décompter les utilisateurs actifs à long terme ce qui est en lien avec les revenus publicitaires.
  • “In app purchase” est lui lié directement aux revenus de microtransactions.
  • “completed 5 levels” est un indicateur de rétention  à court terme. Il est intéressant car il utilise un compteur. 
  • “level complete » est un indicateur d’activation qui devrait se déclencher dès le premier lancement, en corrélation avec “completed 5 levels”. 
  • “first open” est un indicateur automatique qui permet de décompter tous les nouveaux visiteurs. 

Nous avons donc une séquence chronologique avec des indicateurs sur le 1er lancement, quelques jours plus tard, et sur du long terme, alignés avec les objectifs de revenu du produit. 

Google Analytics 

L’application connectée à ce tableau est un site marchand. Les revenus sont générés par des achats ponctuels. Convertir des visiteurs en clients est donc la priorité. 

Liste des objectifs configurés

4 Objectifs sont configurés. Parmi eux : 

  • Finaliser un paiement est l’indicateur direct pour décompter les clients 
  • Pour finaliser, il est nécessaire de s’enregistrer. C’est une étape avec potentiellement un abandon. 
  • Tous les paiements passent d’abord par l’initiation du règlement. 
  • Décompte des personnes affichant plus de 10 pages sur une session. Il s’agit probablement d’un indicateur en forte corrélation avec l’initiation d’un paiement. 

Ici aussi nous remontons dans la chronologie avec des indicateurs de plus en plus en amont. 

Méthode

  1. Partir de l’indicateur en rapport le plus direct avec la valeur du produit. 
  2. Puis remonter dans la chronologie pour définir des indicateurs plus réactifs. 
  3. Sélectionner entre 5 et 10 indicateurs répartis entre la première utilisation et la conversion finale. 

Entonnoirs (Funnels)

Une fois les grands indicateurs définis, il s’agit d’observer plus en détail à quelle étape les utilisateurs décrochent pour cibler les améliorations et les évolutions. 

Firebase

Cet entonnoir affiche plus en détail la conversion de visiteur en utilisateur. Il permet d’identifier les frictions potentielles pour terminer un niveau du jeu. 

Un entonnoir de conversion sur un niveau complété

Notez que Firebase n’offre que des entonnoirs ouverts. Cela signifie que les utilisateurs à une étape n’ont pas forcément observé l’étape précédente. 

Cela reste cependant une approximation suffisante pour optimiser cette portion de la conversion. 

Ici, nous voyons clairement qu’une grande partie des utilisateurs qui lancent l’application pour la première fois ne commencent pas de niveau. Une portion beaucoup moins importante commence un niveau mais ne le finit pas. 

Amener plus de nouveaux utilisateurs à commencer un niveau est une bonne piste d’exploration. 

Google Analytics

Cet entonnoir affiche en détail les étapes précédant l’acte d’achat. 

Entonnoir de conversion sur un achat complété

Ceci est en entonnoir fermé. Ça signifie que les utilisateurs à une étape donnée ont tous observé l’étape précédente. 

Le taux d’abandon le plus fort est sur la dernière étape avec 19 % de conversion sur l’achat. 

Amener plus de personnes qui ont choisi leur mode de facturation et de livraison à payer est donc une piste d’exploration. 

Méthode

  1. Sélectionner l’indicateur que vous souhaitez optimiser.
  2. Détailler les étapes en amont de cette conversion. 
  3. Configurer un entonnoir pour identifier les étapes de décrochage à optimiser. 

Comportement 

Une fois les indicateurs et leurs étapes définis, il s’agit d’ajouter quelques indicateurs d’usage (event) qui pourront être utilisés sur une étude future. Ce que vous ne mesurez pas maintenant est perdu. 

Firebase 

Chaque étape du jeu est mesurée. 

Liste des évenements

Les étapes de succès sur les différents parcours, incluant les invitations.

Les événements d’échec sont également mesurés (échec de niveau, réinitialisation de niveau). 

Sous cette forme, une analyse est difficile. Ces événements trouveront leur place dans un entonnoir ou pour définir une audience (dessous).

Google Analytics

Seuls 6 événements sont configurés ici.

Liste des actions des événements configurés

Les ”Event actions” sont utilisées. Uniquement 2 catégories sont définies. 

C’est une bonne pratique puisque les systèmes récents (Firebase Analytics ou Google Tag Manager) ne supportent aussi que des couples action / valeur. 

Les labels sont utilisés pour identifier l’objet de l’action (un article dans la plupart des cas) 

Ici aussi, nous observons des événements pouvant dégrader les conversions (Remove from cart). 

Méthode

  1. Ajouter un événement sur chaque action possible pour l’utilisateur. 
  2. Mesurer aussi des événements “négatifs”, c’est-à-dire pouvant provoquer un recul par rapport à l’objectif 
  3. Rester simple : une dimension (action) et une valeur (objet de l’action). 

Audience

Une fois tous nos indicateurs mise en place, nous allons diviser l’audience en groupes plus petits partageant des événements en commun pour préciser les analyses.

Firebase

Ici, l’audience est divisée selon une courbe d’apprentissage.

Les audiences configurées

Les utilisateurs experts ont complétés tous les niveaux.

Chaque groupe précédent a découvert un peu moins de l’application. 

Cela divise l’audience totale progressivement jusqu’au groupe expert avec la plus haute rétention, et donc générant le plus de revenus publicitaires. 

Un groupe sur les plantages est en place pour mesurer l’impact négatif sur les conversions. 

Google Analytics

Google Analytics permet de configurer des audiences de plusieurs façons.

Il est possible de configurer des segments. Ils ne sont pas partageables largement. Nous ne pouvons pas les afficher ici. 

Il est aussi possible de configurer des dimensions ou des variables personnalisées. Nous avons ici une dimension “user category”.

La dimension personnalisée « User Category »

Ici, la décomposition se fait sur un type de persona : les employés (de Google ?) ou des distributeurs. 

Méthode

  1. Diviser votre audience sur une courbe d’apprentissage pour s’assurer que chaque groupe transfère sur une groupe de plus haute valeur. 
  2. Diviser votre audience selon vos personas avec des dimensions personnalisées pour identifier quel groupe tire le plus de valeur de votre produit. 
  3. Définir une audience sur des événements négatifs pour définir à quel point ils baissent la valeur de votre produit. 

Expérimentation

Une fois votre audience cible et les frictions identifiées, il s’agit d’expérimenter des modifications ou des évolutions et vérifier une augmentation de la valeur. 

Firebase

Le test AB consiste à comparer la performance d’une ancienne version de l’application avec de nouvelles versions sur la même plage de temps et sur des groupes d’utilisateurs significatifs.

C’est la méthode la plus simple pour s’assurer qu’une modification est utile. 

La première expérimentation cible l’activation en augmentant le démarrage d’un niveau.

Détail d’une expérimentation

Comme évoqué plus haut, Google cherche à augmenter la proportion d’utilisateur qui démarre un niveau. Cela doit se faire sans les faire fuir ensuite. On observe donc un objectif secondaire pour augmenter la réalisation de 5 niveaux.

Chaque expérimentation contient de la même façon un objectif principal et des objectifs secondaires.  Cela permet d’éviter qu’un gain d’un côté engendre une perte de l’autre. 

Google Analytics

“Optimize” permet de faire l’équivalent sur Google Analytics. 

Les tests ne sont cependant pas accessibles sur ce compte de démo 😭. 

Google Optimize sur Google Analytics

Méthode

  1. Choisir un indicateur clé à augmenter suite à une modification ou à une évolution
  2. Choisir un ou deux indicateurs secondaires qui pourrait baisser suite à cette expérimentation. Prendre des indicateurs à plus long terme. 
  3. Expérimenter systématiquement les nouvelles versions.

Conclusion

Bien que chaque produit et chaque système statistique soient différents, vous devriez pouvoir configurer ceci partout : 

  1. Conversion : mesurez un indicateur directement lié à vos revenus, et 3 indicateurs intermédiaires répartis dans le temps pour suivre la progression.  
  2. Entonnoir : créez un entonnoir pour un indicateur à améliorer, et 3 indicateurs précédents pour identifier les expérimentations à mener. Commencer par les indicateurs en amont (le début d’entonnoir) pour plus d’effet sur la conversion finale. 
  3. Comportement : ajoutez systématiquement des indicateurs sur les actions des utilisateurs et les événements détériorant l’expérience. Soyez prêt pour les investigations futures. 
  4. Audience : segmentez sur les personas pour bien identifier l’audience cible. Focalisez vos analyses. 
  5. Expérimentation : utilisez systématiquement des tests AB pour vérifier qu’une évolution augmente bien la valeur du produit. Apprenez des résultats pour affiner les prochaines expérimentations. 

Cela vous aidera à mieux identifier les parties de votre produit à améliorer, à augmenter régulièrement sa valeur et donc à rendre votre produit économiquement viable beaucoup plus rapidement. 

Si vous souhaitez l’aide d’experts pour vous aider à le prendre en main, faites appel à nous ! Nous offrons des ateliers aux incubateurs, donnons des formations d’équipe et renforçons les équipes produit en place.

Figma : retour sur 2 ans d’utilisation

Figma : retour sur 2 ans d’utilisation

Que vaut Figma, cet outil de design numérique récent et ultra-collaboratif ? Quelles sont les avantages face à Sketch ou Adobe XD ? Quelles sont ses contraintes ? Comment le prendre en main rapidement pour se faire son propre avis ?

Chez Sirup lab, cela fait plus de 2 ans que nous utilisons Figma intensément. Nous avons dépassé la période de lune de miel et si nous en apprécions les avantages, nous avons aussi dû en contourner les inconvénients.

Voici notre retour d’expérience pour vous aider à vous faire votre avis. 

Un outil de design collaboratif 

Partager entre designers

Lors de la conception il arrive souvent que 2 designers aient besoin d’intervenir sur la même maquette. 

Certains logiciels le permettent en partageant les fichiers communs via le cloud.

Cela provoque rapidement des conflits de version difficiles à résoudre. C’est une perte de temps et un risque d’incohérence du design. 

Il y a aussi la possibilité de travailler chacun sur un document séparé mais c’est dangereux car il est possible de partir dans des directions opposées. 

Figma se démarque car il permet de travailler en même temps sur un même fichier. 

À l’image de Google doc, chaque contributeur du projet peut intervenir sur le même fichier. Il existe plusieurs types de compte : les éditeurs (souvent les designers) et les viewers (le client, les développeurs). Tous peuvent interagir au moins en mettant des commentaires. Cela permet d’avancer en équipe et beaucoup plus rapidement. 

Multiplayer editing

Partager avec les ingénieurs

Pour gagner du temps sur la création d’une application, il est recommandé de faire intervenir les développeurs dans la phase de conception. 

Ils regardent et analysent les designs pour évaluer la faisabilité de chaque composant d’un écran. 

Cela permet de gagner du temps sur la phase de développement et de respecter le budget du client lors de la phase de développement.

Chez Sirup lab nous travaillons en itération, c’est-à-dire que nous développons les fonctionnalités une par une. 

La collaboration en temps réel avec tous les développeurs permet de partager le design en travaillant déjà sur la prochaine itération. 

Comme ils travaillent tous sur le même fichier, les développeurs sont tenus au courant des dernières versions du fichier. 

Figma est un logiciel très puissant pensé pour les développeurs et pour les designers contrairement à d’autres. Il propose des outils adaptés aux designers qui facilitent aussi le travail du développeur. Chacun des acteurs du projet a toutes les informations en temps réel pour l’intégration (layout, interaction et asset). 

Informations techniques sur Figma

Partager avec des clients

Proposant plusieurs types de compte, Figma permet de donner une licence aux clients qui peuvent donc également suivre la création. 

Le client peut commenter les maquettes directement pour que nous fassions les corrections plus rapidement. C’est un atout qui permet de valider les designs efficacement, d’éviter les nombreux allers-retours et les pertes de temps considérables.

Le design peut aussi être livré sous forme de prototype. Cela permet au client de se faire une idée plus claire de l’expérience du produit et aide à identifier des ajustements plus tôt.

Commentaires sur Figma

La concurrence

Figma vs Sketch ?

Nouveau sur le marché, Figma se confronte à Sketch, logiciel encore très utilisé. Très similaires, ces deux logiciels ont cependant quelques différences et en particulier la collaboration qui reste aujourd’hui impossible en simultané sur Sketch. 

Ayant beaucoup utilisé les deux logiciels, voilà, pour nous, les avantages de Figma sur Sketch :

Figma est une application web. Elle est donc disponible sur Mac, sur PC alors que Sketch n’est disponible que sur Mac. Elle n’a pas besoin d’installation. Ceci aide beaucoup la collaboration.

Figma permet la collaboration en temps réel. Il est donc beaucoup plus facile de faire collaborer une équipe de design là au Sketch demande à mettre en place des systèmes de gestion de version.

Figma intègre les commentaires, les assets pour les développeurs, et le prototype. Il nous a permis de remplacer 4 outils par un seul.

Le pricing

Le prix est également une des forces de Figma. 

La licence starter permet de créer 3 projets gratuitement. Ensuite la suite la licence ne coûte que 12$ par mois et par poste premium. 

Sirup lab ne possède que 3 comptes premium, 1 pour le product manager, 1 pour le designer et 1 pour le directeur technique, ce qui représente une dépense de 45$ par mois. Tous les autres comptes sont gratuits car ils sont simplement en viewer pour les développeurs ou encore les clients. 

Un partage en lecture seule permet encore aux développeurs de faire les exports d’éléments graphiques et de voir les positions des éléments.

Il est possible d’ajouter ou de supprimer des licences au mois selon les besoins.

Des limitations à contourner

Une application gourmande en mémoire

Bien qu’étant une application web, Figma affiche des performances très impressionnantes. Nos propres fichiers peuvent contenir plus d’une dizaine de pages, plus d’une centaine de frames par page, plusieurs centaines de composants … et Figma s’en sort ! 

Ces performances sont possibles car Figma va charger une bonne partie du fichier en RAM. 

Si vous êtes comme nous et si vous aimez produire plusieurs variations pour les écrans clés, ajouter des captures d’écrans du produit existant ou des sources de référence, vous allez rapidement vous trouver avec des fichiers très volumineux. 

Outre le temps initial de chargement, vous risquez d’observer des ralentissements de l’interface. Chaque copier-coller va vous couter plusieurs dizaines de secondes. 

Sur un Macbook pro avec 8Mb de RAM, il n’est pas rare de voir une dialogue nous avertissant que nous n’avons plus de mémoire. 

Notre contournement ? Un peu de ménage régulièrement. 

Chaque design qui n’est plus nécessaire (explorations non retenues, benchmarks ou audits) sont déplacés chaque semaine dans une page “archives”. 

Chaque mois, les archives sont déplacées dans un fichier séparé d’archive pour le projet.

Le message fatidique de manque de mémoire

Un design qui n’est pas assez figé

La collaboration en temps réel de Figma vient avec un problème de taille : comment voir ce qui change ? Ceci est d’autant plus impactant si nous utilisons des composants. 

En effet, changer un simple bouton peut modifier une centaine d’écrans. Aucun système ne permettra de voir ce qui a changé par rapport à la version précédente. Un développeur aura donc des difficultés à mettre à jour son développement en conséquence. 

Quid de la gestion de version ?  S’il est possible de figer une version dans le temps, cela ne semble pas non plus être une solution. Ces versions ne peuvent plus être éditées, et l’avantage de l’édition simultanée est totalement perdu.  Il ne sera pas possible de voir les différences entre la version courante et une version précédente spécifique. 

Notre contournement ? Aujourd’hui nous allons utiliser les commentaires. Il s’agit d’informer les développeurs des modifications réalisés sur un design en cours de production. Nous allons aussi être prudent sur les mises à jour de composants, et ne le faire qu’une fois une exploration approuvée par tous.

Une gestion des commentaires rudimentaire

Figma intègre un système simple et utile de commentaire. 

Chaque contributeur peut placer une petite bulle sur le design, écrire un message, mentionner une personne. Un commentaire peut se transformer en fil de discussion. 

Cela est très pratique pour gérer les demandes de correction ou les demandes d’informations par les développeurs. Ces messages sont vite très précieux. 

Il est cependant très facile de les perdre ! 

Si un commentaire est placé sur autre chose qu’une frame par exemple, il ne sera pas “attaché” à l’image derrière : si l’image est déplacée, le commentaire restera sur place, perdant de son sens. 

Si une partie du design est effacée, les commentaires associés se retrouveront “détachés” et ne pourront plus être associés dans le design. 

Notre contournement ? N’utiliser les commentaires que pour des informations à courte durée de vie : demandes de correction, de clarification. Utiliser des textes pour ajouter tout détail qui vient informer le design. Sur des réorganisations d’un fichier, bien le faire en affichant les commentaires pour les déplacer au préalable et ne pas perdre l’association.

Les commentaires détachés n’apparaissent plus au centre

Comment utiliser le logiciel Figma pour faire un prototype en 3 étapes ?

1. Ajouter les composants material design gratuits sur Figma

Ne partez pas de zéro.

Votre prototype est un assemblage de composant : boutons, listes, cartes.

Chaque composant peut avoir plusieurs états : actifs, inactifs, appuyés, vides, pleins.

Tout réaliser de zéro avec un haut niveau de qualité représente des jours de travail. Ne cédez pas à la tentation !

Commencez donc par dupliquer la librairie Material Design adaptée de la librairie de Google.

Vous pouvez ensuite y configurer votre thème :

  • La palette de couleur. L’outil de Material design vous aidera à choisir une couleur primaire et secondaire.
  • Vos polices de caractère. Limitez-vous à deux : une pour les titres et une pour les textes. Utilisez les polices mises à disposition par Google sur Google font.  Elles sont libres de droit et facilement adaptables sur tout type de supports. Choisissez des typographies qui se marient correctement entre elle. Pour ça, certains sites existent pour vous aider à faire une bonne alliance comme fontpair.

Vous avez maintenant les briques élémentaires pour composer vos écrans.

Astuce avancée : sélectionnez les composants qui sont disponibles dans la technologie que vous utilisez. Cela permettra de composer un design qui puisse être développé.

Template Material Design

2. Composez vos écrans en assemblant les composants

Votre fichier Figma configuré, il est temps de construire vos écrans. 

Commencez par définir un premier parcours utilisateur, par exemple le premier lancement de l’application. Utilisez des frames pour ceci, prenez la taille qui correspond à votre propre téléphone. Ça sera utile pour tester le prototype plus tard.

Déposez dans ces frames les composants de l’écran : bouton, champ texte, texte, images.

Modifiez les textes, les contenus pour être au plus proche de l’application finale.

Astuce avancée : Dans une application ou un site web, le nombre d’écrans monte vite. La plupart des écrans auront plusieurs états : vide, en chargement, plein, en erreur. En cas de modification, il est difficile de tous les mettre à jour rapidement. Pour pallier cela nous créons un composant pour chaque écran et nous utilisons des instances dans les prototypes.

Assemblage de composants

3. Créer un prototype et testez-le sur votre téléphone avec l’app Figma mirror

Une fois les écrans clés de votre parcours réalisés, liés les avec l’outil prototype.

Utilisez des transitions simple, référez-vous aux applications de qualité. Est-ce que l’écran arrive de la droite ? du bas ? Ces détails ont de l’importance.

Concentrez-vous sur un seul parcours. Ajoutez toutes les interactions est tentant, mais cela est très difficile à maintenir et n’est pas réellement utile pour tester une experience.

Téléchargez Figma Mirror sur votre téléphone. Une fois connecté, sélectionnez sur l’éditeur, l’écran à tester. Il apparaîtra sur votre mobile ! Vous pouvez maintenant tester votre parcours et l’ajuster.

Astuce avancée : L’outil smart animate permet de faire des transitions plus complexe entre les écrans en ne faisant bouger que les éléments qui changent. C’est utile pour un carrousel par exemple.

Conclusion 

Figma nous a considérablement fait gagner en vitesse et en qualité et nous ne pourrions revenir sur Sketch aujourd’hui. C’est un outil complexe, qui demande de l’apprentissage et un ordinateur puissant. Avec un peu d’accompagnement, il est néanmoins possible d’avoir des résultats très satisfaisant en peu de temps.

Si vous souhaitez de l’aide d’experts pour vous aider à le prendre en main, faites appel à nous ? Nous offrons des ateliers aux incubateurs, donnons des formations d’équipe et renforçons les équipes produit sur Figma.

Le développement : dernière étape pour créer une application mobile

Le développement : dernière étape pour créer une application mobile

Le développement : dernière étape pour créer une application mobile

Nous partageons régulièrement des astuces avancées de création d’appli pour les mettre à la portée de tous. Vous en connaissez peut-être certaines … d’autres devraient-vous surprendre.

Table des matières

La phase de développement

1. Développer sur iOS et Android

Commencer par une seule application, la moins chère
Créer une application qui fonctionne sur iOS et Android

2. Le découpage du design par séquences

Organiser le découpage en séquences
Adapter le découpage
Planifier le découpage

3. Tester et valider

Utiliser la vidéo
Prioriser les demandes de correction
Valider quantitativement

En conclusion

 

La phase de développement

 

La création d’une application mobile est devenu un enjeu stratégique pour beaucoup d’entrepreneurs. 

C’est donc primordial de concevoir une appli d’excellente qualité. Qui réponde aux attentes des utilisateurs finaux. Tout ça en se démarquant.

Ce n’est pas toujours simple.

Pour vous aider à lever les zones d’ombre, chez Sirup lab, nous partageons avec vous notre méthode. 

Celle que nous mettons en pratique avec nos clients. C’est-à-dire les bonnes astuces qui fonctionnent. 

Nous espérons qu’elles vous feront gagner du temps. Et surtout, qu’elles vous aideront à prendre la bonne direction.

Que ce soit sur iOS ou Android, créer une application mobile passe toujours par 3 étapes : 

  • La recherche
  • La conception
  • Le développement

Dans un 1er article, nous abordons la phase de recherche. C’est l’étape indispensable pour prioriser et documenter vos idées. Elle permet aussi d’obtenir une estimation précise du coût de votre produit.

Dans un 2ème article, nous vous parlons de la phase de conception. Elle sert à définir et choisir la meilleure solution. C’est aussi à ce stade qu’on peut tester et améliorer son prototype.

Et la dernière étape, c’est celle de la réalisation de l’application. 

Dans ce dernier article, nous partageons avec vous les bonnes astuces associées. Comme pour les phases précédentes, il y en a 3.

  1. L’organisation entre iOS et Android
  2. Le découpage du design en séquences
  3. Le test et la validation

Lorsque cette phase commence, vous avez déjà un prototype fonctionnel.

Vous l’avez testé auprès de vos utilisateurs finaux. Et son utilisabilité est vérifiée.

L’objectif ici : limiter les retards et respecter le budget. Mais aussi éviter un décalage trop important entre votre prototype et l’appli finale.

La clé de cette dernière étape peut se résumer en 2 mots : avancer progressivement. 

1. Développer sur iOS et Android

À ce stade, vous avez déjà une conception validée et estimée.

La difficulté c’est de créer deux applications en même temps : une pour iOS et une pour Android. Les 2 équipes en charge des projets peuvent être bloquées sur le même problème.

Tester deux applications peut aussi prendre beaucoup de temps.

La question qui se pose c’est : comment créer les applications sur iOS et Android le plus rapidement possible et le moins cher possible ?

Plusieurs possibilités s’offrent à vous.

  • Commencer par une seule application, la moins chère

Pour être plus efficace, c’est intéressant de valider et d’affiner son produit sur une seule application. Et donc de prioriser l’une d’entre elles. 

Il y a 3 manières de prioriser.

La première option, c’est de commencer par l’application la moins chère.

Pour bêta-tester, corriger et affiner. La deuxième application bénéficiera des améliorations de la première.

La seconde option, c’est de prioriser celle qui peut générer le plus de revenus. C’est donc souvent sous iOS.

Et la dernière, c’est de commencer par celle qui aura le plus d’audience.

Quelque soit l’option choisie, une fois la première appli prête, vous pourrez la passer en bêta-test. Avec les retours des utilisateurs, elle sera corrigée et affinée.

Elle pourra ensuite être mise à jour et servir à la deuxième application. La seconde aura donc besoin de moins de corrections. Voire même, avec un peu de chance, d’aucune correction.

Son développement sera plus rapide. Il pourra d’ailleurs être lancé quand les deux applications seront prêtes.

Pour planifier l’ensemble de ce travail, vous pouvez utiliser un outil comme Gitlab. Il permet de créer les différentes tâches de développement, de suivre leur évolution et de répertorier les bugs. C’est aussi très utile pour optimiser la collaboration entre les développeurs.

  • Créer une application qui fonctionne sur iOS et Android

Il s’agit ici de monter les deux applications à partir d’un seul et même code. Plusieurs technologies permettent de le faire. 

React Native est l’une d’entre elles.

React Native PaperReact Native Paper

La technologie est très solide. Que ce soit en terme de performance (rapidité d’affichage, fluidité) ou de stabilité. 

Elle a aussi l’avantage d’évoluer régulièrement et de ne pas stagner. Elle est d’ailleurs utilisée par de grands acteurs comme Uber ou Airbnb.

Elle permet de créer des applis de haute qualité. Avec des interfaces utilisateurs simples et efficaces.

Par contre, l’animation et les transitions sont moins poussées que sur une application dite native, c’est-à-dire développée spécifiquement pour iOS ou Android. 

Et donc l’expérience utilisateur et les interactions sont plus limitées.

Chez Sirup lab, nous l’utilisons principalement pour des startups early stage. Sur la création d’une première application mobile.

Notamment parce que ça permet de réduire les coûts et d’être plus rapide. Sans pour autant mettre de côté la qualité.

2. Le découpage du design par séquences 

Nous vous conseillons de construire votre produit étape par étape. Principalement pour garder le contrôle sur les coûts.

À ce stade, il s’agit de déouper le design en séquences. Concrètement, c’est segmenter le parcours utilisateur en plusieurs petites trajectoires.

Les séquences reprennent les user stories identifiées dès la phase de recherche.

L’idée c’est de prioriser les séquences qui sont essentielles pour les utilisateurs. Car si le développement de l’application s’arrête (par exemple pour des questions de budget), le produit est fonctionnel. 

Ça permet de donner du sens à chaque étape du développement. Et de tester et valider en continu.

C’est aussi rassurant de se dire qu’à tout moment, le produit est prêt.

  • Organiser le découpage en séquences

Pour chaque séquence, on prend la partie du design correspondante. Et on l’adapte pour qu’elle soit entièrement autonome.

Si on prend l’exemple de Netflix, la séquence prioritaire c’est de visionner un film. Si on peut faire ça, l’application est fonctionnelle.

Il faut donc pouvoir accéder à une liste de films. Et avoir la possibilité d’en sélectionner un. Si cette séquence est développée, l’outil est prêt.

Tout ce qui concerne le filtrage par catégorie, les suggestions, l’accès à un compte personnel, … sont autant de séquences secondaires. Elles sont ajoutées au fur et à mesure.

Prenons un autre exemple pour que ce soit tout à fait clair.

Chez Sirup labnous avons récemment développé une application de rééducation physique pour un client. Il s’agit de proposer aux utilisateurs de suivre un entraînement sportif.

Ici, la séquence prioritaire c’est regarder une vidéo avec un mouvement à faire. Et pouvoir le reproduire.

A contrario, s’identifier à l’aide d’un login et mot de passe n’est pas prioritaire. Car cette séquence ne permet pas à l’application d’être fonctionnelle.

  • Adapter le découpage

Si la séquence débouche sur une autre action mais que celle-ci n’est pas encore accessible, il faut supprimer cette action.

Pour qu’il n’y ait aucune dépendance à une autre séquence. Et qu’elle puisse fonctionner indépendamment.

Idéalement, chaque séquence est développée de cette façon.

Petit à petit. Les unes après les autres.

À chaque nouvelle séquence ajoutée, il faut s’assurer que les étapes essentielles pour arriver à celle-ci ont été développées.

En parallèle, comme pour le découpage des user stories, il faut s’assurer que les séquences soient de taille homogène. Et qu’il n’y en ait pas une plus dense que l’autre.

Découpage du design par séquencesDécoupage du design par séquences

  • Planifier le découpage

L’idée c’est de ne pas trop planifier. Pour rester flexible et pouvoir s’adapter. Grâce à ça, on peut tester continuellement et ajuster le produit pour continuer à faire du sur-mesure.

Par exemple, on peut définir avec exactitude ce qui peut être produit en deux semaines.

Et anticiper sur les deux semaines suivantes.

De cette façon, si l’équipe est en avance, elle peut commencer à travailler sur la suite.

Ça permet d’être plus agile. Et de modifier l’application au fur et à mesure, pendant qu’elle est construite. Éviter de modifier des éléments qui interviennent plus tard, c’est aussi moins de frustration et de perte de temps.

3. Tester plus rapidement et valider

À ce stade, vous avez déjà une première partie de votre appli développée.

De nouvelles difficultés vont sûrement se présenter.

Par exemple, décrire des bugs prend du temps.

Et il y a toujours une ou plusieurs informations manquantes.

Les allers-retours entre l’équipe produit et vous sont fréquents.

Alors comment transmettre les problèmes à l’équipe produit de la façon la plus claire et rapide possible ?

En lien direct avec vous, l’équipe produit se chargera ensuite d’estimer le budget.

  • Utiliser la vidéo

Pour pouvoir tester votre produit, demandez que l’équipe produit vous envoie une vidéo avec toutes les étapes à explorer.

C’est important pour ne rien oublier. Par exemple, pour tester correctement, parfois il faut se déconnecter du compte. C’est l’équipe produit qui pourra vous guider sur ces points.

Bien définir ce qui est attendu est primordial. Et ce n’est pas toujours clairement fait.

L’idée, c’est que rien ne manque lorsque vous allez faire votre propre test et que vous compreniez bien comment tester. C’est primordial pour éviter que le test soit invalide.

Autre exemple, il ne faut pas oublier de tester les phases de téléchargement, d’installation, de désinstallation mais aussi de réinstallation de l’application.

Ce sera très utile ensuite pour les ingénieurs.

Au moment du test, faites une capture vidéo de votre écran. Enregistrez toute la session et parlez à voix haute. Ça permet de suivre ce que vous faites. Mentionnez les étapes, les problèmes rencontrés, etc.

Reproduire un problème survenu lors d’un test n’est pas évident. Expliquer ce qui se passe à haute voix est essentiel pour définir toutes les étapes qui permettent systématiquement de reproduire le même problème. Il faut savoir qu’un bug qui n’est pas reproduit à tous les coups ne pourra probablement pas être corrigé.

Des outils comme Reflector (payant) ou AZ recorder (gratuit) – sur Android – offrent un rendu de grande qualité pour un test sur téléphone.  On peut aussi citer Genymobile/srccpy, un outil là encore gratuit mais plus technique.

Une fois le test fini, envoyez la vidéo à l’équipe produit pour qu’ils puissent prendre en compte les bugs.

  • Prioriser les demandes de correction

L’objectif ici, c’est de corriger les problèmes mais sans ralentir le développement.

Or, c’est impossible d’estimer le temps qu’il va falloir pour corriger un bug. Parce que ce qui prend le plus de temps, c’est de comprendre ce qu’il se passe.

Il faut donc éviter d’interrompre l’équipe pour qu’ils corrigent des problèmes sans arrêt. Sinon ils n’avancent plus. Et les retards s’accumulent.

En parallèle, il ne faut pas non plus entasser trop de problèmes car cela entraîne aussi beaucoup de retards.

Alors comment faire ?

La meilleure option selon nous, c’est de séparer et hiérarchiser les demandes de correction de la façon suivante :

 les bugs déjà existants et constatés sur le produit

●  les améliorations qu’on aimerait faire et auxquelles on pense au fur et à mesure du développement

●  les nouvelles fonctionnalités qui viennent en tête petit à petit

Les améliorations et les nouvelles fonctionnalités prennent beaucoup de temps. Il faut donc voir avec l’équipe s’il faut les traiter. Et si oui, à quel moment le faire.

Des outils peuvent vous aider à prioriser. De nouveau Gitlab ou des solutions payantes comme Asana ou Jira.

Dashboard GitHubDashboard GitLab

En ce qui concerne les bugs, il y a ceux qui doivent être résolus tout de suite et ceux qui peuvent attendre que l’application soit disponible sur les stores.

Voici un exemple de priorités que nous utilisons lors du développement d’applications :

  • P1 : tout ce qui empêche de tester l’application (à fixer rapidement pour ne pas ralentir l’équipe en charge de la production).
  • P2 : tout ce qui empêche de mettre l’application sur le store (crashs, perte de données…, tout ce qui impacte beaucoup l’expérience utilisateurs et peut entraîner des avis négatifs sur le store).
  • P3 : tout ce qui est important mais pas critique, c’est-à-dire qui peut être corrigé après la mise à disposition sur le store (ils sont toutefois à fixer avant d’ajouter de nouvelles stories au produit. Il faut éviter d’accumuler des bugs empêchant la sortie de l’application).
  • Valider quantitativement

À ce stade, l’application a été entièrement débuggée..

Elle est prête à être testée par les utilisateurs finaux.

L’objectif de ces derniers tests est de vérifier que l’application est réellement utile et qu’elle apporte de la valeur.

Concrètement, il s’agit d’observer :

  • Les utilisateurs qui la téléchargent et l’utilisent
  • Ceux qui l’utilisent et continuent de le faire sur la durée

Le 1er point correspond au taux d’activation.

Il mesure la conversion de “visiteurs” en “utilisateurs”.

Il faut donc définir à partir de quand on considère qu’une personne a utilisé l’appli. Et c’est rarement à l’inscription.

Sur Netflix par exemple, ce sera quand l’utilisateur aura regardé un film.

Le second point correspond au taux de rétention.

Il mesure la conversion de “visiteurs” en “visiteurs actifs”, c’est-à-dire les utilisateurs qui reviennent de façon régulière.

La notion de régularité dépend évidemment du type d’application.

Par exemple, sur une application de réservation de billets d’avion, la rétention s’évalue a priori sur plusieurs mois. A contrario, sur Netflix, la rétention est plutôt d’une semaine à l’autre. Et sur une appli de streaming (type Spotify ou Deezer), elle s’observe d’un jour à l’autre.

Mais revenons-en au taux d’activation.

Pour le mesurer, il faut définir les actions dans l’appli qu’on considère comme une utilisation.

Ces actions sont mesurées grâce à un tableau de bord : l’entonnoir de conversion.

Analytics de Firebase

Il permet de visualiser les étapes suivies par les utilisateurs pour effectuer une tâche. C’est donc très utile pour voir s’ils réussissent ou s’ils échouent à chacune de ces étapes.

En ce qui concerne le taux de rétention, c’est très différent.

Il évalue la capacité à retenir des utilisateurs, à les fidéliser.

Il faut donc se demander à partir de combien de temps d’inactivité un utilisateur est considéré comme étant “inactif”.

Un second tableau de bord permet de définir la fréquence supposée d’utilisation de l’appli : l’analyse de cohorte.

Analytics de Firebase

Taux de rétention sur Firebase

Grâce à elle, le comportement des utilisateurs peut être observé au fur et à mesure du temps.

Pour mesurer l’activation et/ou la rétention, un outil comme Firebase est parfait. Il en existe d’autres comme Google Analytics, ou Mixpanel. Il faut simplement intégrer ces outils de mesure dans l’application.

Une fois ces deux dashboards en place, il reste à prioriser les améliorations pour augmenter l’utilité du produit.

L’impact de ces améliorations sur les taux d’activation et de rétention peut ensuite être évalué.

Chez Sirup lab, en général on prévoit 15 à 20% du budget initial pour faire évoluer l’appli après l’avoir mise sur les stores.

Pour mesurer la qualité technique de l’appli, des outils de mesure des crashs peuvent aussi être utiles.

Un crash, c’est lorsque l’application se ferme d’un coup. Sans prévenir.

L’impact est instantané car les utilisateurs n’apprécient pas. Cela se termine souvent avec un vote à 1 étoile sur les stores.

Analytics de FirebaseCrashlytics de Firebase

Quelques idées d’outils : Crashlytics de Firebase ou Bug snag. Ils permettent d’obtenir des informations sur les problèmes difficiles à reproduire. Ceux qui n’apparaissent pas de façon systématique.

Suite à ces tests et observations, il peut y avoir de nouvelles mises à jour de l’appli à faire. 

Dans ce cas, si les utilisateurs sont nombreux, distribuer la mise à jour à un petit panel est une bonne option (1 à 10% des utilisateurs par exemple). Ça permet de rester qualitatif tout en évitant un impact trop important en cas de retours négatifs. 

En conclusion

Grâce aux 3 dernières astuces développées dans cet article, vous avez :

  • Choisi la technologie et la stratégie à adopter sur iOS et Android
  • Défini des petites étapes pour construire votre produit pas à pas
  • Testé chacune de ces étapes, corrigé les problèmes rencontrés et surtout améliorer le produit

On arrive désormais au bout des 3 phases essentielles à la création d’une application mobile.

Dans la phase de recherche, on a vérifié le concept. On s’est assuré que l’idée est utile et qu’elle sera vraiment utilisée.

Avec l’étape de la conception, on a vérifié que la solution est simple d’utilisation et facile à construire.

Enfin, la phase de développement a permis d’avoir plus de contrôle sur le produit. Tout en restant dans les clous, que ce soit en termes de délais ou de coûts.

En vous proposant un article pour chaque étape (recherche, conception et développement), on a partagé un peu de notre expérience avec vous. Nous espérons que ça vous soit utile. 

Le bilan qu’on en tire, c’est qu’il ne faut pas hésiter à se faire accompagner par des professionnels.

Si le produit a été réfléchi, s’il est bien fini et simple d’utilisation, les résultats seront au rendez-vous. Voir les utilisateurs finaux s’emparer de son application, c’est une réelle satisfaction.

C’est ce qu’on vous souhaite. Qu’ils l’utilisent et qu’ils se l’approprient.

Et vous, quelles leçons en tirez-vous ? Partagez-les avec nous dans les commentaires ou envoyez-nous un email

 

La conception : 2ème étape pour créer une application mobile

La conception : 2ème étape pour créer une application mobile

La conception : 2ème étape pour créer une application mobile

Nous partageons régulièrement des astuces avancées de création d’appli pour les mettre à la portée de tous. Vous en connaissez peut-être certaines … d’autres devraient vous surprendre.

 

La création d’une application mobile pour smartphone n’est pas simple.

Ce constat, nous le faisons chaque jour chez Sirup lab.

Que ce soit le coût, le temps passé, ou même le produit fini : il y a souvent des imprévus.

Et de nombreuses zones d’ombre.

Spécialisés dans la création d’applications mobiles Android et iOS, nous avons mis en place notre propre méthode. Et elle est particulièrement efficace avec nos clients.

Elle permet d’anticiper et d’éviter pas mal de problèmes.

C’est cette méthodologie que nous souhaitons partager avec vous.

Dans un premier article, vous pouvez retrouver nos bonnes pratiques pour penser et documenter votre produit.

L’objectif ici : simplifier au maximum pour créer votre prototype et mettre en place les premiers tests.

Lorsque cette deuxième phase commence, vous avez déjà défini un périmètre d’actions prioritaires pour développer une application. Au moins sa V1.

Vous savez quelles user stories et fonctionnalités essentielles vont être développées. Et en combien de temps.

Dans la plupart des cas, l’estimation initiale du strict nécessaire à développer est encore au-dessus du budget.

Et la solution proposée ne se différencie pas assez de la concurrence.

Alors comment designer une application mobile de haute qualité sans exploser son budget ? Il y a quelques pistes à explorer.

1. Évaluer une meilleure solution pour développer une application

S’en tenir au budget qui a été défini en amont n’est pas toujours simple.

On a souvent plein d’idées mais c’est difficile de connaître les coûts associés.

Le budget peut vite exploser. Et devenir un frein dans la création de votre application.

Plusieurs options permettent d’éviter cela.

  • Les design sytems pour un développement Android ou iOS

L’autre option consiste à utiliser des composants issus de la technologie choisie.

En effet, une application Android ou iOS a sa propre façon de concevoir un design. C’est-à-dire son propre design system.

Le design system, c’est ce qui sert à définir les lignes directrices pour créer une application ou un site Web (textes, titres, couleurs, composants…).

Vous en trouverez un exemple ici, c’est celui que nous utilisons chez Sirup lab (Material Design sur Figma).

Material Design de Google définit par exemple les composants sur Android. Les Human Interface Guidelines définissent ceux pour iPhone.

Pas besoin de développement spécifique, ils sont prêts à l’usage.

Ces composants sont disponibles en téléchargement libre sur des outils comme Figma ou Sketch.

Un conseil : utilisez ces éléments pour ne pas avoir à tout réinventer. Cela peut vous faire gagner un temps précieux !

Utiliser des briques élémentaires déjà existantes (boutons, navigation, liste, menu, etc.) permet aussi parfois de réduire les coûts de moitié.

design-system
Adaptation Android et iOS

  • Le budget

Montrez ensuite vos écrans aux ingénieurs. Cela permet de vérifier que votre prototype rentre toujours dans le budget.

Leur demander une estimation est aussi une bonne façon de vérifier s’il reste des inconnus.

En parallèle, les écrans peuvent être annotés avec des axes d’exploration, des idées de recherche, etc.

  • La qualité

La dernière piste d’exploration concerne la qualité.

Demandez aux équipes produits s’ils peuvent définir une solution de plus haute qualité.

Par exemple en innovant sur les user stories dites “critiques” :

  • celles qui sont les plus fréquentes
  • celles qui sont destinées à l’utilisateur final
  • celles qui permettent de se différencier de la concurrence

Parfois, pour une plus haute qualité, c’est possible de faire plus simple et plus agréable.

Une fois cette étape franchie, comment s’assurer que la conception est sur la bonne voie ?

2. Créer un prototype

Il va falloir créer une conception testable, c’est-à-dire un prototype.

Pour ensuite pouvoir faire des tests utilisateurs.

C’est la façon la plus efficace de vérifier que le design est simple et agréable.

Les séquences principales doivent être designées pour pouvoir être testées. Mais également les interactions entre les différents écrans.

Dans l’idéal, ce document testable doit avoir un design haute fidélité.

Et être co-construit avec les designers et développeurs du produit.

  • Le choix des outils

Pour les entrepreneurs avec un niveau avancé, nous recommandons :

  • Sketch (uniquement disponible sur mac) et Invision
  • Figma (un petit nouveau très efficace, disponible sur le web)
  • Sketch et Figma permettent une conception très rapide en haute fidélité. Leur niveau de difficulté est proche de celui de Photoshop.
  • Invision est excellent pour récolter des feedbacks. Il permet aussi l’ajout de zones d’interaction sur des maquettes. Son niveau de difficulté est proche de celui de PowerPoint.
  • Figma permet aussi la collaboration en temps réel sur un même fichier

Prototype sur Sketch Prototype sur Sketch

Pour les entrepreneurs avec un niveau intermédiaire, les logiciels Balsamiq et Invision font très bien l’affaire pour concevoir le prototype.

  • Balsamiq permet de faire de la conception très simplifiée mais uniquement en basse fidélité. Il gère les files de commentaires sur les écrans. Et il s’intègre très bien avec des outils de conception graphique comme Sketch ou Photoshop XD. Son niveau de difficulté est proche de celui de PowerPoint.

Le prototype cliquable obtenu peut ensuite être testé.

Les débutants peuvent utiliser Moqups.

  • Moqups permet surtout de créer un prototype cliquable avec un design basse fidélité, c’est-à-dire très éloigné du design final. Tout comme Balsamiq, il permet de créer des files de commentaires (très pratiques pour obtenir des feedbacks). Le niveau de difficulté est proche de celui de PowerPoint.

Quelque soit l’outil choisi, le prototype est très malléable et permet de tester facilement.

C’est le moment d’identifier les expériences utilisateurs prioritaires pour les étudier au maximum.

C’est maintenant qu’il faut explorer le maximum de solutions pour trouver celle qui convient le mieux.

variations-séquence Plusieurs variations sur une même séquence : un parcours de recherche

  • L’importance des contenus finaux

Parfois la conception est plus simple qu’elle n’y paraît. Des raccourcis sont possibles et une alternative peut être proposée.

La meilleure façon de s’en rendre compte, c’est d’avoir des contenus définitifs.

C’est-à-dire les textes, les images et les informations finales. Surtout pas de lorem ipsum.

Même si le design n’est pas terminé, les contenus sont vraiment importants.

De la même façon, accordez une attention particulière à l’orthographe. Des fautes en trop grand nombre risquent de perturber les tests utilisateurs.

Le texte définitif permet aussi de confronter plusieurs solutions pour les user stories et voir laquelle fonctionne le mieux lors des tests utilisateurs.

N’oubliez pas que les séquences doivent présenter plusieurs alternatives possibles.

Si le texte est définitif et raconte une histoire, le scénario aura du sens pour la personne qui testera. Et le feedback ne sera pas biaisé.

design-contenu Un design avec le bon contenu peut être testé

Une fois ce travail fait, le prototype peut être testé.

3. Tester votre prototype et itérer

Grâce à l’étape précédente, vous avez entre les mains un prototype haute fidélité.

Vous devez ensuite vous assurer que votre produit est utilisable et meilleur que ses concurrents.

C’est la dernière étape avant de passer au développement.

Et pour ça, il faut passer par des tests.

  • La préparation des tests utilisateurs

La première chose à faire est de créer un script avec l’équipe produit.

Le script va servir à placer le décor et mettre les utilisateurs en situation.

Pour des tests en présentiel, il faut leur expliquer dans quel cadre ils sont censés utiliser le produit. Et donc dans quel état d’esprit ils doivent être pour le tester.

Le script doit aussi préciser que les commentaires des utilisateurs doivent se faire à voix haute. Pour que vous puissiez suivre ce qu’ils font en même temps qu’eux.

Et surtout, détecter d’éventuelles incompréhensions.

Ensuite, ils testent eux-mêmes.

Puis, il va falloir progressivement leur donner des tâches à réaliser.

L’objectif c’est qu’ils puissent explorer toutes les user stories. Mais aussi qu’ils puissent tester celles sur lesquelles l’équipe a encore des doutes.

Et voir si c’est suffisamment clair pour eux ou si ça demande des corrections.

Le script doit intégrer ces différentes tâches.

À la fin, ça peut être intéressant de terminer avec 3 questions du type :

  • Quelle est la facilité de prise en main ? Avec une note de 1 à 5 (1 : difficile / 5 très facile)
  • La recommanderiez-vous à un collègue ou ami ? Avec une note de 1 à 5 (5 : je recommande)
  • Si vous aviez une baguette magique, que changeriez-vous ?

Les réponses permettent d’obtenir davantage de feedbacks qualitatifs.

Une fois le script terminé, testez-le avec un premier utilisateur.

Cela permet d’éprouver le script. C’est-à-dire de calibrer le temps et d’identifier les problèmes de 3 types :

  • ceux qui sont liés à l’énoncé
  • ceux qui sont liés au prototype
  • ceux qui gênent le test utilisateur

C’est ce premier test qui permet de corriger les suivants.

Des tests utilisateurs à distance sont également possibles. Cela donne plus de flexibilité aux testeurs.

À noter que cela est plus complexe à mettre en place et peut réduire la quantité de feedbacks.

Maze.design est un outil qui permet de créer le script de test en donnant aux utilisateurs des missions à effectuer. Pendant qu’ils complètent la séquence, on peut suivre leur parcours en temps réel, le temps passé sur les différents écrans, etc.
trajectoires-maze-design Observer les trajectoires avec Maze.design

  • Vérifier une utilisabilité

En parallèle, il va falloir recruter 5 à 10 personnes pour effectuer les tests.

Leur profil doit être le plus proche possible de celui des utilisateurs finaux.

Pour vérifier l’utilisabilité d’un produit, 5 tests suffisent pour corriger 80% des problèmes

Les tests utilisateurs prennent en moyenne entre 20 et 40 min.

Vous trouverez un exemple de test d’utilisabilité ici

Idéalement, lorsqu’ils sont réalisés en présentiel, les tests doivent être filmés pour garder une trace.

Il faut aussi penser à noter les tâches réalisées par les utilisateurs sans aucune aide. Noter les erreurs aussi. Et l’impression générale : est-ce que le produit est agréable ? Intuitif ? Est-ce qu’il y a des éléments qu’ils modifieraient ?

Quelques outils d’enregistrement et de visio à distance peuvent être utile dans cette étape: ScreenflickReflectorMaze.design ou même Skype.

Maze.design Dashboard de Maze.design

À la fin des tests, 3 questions peuvent être posées :

  • Le produit est-il facile à prendre en main ? (avec une note de 1 à 5 / 5=très facile)
  • Le recommanderiez-vous à un ami ? (note de 1 à 5 / 5=je recommande)
  • Si vous aviez une baguette magique, que changeriez-vous ?

Elles permettent souvent d’obtenir des feedbacks utiles.

Les tests utilisateurs sont aussi l’occasion de recruter des bêta testeurs. À la fin, vous pouvez leur demander s’ils sont d’accord pour tester la première version du produit fini.

Vous pouvez aussi les questionner pour savoir s’ils ont d’autres personnes en tête pour le bêta test.

  • Corriger la conception

Une fois les tests utilisateurs effectués, vous pouvez en observer les résultats et regarder les vidéos.

Les problèmes identifiés doivent être annotés sur le prototype.

Et ensuite corrigés.

Si les corrections sont très importantes, n’hésitez pas à refaire des tests utilisateurs. C’est par exemple le cas lorsqu’il y a des ajouts d’écrans ou de nouveaux parcours.

Si les tests sont concluants, le produit est prêt à être développé.

Aujourd’hui, trop d’entrepreneurs ne testent pas le design de leur application.

C’est souvent une grosse erreur. La correction à ce stade est beaucoup plus simple qu’après le développement. Pensez-y.

En conclusion

Une fois les tests utilisateurs effectués, vous pouvez en observer les résultats et regarder les vidéos.

Les problèmes identifiés doivent être annotés sur le prototype.

Et ensuite corrigés.

Si les corrections sont très importantes, n’hésitez pas à refaire des tests utilisateurs. C’est par exemple le cas lorsqu’il y a des ajouts d’écrans ou de nouveaux parcours.

Si les tests sont concluants, le produit est prêt à être développé.

Aujourd’hui, trop d’entrepreneurs ne testent pas le design de leur application.

C’est souvent une grosse erreur. La correction à ce stade est beaucoup plus simple qu’après le développement. Pensez-y.

Si vous souhaitez être informé de la publication de la troisième partie, inscrivez-vous pour la recevoir directement par email.

Stagiaire en design d’interaction

Stagiaire en design d’interaction

Stagiaire en design d’interaction

Nous recherchons un stagiaire en design d’interaction avec une licence dans un domaine lié au design (ou une expérience pro équivalente) et ayant plusieurs réalisations sur mobile. 

  • Nous re-designons des applications natives pour des startups dans l’éducation, la santé et le bien-être.
  • Nous prototypons de nouveaux concepts, des idées d’outils pour les startups que nous testons et validons avec eux.
  • Nous mesurons le succès de nos produits. Nous n’avons pas peur d’expérimenter pour apprendre de chaque projet.
Xavier is organized and great at executing on goals. He is very detail-oriented and knows how to collaborate with design and engineering. He is always thinking about what is next and looking for opportunities to improve the product.
Jason Jones

Product Designer, Facebook