Sélectionner une page
React Native : notre retour d’expérience

React Native : notre retour d’expérience

Bien que React Native soit une technologie plutôt récente, de nombreuses applications utilisées par des millions de personnes tous les jours sont basées dessus. C’est notamment le cas de Twitter, Uber Eats, Instagram ou encore Discord.

Ces entreprises reconnues ont choisi d’utiliser React Native car c’est une technologie qui permet d’avoir une expérience très proche du natif tout en développant une seule et unique application. Cependant, d’autres technologies utilisent et permettent de faire quelque chose de similaire, tel que Flutter ou Xamarin

Pourquoi, chez Sirup lab, avons-nous donc choisi de partir sur React Native ? Quel bilan peut-on tirer des projets que nous avons créés via cette technologie et comment les réussir ? C’est ce que nous allons voir ici.

Qu’est-ce que React Native apporte par rapport aux autres langages

Maturité de React Native

Tout d’abord, React Native est un framework développé par les équipes de Facebook issu de sa version web ReactJS, et en 5 ans, il est devenu un langage plutôt mature. Cette maturité, il la doit d’abord à ReactJS, qui est l’une des technologies les plus utilisées parmi les développeurs web de nos jours.

Il la doit également aux nombreuses évolutions qu’ont connues le langage, avec des mises à jour majeures et constantes, pour le rendre plus optimisé, plus fluide mais aussi plus simple à prendre en main. Le framework impose relativement peu de spécificités et l’utiliser revient pour beaucoup à écrire du JavaScript pur en ajoutant les fonctions et widgets spécifiques de React, ainsi que le JSX, qui permet d’écrire des pseudo balises HTML dans le code.

Support et aspect communautaire

En plus d’avoir acquis cette maturité, React Native repose sur une base communautaire relativement solide. L’un de ces exemples les plus marquants est react-native-community, qui fournit de nombreux composants aidant au développement, tel qu’un sélecteur de date, la gestion des permissions, la gestion des images vectorielles…

La communauté React Native est très active, et l’est également chez les francophones. Certains s’essayent à des défis tels que les “Can it be done in React Native ?” de William Candillon.  

Comparaison avec les langages natifs

React Native a la particularité d’utiliser les composants propres à chaque plateforme et rend son expérience très proche de ce que peut proposer une application native. De plus, il a l’avantage de fournir deux applications avec une seule base de code, ce qui permet de réduire considérablement les coûts de développement car il n’y a plus besoin de séparer les deux équipes iOS et Android.

Cependant, ce gain de temps vient avec un inconvénient : iOS et Android ont des lignes directrices bien différentes en termes de design, ce qui implique de devoir faire quelques concessions. En effet, certains éléments se retrouvent seulement sur l’une ou l’autre des plateformes, tel que les menus sandwichs d’Android, ce qui pourrait donner une expérience utilisateur amoindrie pour un utilisateur iOS.

React Native possède également des avantages d’un point de vue UI. Sa structure repose sur Flexbox, déjà très populaire sur le web et qui s’intègre relativement bien aux outils de design les plus populaires tels que Figma ou Adobe XD. Sa simplicité d’application et son intégration lui permettent de rivaliser avec des technologies natives similaires telles que Compose d’Android ou swiftUI côté iOS.

React Native ne fournit cependant pas les mêmes capacités de développement que le natif pour réaliser des UI ou animations complexes, mais il excelle cependant dans la réalisation d’applications simples et intuitives.

Comparaison avec Flutter

Flutter est un concurrent direct de React Native, qui permet lui aussi de développer une application mobile cross-platform avec une unique base de code. Ce framework, créé par Google, est écrit en Dart, qui est le langage uniquement utilisé pour Flutter. 

Google envisagerait de remplacer un jour Android par un nouvel OS, Fushia, qui serait intégralement écrit en Dart, mais pour le moment il reste plutôt réservé à Flutter. 

Les deux langages cross-platforms fonctionnent différemment mais donnent des performances plutôt équivalentes. 

La raison qui nous a poussé vers React Native plutôt que Flutter est que ce premier est plus facilement abordable par les équipes techniques de nos clients car très proche du JavaScript classique utilisé aussi pour du Web. 

Il est aussi plus mature (2015 pour React Native contre 2017 pour Flutter) rassemble une communauté nombreuse et active et nous semble donc plus pérenne que Flutter aujourd’hui. 

React Native Web 

Vous avez besoin de rendre votre application mobile disponible aussi sur le web ? React Native Web permet de transformer votre application mobile en site web responsif. 

Nous l’avons testé sur des premiers projets et les résultats sont étonnants ! 

Si l’application n’utilise pas trop de composants propres au mobile (camera, carnet d’adresse, partage natif) l’effort d’adaptation est très faible. Avec une même base de code il est maintenant possible d’adresser tous les écrans. Cela nécessite aussi une bonne connaissance des outils de build Web (Webpack, Babel).

Côté performance : c’est fluide et rapide. Vous souhaitez voir un exemple concret ? Twitter l’utilise. 

Côté SEO : à la différence de Flutter, comme nous sommes en JavaScript, il est possible de faire de l’optimisation simple. Le HTML généré est cependant complexe et non sémantique et l’optimisation sera probablement plus compliquée. 

Les bonnes pratiques pour développer en React Native

Un boilerplate à jour

Développer une application en React Native implique de savoir comment la créer et la documentation de Facebook indique d’ailleurs que l’on peut facilement en créer une. Or, de nombreuses parties d’une application sont très similaires l’une à l’autre, comme la navigation ou la logique de traductions. C’est là qu’interviennent les boilerplates, comme Ignite

Le principe d’un boilerplate est le même que pour un modèle PowerPoint ou InDesign : Il permet de partir d’une base de code commune afin d’arriver à accélérer le développement d’une application. Les seules paramètres variant d’une application à une autre étant son nom et les informations présentes sur les différents stores.

Une bonne pratique qui permet un gain de temps significatif est de créer son propre boilerplate. C’est ce que nous avons fait chez Sirup lab. D’abord avec une première version, plutôt dure à prendre en main, et moins propice aux évolutions. Puis, nous avons créé Mercury, qui reprend les bases communes de nos applications et qui s’étoffe au fur et à mesure avec de nouvelles fonctionnalités. L’avantage de gérer son propre boilerplate est qu’il est plus simple de le faire évoluer ou de le mettre à jour, car bien moins opaque qu’un système de boilerplate classique comme Ignite sur ses capacités et son fonctionnement.

Une utilisation optimale de React Native : React Navigation & Hooks

Le cœur de l’application réside dans sa navigation. C’est elle qui définit quelle page apparaît avant l’autre, comment celles-ci sont organisées entre elles, si elles sont cachées ou non, etc… Il est donc important de bien la structurer au départ de l’application.

Une librairie permettant de gérer ces aspects sur React Native est React Navigation. Cette dernière s’adapte parfaitement aux récentes mises à jour de React Native, et notamment aux Hooks, ce qui permet entre autres d’accéder à la navigation depuis n’importe quel écran.

TypeScript

React Native utilise le JavaScript. C’est un langage mature de haut niveau, plutôt permissif, mais qui nécessite de faire attention aux moindres parcelles de son code afin d’éviter de potentielles erreurs. C’est pourquoi de plus en plus de projets utilisent une alternative à celui-ci : TypeScript.

TypeScript est un langage de programmation libre et open source développé par Microsoft qui a pour but d’améliorer et de sécuriser la production de code JavaScript. C’est un sur-ensemble de JavaScript, ce qui signifie qu’un code JavaScript correct l’est également en TypeScript.

L’avantage majeur du TypeScript est donc l’ajout des différents types de variables. Il permet par exemple de définir les réponses que l’on peut recevoir d’un serveur afin de l’utiliser de manière optimale dans son code.

Chez Sirup lab, nous avons également commencé à utiliser ce langage avec notre nouveau boilerplate. Il permet un gain de temps de développement ainsi qu’une réduction drastique des bugs introduits par des erreurs de syntaxe.

React Native Paper

Une fois que le corps de l’application est en place, la partie la plus importante est son apparence. Mais, comme pour la navigation, cette partie là peut facilement se répéter d’une application à une autre, avec une palette de couleurs, des tailles de textes similaires reprenant certains standards comme H1, H2, etc…

Avant d’utiliser React Native Paper chez Sirup lab, nous nous contentions de respecter les directives de Material Design de Google. Seulement, celles-ci sont plutôt denses, et l’on devait donc en permanence adapter nos composants aux comportements de ceux présents chez Google.

Nous avons donc intégré à notre boilerplate ce design system, qui nous permet de répliquer un même et unique thème de manière simple et intuitive dans le reste de notre application.

Firebase

Développer une application mobile demande souvent une API qui permet de gérer toutes les données. Lors de nos nombreux projets, nous avons pu traiter avec un certain nombre d’API, faites pour la plupart de manières différentes. Ces API ne se ressemblent pas mais ont quelque chose en commun : elles impliquent systématiquement de devoir repenser la façon de les connecter à nos applications, et plus globalement à notre boilerplate.

Pour simplifier ceci nous avons décidé de partir sur une solution plus globale : Firebase. Ce service a pour avantage d’être très bien intégré à React Native via React Native Firebase, une librairie externe très efficace et régulièrement mise à jour. Ce service permet non seulement d’avoir une API uniformisée, mais propose également toute une suite de fonctionnalités tel que la gestion des notifications, des Analytics ou des outils de livraison continue.

Nous l’utilisons maintenant de manière systématique dans tous nos projets. Dorénavant, nous avons simplement à adapter le format des données présentes et non leurs intégrations. On acquiert également de l’expérience au fur et à mesure, ce qui nous fait gagner en rapidité sur l’ensemble de nos développements.

Quelques points négatifs de React Native

React Native permet donc, en développant une application pour les deux plateformes simultanément, de gagner en rapidité et en coût avec une expérience utilisateur de qualité. Néanmoins, le framework ayant beaucoup évolué, de nombreux points de friction sont apparus.

React Native permet d’utiliser des modules initialement conçus pour une plateforme native. Avant sa version 0.60, ces modules devaient être intégrés manuellement dans l’application, ce qui pouvait régulièrement s’avérer chronophage. Cela a depuis été résolu par une logique d’auto-link des paquets utilisés, mais ce n’est pas systématiquement le cas. Par exemple, les Unimodules d’Expo, un service permettant facilement de gérer des sons, des images ou de la localisation nécessite une intégration particulière, et il peut être complexe de s’en détacher une fois cette solution choisie.

Un autre problème de taille avec l’utilisation de dépendances via des paquets est que ceux-ci sont régulièrement mis à jour, avec de nombreux changements majeurs, demandant alors de retravailler leur intégration. Le risque ici peut donc être relativement élevé si l’on a peu de budget ou de temps à accorder à la maintenance de son application. 

Créer une application mobile : pourquoi pas vous ?

Depuis l’arrivée de React Native sur le marché du mobile, de nombreuses améliorations ont été constatées, autant du côté développement avec par exemple l’auto-link qu’au niveau performance, ou celles-ci peuvent maintenant rivaliser avec ce que proposent les langages natifs traditionnels. Par ailleurs, React Native continue ses améliorations fréquentes, à tel point que 3 voire 4 mises à jour majeures sortent par an, en apportant toutes leur lot de nouveautés.

D’un point de vue développeur, son framework en JavaScript rend son apprentissage plus simple et rapide que d’autres langages. Il est donc plus simple de trouver sur le marché des talents capables de prendre en main React Native. De plus, créer une application cross-platform sera forcément un avantage : celle-ci ne sera faite qu’une seule fois pour les deux plateformes majeures du marché, donc un coût divisé jusqu’à 2.

Vous souhaitez réaliser un nouveau produit numérique disponible sur mobile ? Vous aimeriez vous faire accompagner par des experts pour aller plus vite ? Faites appel à nous, nous  proposons des offres au forfait pour réaliser la V1 de votre produit. 

Si vous hésitiez, n’hésitez plus, c’est le moment ou jamais de vous lancer !

Figma : aller plus vite en utilisant Design Systems, Autolayouts et Composants

Figma : aller plus vite en utilisant Design Systems, Autolayouts et Composants

Introduction

Comme beaucoup de startups, designers et entrepreneurs, vous avez commencé à utiliser Figma pour votre application. Après les quelques mois de prise en main, vous commencez à vous poser des questions : 

  • Comment utiliser les composants pour simplifier les mises à jour de votre appli, sans devenir très compliqué ? 
  • Comment adapter des écrans du web au mobile sans vous casser la tête tout en gardant une cohérence forte entre les expériences ? 
  • Comment organiser vos fichiers pour réaliser vos designs plus rapidement, permettre à tous de les lire, et ne pas utiliser toute la RAM de votre ordi ? 

Chez Sirup lab, cela fait plus de 2 ans que nous utilisons Figma intensément sur plus de 15 produits. Nous avons affiné nos méthodes au fur et à mesure pour réaliser de meilleurs designs : plus simples à utiliser, à maintenir et à développer.

Dans un premier article nous parlons des principes base pour prendre en main Figma. Ici, nous allons sur les choses avancées qui vous feront aller beaucoup plus vite. 

Voici notre retour d’expérience. 

Comment gérer les états ?

Problématique

Chaque composant et chaque écran vont avoir plusieurs états.

  • Actif / inactif / hover
  • En chargement / vide / en erreur / en scroll / complet

Ces états doivent être maintenus en cohérence.
Si on modifie un bouton dans l’état complet, on doit s’assurer que c’est aussi le cas dans tous les autres états.
Sur la moindre application, nous observons rapidement une 50 aines d’états.
Les maintenir en cohérence sans organisation prend beaucoup de temps.

Solution

Utiliser un composant qui les contient tous

Chaque écran est un composant.

Il contient tous les états sur différents layers qui seront cachés suivant la situation.

Nous utilisons les autolayouts pour que les mises en page s’adaptent lorsque des éléments sont cachés.

Créer un composant pour les états clés

Nous encapsulons les états clés dans un nouveau composant.
Cela nous permet de les mettre à jour rapidement si nous les utilisons dans un prototype.
Cela nous permet aussi d’utiliser la surcharge, notamment sur un composant.
Les écrans sont organisés en colonne. Cela nous permet de vérifier qu’une modification fonctionne bien dans tous les états.

Résultat

Si cette solution demande plus d’effort à la composition, elle permet toutefois des mises à jour très rapides.
Nous avons régulièrement plus d’une centaine de petites modifications.
Nous pouvons les faire en quelques heures au lieu de quelques jours.
Un design très cohérent et une réduction des corrections lors du développement.

Comment gérer les tailles d’écran ?

Problématique

Nous travaillons régulièrement sur des applications qui s’adaptent du plus grand au plus petit écran.

Nous utilisons pour ça les recommandations de Material Design.

Ces écrans peuvent s’afficher sur un nombre variable de colonnes. 

Ils peuvent rester centrés (grille fixe) ou s’adapter sur la largeur (grille flexible).

Solution

2 layouts et des composants pour les panels

L’écran contient 2 mises en pages.

Une première à 2 colonnes qui sera utilisée pour les grands écrans.

Une seconde à 1 colonne pour les plus petits.

Ces colonnes contiennent les mêmes composants.

Cela permet de modifier à un seul endroit toutes les versions.

Nous créons ensuite une instance pour chaque taille d’écran.

Et nous n’affichons que la bonne mise en page en fonction de la taille.

Un autolayout global pour gérer le padding

Les contenus sont inclus dans un autolayout.
Par défaut, l’autolayout prend toute la place disponible (scale) et son contenu est centré.
Il s’agit d’une grille fixe.

Dès que l’écran est trop étroit, nous changeons les règles.
Le contenu de l’autolayout se contraint pour prendre la place disponible.
Tout le contenu s’organise automatiquement.
Les espacements deviennent plus compacts et les textes sont adaptés.
Cela reste néanmoins la même instance. Il est donc possible de modifier pour le web et pour le mobile à un seul endroit.

Voici le Figma contenant ces exemples🎁.

Résultat

Encore une fois cette solution demande plus de rigueur sur la composition. Une fois le mécanisme compris, la déclinaison sur toutes les tailles d’écran est très rapide.

Ce système est très proche de ce qui est fait techniquement. Cela donne donc aussi l’avantage d’être simple à transposer et plus rapide à développer.

Comment maintenir un design system à jour sans trop d’effort avec la bonne organisation ?

Problématique

Pour une agence de design, chaque produit est un design system différent.
Nous travaillons sur des applications qui font plus de 50 pages écrans et qui doivent rester cohérentes.
Ces applications ajoutent de nouvelles fonctionnalités régulièrement.
Nous avons expérimenté différentes organisations pour faire face à ceci.
Voici notre retour d’expérience.

Solution

Un Figma contenant un design system simple

La shared library contient les composants et le thème de l’application.
Il ne contient pas de choses complexes comme des écrans.
Maintenir les composants est coûteux et on se focalisera donc sur ce qui n’en change pas d’un projet à un autre.

Nous travaillons actuellement sur un design system encore plus minimaliste pour faciliter la composition.

Un Figma par version de l’application

Pour chaque nouvelle version d’une application, nous créons un nouveau Figma. Organiser ceci par version permet d’éviter les problèmes de chronologie. Par exemple, travailler sur 2 évolutions qui modifient le même écran.

Nous lions la shared library pour réutiliser le thème et les composants.

Nous commençons en général par un audit de la zone à modifier.

Il y a parfois des déviations entre les derniers designs et ce qui est réellement disponible.

Parfois nous n’avons pas de Figma pour la zone étudiée. 

Nous utilisons une page de travail incluant :

Les flots utilisateurs organisés en prototype

Une zone d’exploration pour les designs en attente de validation

Les composants propres à ces flots. Nous créons un composant à chaque fois qu’une partie de l’interface se répète.

Tous les écrans organisés en colonnes.

Tout avoir sur une même page permet de vérifier plus rapidement l’impact d’une modification. Voici un de nos fichiers qui utilise cette structure 🎁. 

Nous ne déplaçons pas systématiquement les composants d’une version dans le système. Notre design system est cependant corrigé et modifié en continu. Nous utilisons le même fichier sur plusieurs projets. Nous continuons de l’améliorer encore aujourd’hui.

Résultat

Nous utilisons maintenant ce système depuis plus d’1 an sans modification majeure.
Nous avons plusieurs versions de notre Design System, qui s’améliore en parallèle sur chaque produit. Nous essayons de garder la version la plus aboutie comme nouvelle base pour la suite.

Avant ça nous avons exploré beaucoup d’options plus difficiles à maintenir.
Notamment, il faut rester très vigilant sur la taille du Figma. De gros fichiers contenant beaucoup d’images peuvent utiliser toute la mémoire de votre ordi et sont longs à ouvrir.

Changer d’organisation peut demander beaucoup d’effort.
Notamment il est difficile de déplacer une arborescence de composants d’un fichier à un autre.

Conclusion

3 choses à retenir :

  • Utiliser un composant pour chaque écran pour pouvoir mettre à jour ces états et les prototypes à un seul endroit.
  • Utiliser les autolayouts et la surcharge pour décliner les versions web et mobile.
  • Garder un petit système, qui sera plus simple à maintenir et plus facile à utiliser

La prochaine fois nous parlerons de … 

  • Comment s’assurer qu’un design utilise tous les raccourcis de la technologie tout en restant innovant ?
  • Comment corriger son design efficacement en utilisant les commentaires ?
  • Comment utiliser Figma pour ses spécifications techniques ?

Besoin d’aide sur Figma ? Contactez-nous 💌. Nous proposons de l’encadrement et des forfaits de designs accessibles aux startups. 

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.