On ne présente plus ChatGPT. En tout cas, je ne le ferai pas dans cet article, mais si vous voulez mieux comprendre le modèle originel à la base de ChatGPT (GPT), on en parlait il y a 2 ans avec Julien Laugel, CEO de MFG Labs, dans ce podcast1 (et la genèse du modèle est détaillée dans cet article).
La hype autour de ce modèle super puissant montre l’importance croissante que prennent les outils fonctionnant grâce à de l’intelligence artificielle dans notre quotidien. Face à ces changements, notre métier de designer lui aussi doit évoluer. Je me demandais alors : Quelles seraient les guidelines spécifiques au design d’interface d’un outil fonctionnant grâce à de l’intelligence artificielle ?
J’ai posé cette question à ChatGPT en partant du principe que l’algorithme allait me donner un patchwork de ce qui se disait sur le sujet jusqu’en 2021, sans oublier que bien que les résultats soient impressionnants, ChatGPT a ses limites qui sont notamment :
L’output3 de ChatGPT constitue donc une base dont nous évaluerons la pertinence et sur laquelle nous construirons notre réflexion, rien de plus.
Le résultat n’a rien de révolutionnaire mais c’est un ensemble de règles qui semblent cohérentes. Voyons ce qu’elles valent dans le détail. Pour ancrer notre réflexion dans le réel, nous évaluerons leur pertinence directement sur l’interface Chat GPT elle-même ainsi que sur d’autres interfaces de services faisant appel à de l’IA.
Il est important de fournir à l’utilisateur des informations sur les actions que l’IA est en train de réaliser et sur les raisons pour lesquelles elle les réalise, afin de renforcer la confiance de l’utilisateur dans l’outil.
Dans cette guideline plusieurs niveaux de transparence sont abordés : le pourquoi et le comment.
D’autres interfaces donnent bien à leurs utilisateurs des indications sur les raisons de leurs actions et par là même, sont plus transparentes. C’est le cas de certaines recommandations Netflix qui sont explicitement faites suite au visionnage de contenu similaire.
Il est important de permettre à l’utilisateur de contrôler et de réviser les actions de l’IA pour s’assurer que celles-ci correspondent à ses attentes et à ses objectifs.
L’utilisateur a bien le contrôle sur les résultats de l’IA dans le sens où il peut :
Un autre exemple de contrôle par l’utilisateur est la suggestion de réponses par Gmail. Si l’utilisateur sélectionne une des réponses proposées, il peut ensuite la modifier avant envoi. Cela permet de gagner du temps tout en gardant le contrôle.
L’interface doit être conçue de manière que l’utilisateur comprenne facilement comment interagir avec elle, en utilisant des icônes et des labels clairs et explicites.
L’utilisation de l’interface est claire, notamment grâce aux exemples de prompt, de capacités et de limites de l’outil présentés au début de chaque nouveau chat.
La clarté d’utilisation pourrait toutefois être améliorée avec deux éléments :
L’interface doit être conçue de manière à permettre à l’utilisateur de personnaliser son utilisation de l’outil en fonction de ses besoins et préférences.
L’outil ChatGPT en lui-même est très flexible, étant donné qu’il génère des réponses en fonction des prompts des utilisateurs. Il s’adapte à sa langue et à son niveau de vocabulaire. L’interface, elle, n’offre aucune possibilité de personnalisation à part le Light/Dark mode. Cela peut être lié au fait que ce soit une version Béta. Plusieurs aspects de la plateforme pourraient pourtant être personnalisables, comme la langue et l’accessibilité.
Il est important de prévoir des mécanismes pour gérer les erreurs et les échecs de manière à minimiser leur impact sur l’expérience utilisateur.
Appliqué : Lorsque l’on veut se connecter ou interagir avec ChatGPT mais que le serveur est surchargé, il nous est expliqué pourquoi cela est impossible et il nous est donné la possibilité d’être recontacté par mail lorsque le système sera de nouveau fonctionnel.
Le système identifie certaines questions auxquelles il n’est pas capable de répondre. Dans ce cas, les raisons de cette incapacité sont expliquées et une alternative est proposée à l’utilisateur.
Dans le cas ci-dessus, ChatGPT ne sait pas qui a gagné la dernière coupe du monde. Il m’explique pourquoi et me propose de me référer à une autre source d’information fiable.
S’il y a une erreur du système, la barre de dialogue disparaît et l’utilisateur ne sait pas comment remédier à la situation… En dessous du terme « network error », il pourrait être indiqué la marche à suivre : recharger la page, par exemple.
L’interface doit être conçue de manière à être facile à utiliser, même pour les utilisateurs peu expérimentés.
Le site ChatGPT ressemble à une plateforme de chat classique. Il est donc relativement facile d’utilisation car la plupart des utilisateurs ont déjà fait l’expérience de ce type d’interactions.
L’interface doit être conçue de manière à maintenir la confiance de l’utilisateur dans l’outil et à lui montrer que ses données et sa vie privée sont protégées.
L’interface ne montre pas que la vie privée et les données sont protégées. Au contraire, lors de la première connexion il est explicitement demandé à l’utilisateur de ne pas partager d’informations confidentielles. Dans un sens, cela peut générer de la confiance par la transparence de la démarche.
Cette règle n’est donc pas appliquée parce qu’elle n’est pas pertinente dans tous les cas.
En y réfléchissant, on s’aperçoit que les guidelines de ChatGPT ne sont pas, pour la plupart, spécifiques à des outils fonctionnant avec de l’Intelligence artificielle. Contrôle et révision par l’utilisateur, indications claires et précises, flexibilité et personnalisation, gestion des erreurs et des échecs et facilité d’utilisation sont des reformulations des heuristiques ergonomiques de Bastien et Scapin.
Ces règles ont permis de lister quelques bonnes pratiques du design d’interfaces sans toutefois répondre à ce qui fait la spécificité d’une interface fonctionnant avec de l’intelligence artificielle, et sont l’enjeu principal, la relation homme-algorithme. Le design, est un élément clef dans la définition des interactions entre les utilisateurs et leur outil. Lorsque l’outil est un modèle d’intelligence artificielle (avec de nouvelles capacités et la possibilité d’évoluer dans le temps et face au contexte), le design s’en voit impacté. À partir de là, de nouvelles questions peuvent se poser : comment les systèmes (humain et algorithme) vont-ils communiquer ? Jusqu’où iront leurs actions respectives ? Comment vont-ils collaborer ? Comment vont-ils évoluer ensemble ?
Dans cette optique, j’ajouterais ainsi les règles suivantes à celles mentionnées, lesquelles sont d’ailleurs appliquées par l’interface ChatGPT :
Se prémunir contre l’excès de confiance peut aussi se faire en indiquant un niveau de confiance dans les résultats de l’algorithme, comme le fait Netflix pour ses recommandations. D’ailleurs, comment définir un niveau de confiance dans la reco alors même que celle-ci dépend du corpus initial qui a servi à le poser ?
Enfin, si ChatGPT ne peut pas nous apporter la vérité absolue sur les bonnes pratiques de design d’un outil fonctionnant avec de l’IA, il peut nous apporter une grande aide dans notre quotidien de designer. ChatGPT peut être très utile sur certaines tâches peu critiques de notre métier comme le benchmarking, la rédaction de textes pour des maquettes ou encore la recherche d’inspiration produit. Nous n’avons pas fini d’explorer.
[1] Rdv sur les plateformes de podcast pour découvrir l’épisode de AIE et Julien Laugel sur GPT-3:
▶️ Le Poste Général : https://bit.ly/2Pq9HLt
▶️ Apple Podcasts : https://apple.co/2HxvGq7
▶️ Spotify : https://spoti.fi/2RQ4StL
▶️ Deezer : https://bit.ly/30J8xgn
[2] Comme on lit un prompteur, le prompt est le bout de texte qui passe par le modèle d’IA pour générer un résultat que l’on appellera output
[3] Comme on lit un prompteur, le prompt est le bout de texte qui passe par le modèle d’IA pour générer un résultat que l’on appellera output
[4] GPT1,2,3, et “instructGPT”, qui est le process qui explique comment chatGPT a été fine tune
Moi et mes amis devices sommes très différents, vous savez pourquoi ? J’entretiens moi aussi un lien très fort avec mon utilisateur, mais contrairement à eux, mon utilisateur doit éviter de me regarder et de me toucher. Et oui, mon utilisateur est occupé à autre chose, il conduit. Et mon rôle est de lui faciliter […]
Lire la suite de Dans la peau d’une interface véhiculeUn Design System permet le partage de toutes les briques visuelles nécessaires à la conception d’applications. Il prend la forme d’une documentation en ligne, répertoriant tous les composants graphiques, des différentes variantes de boutons jusqu’aux champs de formulaire, par exemple.
Cette documentation fournira également toutes les bonnes pratiques pour leur mise en œuvre sur une interface. Il peut donc s’agir de recommandations sur l’expérience utilisateur, le ton de la voix, l’image de marque, etc.
C’est la partie émergée de l’iceberg. Pour la partie immergée, cela représente l’accès à tous ces composants réutilisables dans les outils des designers (Figma, Sketch, etc.) et ces mêmes composants codés dans le langage des développeurs (Angular, React, etc.).
Les utilisateurs de cet outil sont donc multiples : Designers, Développeurs, Product Owners, Responsables marketing… et aussi bien en interne qu’en externe pour tous les prestataires ou partenaires qui ont besoin d’accéder à ces ressources.
Les bénéfices d’un Design System sont variés :
Gagner en homogénéité – pour avoir une cohérence dans toutes les différentes applications d’une même entité.
Accélérer la production – grâce à des composants standardisés et réutilisables.
Améliorer la transmission – par une source unique de vérité, accessible par toutes les typologies d’utilisateurs.
De nombreuses entités disposent désormais de leur Design System, que ce soit les GAFAM (Google, Apple, Facebook, Amazon et Microsoft), avec l’un des plus connus – le Material Design de Google ; des entreprises et start-ups de divers secteurs, comme l’assurance ou la banque (ex. BPCE, MAIF) ; ou encore des services publics (ex. France, UK).
Chez ekino, nous avons mené de nombreux projets concernant les Design System.
Nous avons recommandé la création de Design System à certains de nos clients, notamment pour les aider à accélérer leur capacité de production lorsqu’ils commençaient à avoir plusieurs applications à gérer.
Tout comme nous avons également repris des Design System existants qui n’étaient plus alimentés – qu’il fallait faire revivre et pour lesquels il fallait concevoir un processus de maintenance adapté.
Une fois plongé dans ce travail, il y a de nombreux défis à relever, la conception et la maintenance d’un Design System étant souvent bien trop sous-estimées.
Les principaux défis à relever sont les suivants :
Si ces facteurs ne sont pas prévus dès le départ, le résultat est souvent un Design System incomplet, non utilisé, non alimenté, et mourant.
On peut considérer le Design System comme un organisme vivant, qui a besoin d’être nourri et choyé pour pouvoir nous rendre service. Il doit grandir, devenir de plus en éduqué et intelligent, et ainsi devenir un compagnon précieux pour tous.
Pour qu’un Design System soit en bonne santé, il est donc intéressant de le monitorer et de s’assurer qu’il est performant, utile et apprécié. Pour cela, des indicateurs de suivi doivent être mis en place dès le début de sa conception ou de sa reprise.
Voici les 3 grandes familles d’indicateurs que nous conseillons de mesurer et suivre :
Trop souvent, les indicateurs qui sont suivis sont liés à sa performance, mais il est aussi important de suivre son adoption de très près. Nous avons pu lancer ou participer à des conceptions de Design System qui n’ont malheureusement pas eu le succès attendu parce que l’adoption a été négligée. Il s’agit désormais d’un facteur essentiel pour nous. Pour cela, il faut suivre sa consommation et la satisfaction des utilisateurs dès que possible.
Cela permet notamment de détecter si des composants n’ont d’intérêt pour personne. Peut-être sont-ils inutiles, auquel cas ils peuvent être retirés du Design System pour éviter des coûts de maintenance. Ou peut-être présentent-ils des défauts qui doivent être connus afin de pouvoir les refaire.
Un Design System doit être aussi universel que possible, ce qui est parfois compliqué car les applications peuvent avoir des usages très différents (applications métiers internes, site internet grand public, application mobile, etc.) Si certaines applications ne l’utilisent pas, c’est peut-être parce qu’il ne leur est pas adapté.
Il y a alors de fortes chances que des composants propres soient créés pour ces applications en dehors du Design System; des composants cachés qui pourraient pourtant être utiles à d’autres applications.
Par manque de temps, de budget ou encore de communication, les composants réalisés par les designers peuvent différer des composants développés une fois en production. Il en résulte un manque de cohérence dans les interfaces. Si le Design System est adopté par toutes les équipes, cela se reflétera dans les interfaces par la cohérence entre le design et le développement.
Le Design System peut être un outil formidable pour la communication interne d’une organisation. Un Design System mature peut notamment contenir les guidelines de la marque et permettre le téléchargement rapide de ressources (template PowerPoint, signature mail…). En s’y rendant pour consulter ces éléments, des collaborateurs non techniques peuvent facilement consulter le contenu.
De plus, en découvrant les différents guidelines de conception des interfaces et en les rendant accessibles, cela peut contribuer à une meilleure compréhension des métiers du design et du développement.
Il est possible de mettre en place un tracking des composants, que ce soit sur les outils des designers comme sur Figma, ou mettre des tags directement sur les applications en production.
Exemples d’indicateurs à suivre :
Il est essentiel de compléter cette analyse par une enquête de satisfaction quantitative et surtout qualitative.
Il faut s’assurer que le Design System répond aux attentes des utilisateurs. Qu’il serve d’outil leur permettant de faciliter leur travail et de se concentrer sur l’expérience utilisateur en supprimant les tâches de production les plus élémentaires et les moins intéressantes.
Nous avons parfois eu des retours d’utilisateurs qui étaient frustrés d’utiliser des éléments standardisés et se sentaient bridés dans leur créativité. Il y a alors un risque qu’ils essaient de passer outre l’utilisation des composants du Design System et de créer les leurs. D’où l’importance de les faire contribuer au Design System et de les consulter régulièrement lors des enquêtes de satisfaction.
Dans le cas où les designers et les développeurs d’un produit doivent demander la conception d’un composant à une autre équipe, souvent entièrement dédiée au Design System, ils sont alors dépendants de celle-ci. Et si elle ne respecte pas la demande et les délais demandés, ils risquent également de se passer de ses services.
Par des entretiens réguliers avec les utilisateurs, et l’envoi d’enquêtes de satisfaction.
Exemple d’indicateur à suivre :
Il faut s’assurer que le Design System évolue constamment pour alimenter les différents besoins des équipes, il est donc également important de suivre sa construction et sa maintenance.
Un grand nombre de nouveaux composants créés est le signe d’un Design System vivant. Toutefois, cela doit être considéré au regard des chiffres sur sa consommation, car il pourrait y avoir des créations de composants inutiles.
Quand on parle de composant, il y a le composant “graphique” le composant qui sera utilisé par les designers dans leurs outils de conception (Figma, Sketch…) et la version “développée” pour les développeurs potentiellement déclinée en plusieurs technologies (React, Angular…). Bien entendu, les deux doivent être conçus et disposer de la documentation associée appropriée. Ce sont là des prérequis pour être sûr que le composant sera pleinement utilisé.
Suivre les contributions est également un bon indicateur pour évaluer son adoption, il semblerait suspect qu’il n’y ait aucune demande de contribution même devant une librairie de composant assez complète.
Plus il est facile de mettre à jour le Design System, plus de nouveaux composants seront ajoutés. Un process clair et défini au lancement du Design System permettra son bon développement.
Évidemment, c’est à pondérer selon la maturité du Design System. Il est normal de recenser au début un certain nombre de bugs, il faut surveiller que ce nombre soit en baisse et que les temps de traitement se raccourcissent.
Les équipes consommant le Design System doivent pouvoir facilement joindre les équipes chargées de sa réalisation. Cela permet aux utilisateurs du Design System de poser des questions, mais cela permet également au concepteur du Design System de communiquer sur son évolution.
Un tracking comme celui existant dans Figma peut déjà permettre de suivre l’évolution du nombre de composants. Mais il est également important de mettre en place un board de suivi.
Comme un Design System est outil interne qui évolue constamment, il peut avoir son propre backlog dédié – un ticket par composant à concevoir et à implémenter en mode agile, sprint après sprint. Le suivi peut donc s’effectuer dans Jira par exemple, en suivant les composants de la phase de demande, puis création, développement, test, documentation et enfin livraison.
Un board dédié au suivi et à la résolution des bugs se révélera également utile. Cela permettra d’évaluer facilement le temps de production des composants, ainsi que le nombre de bugs associés.
Exemples d’indicateurs à suivre :
Le principal avantage d’un Design System est de réduire les coûts de production afin que les designers et les développeurs puissent réutiliser des composants standardisés sans avoir à les créer de toutes pièces.
Toutefois, comme l’implémentation d’un Design System représente un coût important en soi, avec potentiellement une équipe entière dédiée à la maintenance de l’outil, il faut pouvoir justifier cet investissement en démontrant les économies réalisées en contrepartie de la production.
Il convient d’en faire l’estimation dès le départ, ce qui aidera à persuader les décisionnaires de se lancer dans un Design System. Puis, continuer à suivre les temps de productions à mesure que le Design System se complète.
La conception d’un Design System est l’occasion de réduire la dette graphique et technique potentiellement accumulée, et donc de réduire les bugs techniques, liés par exemple à une technologie devenue obsolète et difficile à maintenir.
Former un nouveau membre à un Design System est facilité puisque les ressources sont centralisées en un seul endroit avec la documentation associée permettant de le guider.
Un Design System permet l’utilisation rapide de composants “graphiques” et “développés”, et devrait par conséquent faciliter la conception de MVPs. Le lancement de nouveaux MVPs peut donc être un signe de performance du Design System.
Il faut comparer les temps passés sans et avec un Design System. Par exemple, le temps passé sur un écran pour concevoir ses composants de toutes pièces par rapport au temps passé sur le même écran avec des composants déjà conçus disponibles.
Bien sûr, cette comparaison est un peu simpliste, mais elle permet de mettre clairement en évidence les avantages qu’un Design System peut apporter.
Lors de l’utilisation du Design System, il faudra évaluer le temps de production pour chaque écran selon leur complexité. De l’écran basique qui comprend des composants simples à l’écran plus complexe qui est composé de composants nécessitant des évolutions.
Exemples d’indicateurs à suivre :
Lors de nos différentes interventions sur des Design Systems, nous avons pu constater à quel point les contextes pouvaient être différents. Est-ce un Design System utilisé par de nombreuses applications ? Par différents types d’utilisateurs finaux ? Développé dans plusieurs technologies ? Utilisé pour différents devices ?
Les réponses à ce type de questions peuvent donc orienter le type d’indicateurs à suivre.
Au lancement d’un Design System, il faut bien comprendre le contexte, les utilisateurs concernés et leurs besoins afin de déterminer les indicateurs pertinents en conséquence.
Quel que soit le contexte, selon notre expérience, la mesure de l’adoption reste une nécessité. Comme nous avons pu le voir dans cet article, cette mesure peut prendre différents formats, à adapter selon le contexte. Cependant, il faut mettre tous les moyens en œuvre dès le départ pour concevoir un système qui sera utile à tous et de veiller à ce qu’il le reste tout au long de sa durée de vie.
Le lien entre designers et ingénieur.es Bien que les designers et les ingénieur.es puissent sembler appartenir à deux mondes opposés, ils partagent au fond un objectif commun très concret : faire ce qu’il y a de mieux pour l’utilisateur. Ce qui les différencie, c’est avant tout leur vision, la manière dont ils envisagent et abordent […]
Lire la suite de Comment améliorer la collaboration entre designers et ingénieur.es ?Aujourd’hui, le design thinking est une méthode de résolution de problèmes centrée sur l’utilisateur, et principalement mise en œuvre par les spécialistes du design en collaboration avec des équipes pluridisciplinaires. Sa finalité est de trouver des solutions aux services et processus inefficaces, aux produits ou systèmes numériques mal conçus.
En d’autres termes, le design thinking place l’utilisateur au centre de l’attention, en promouvant différentes méthodes de compréhension de ses besoins, d’empathie avec son contexte ethnographique, son comportement, sa façon de penser, ses motivations et ses habitudes. Tout cela afin de développer des innovations ou des améliorations de son point de vue, et non en fonction de ce que l’entreprise souhaite commercialiser auprès de ses clients.
Le processus de design thinking est intuitif et universel. Il peut être adopté par n’importe quelle discipline, rôle ou organisation, avec le conseil et le soutien d’un designer de services ou d’expériences. Cependant, il requiert de l’empathie, une bonne écoute et des capacités d’observation.
Il existe différents modèles de design thinking, tels que le double diamant, le modèle IDEO, le design thinking d’IBM et d’autres, lesquels sont utilisés par divers secteurs industriels et types d’organisations pour stimuler la stratégie, l’innovation et l’amélioration continue.
S’il existe de nombreuses subtilités et nuances dans la méthodologie appliquée en fonction du projet, tous les modèles sont unis par ces mêmes principes clés de l’approche du design thinking centré sur l’utilisateur :
Découvrir & définir : commencer par l’utilisateur et ses besoins
Appliquer le processus de questionnement, observer l’utilisateur dans son environnement réel, souligner, recueillir ses besoins et ses problèmes. Utiliser la pensée analytique pour générer des énoncés de problèmes. Examiner les éventuels problèmes à traiter, et ceux qui ont le plus d’impact sur l’expérience.
Développer : appliquer le processus de co-création
Redéfinir un processus ou un service existant – ou en créer un nouveau – en abordant les points de douleur des utilisateurs et les convertir en opportunités. Discuter et concevoir chaque point de contact conjointement avec les utilisateurs : les points de contact qui ont un impact direct sur l’utilisateur et ceux qui se passent en coulisses.
Délivrer – Prototyper les idées, tester et améliorer
Construire des prototypes grossiers de vos idées, les mettre en pratique et les tester auprès des utilisateurs. Affiner les idées en recueillant et en analysant les réactions et en poursuivant l’expérience jusqu’à ce que le résultat soit satisfaisant.
Le processus de design thinking suggère une amélioration continue. Ses résultats doivent donc être mesurés en permanence.
La section suivante présente quelques cas d’utilisation sélectionnés parmi divers secteurs d’activité (santé, finance et mobilité) impactés par la pandémie. Ces cas d’utilisation spécifiques démontrent l’application du design thinking et les avantages qui en découlent, tels que l’amélioration de la satisfaction des clients, l’efficacité des processus ou la création d’une image de marque innovante.
La sécurité des patients et du personnel, la réduction des risques et l’efficacité opérationnelle sont des enjeux majeurs lorsqu’il s’agit de contrôler la propagation des infections, surtout en cas de pandémie. Toutefois, il est difficile de mesurer l’hygiène et de permettre au personnel de contrôler et de promouvoir les bonnes pratiques de désinfection, faute de données fiables au sein de l’hôpital.
À cet égard, SwipeSense est un excellent exemple de service conçu pour lutter contre la propagation des infections. En collaboration avec IDEO, le prototype physique et l’expérience utilisateur numérique ont été développés en utilisant le design thinking.
Lorsqu’il s’agit de l’adoption d’un nouveau service – en l’occurrence un outil numérique et physique par le personnel hospitalier – il peut s’avérer difficile de modifier des comportements ancrés.
En analysant soigneusement les différents comportements au sein de l’hôpital, les processus adoptés et les habitudes, tout en collectant des millions de données, la solution développée par SwipeSense apporte des informations substantielles pour induire des changements de comportement mesurables et durables.
SwipeSense est un simple réseau de capteurs hébergés dans le cloud qui capte les habitudes sanitaires individuelles afin de monitorer l’hôpital, ses différents départements, unités et le personnel. Les habitudes sanitaires sont recueillies à l’aide de capteurs individuels via le badge qui se connecte aux distributeurs et qui transmet ensuite les informations à une unité située dans des zones centrales telles que les postes infirmiers.
Ainsi, la startup a réussi à créer un produit non perturbateur qui ne demande qu’un effort minimal en matière de changement de comportement.
Il permet au responsable de service ou d’unité de suivre le processus, de mettre en place des indicateurs de performance clés pour son personnel et de promouvoir une amélioration continue afin de limiter la propagation des infections au sein de l’hôpital.
Résultat : le service SwipeSense a été testé pendant 12 semaines dans l’hôpital et a produit des résultats remarquables : 64% d’augmentation de l’hygiène des mains.
Les pays du monde entier se dirigent actuellement vers des sociétés sans espèces, mais la plus grande accélération s’est produite depuis la pandémie de COVID, en raison de la distanciation sociale, des paiements sans contact, de la popularité croissante du e-commerce, etc.
En ce qui concerne l’adoption des technologies « cashless », tous les pays n’avancent malheureusement pas au même rythme, et ce même si les paiements numériques sont disponibles sur tout le territoire.
Hong Kong est l’un des pays où la population préfère encore payer en espèces, notamment en raison des difficultés à se payer les uns les autres sans argent liquide, mais aussi pour des raisons culturelles. Ce sont quelques-uns des problèmes identifiés par la plus grande banque de Hong Kong – HSBC, lesquels ont inspiré le développement d’une nouvelle application mobile.
La solution qui a été développée pour relever ce défi s’appelle PayMe, une application de paiement mobile qui permet aux utilisateurs de se transférer de l’argent via leur numéro de téléphone.
Elle présente un moyen pratique de se payer mutuellement en enregistrant simplement un numéro de téléphone et en y associant un compte bancaire. Les utilisateurs peuvent notamment recharger leur solde et faire des demandes de paiement après une soirée entre amis, par exemple, pour partager les frais.
Ces fonctionnalités ont été identifiées lors de la phase d’exploration des besoins utilisateurs, tandis que le processus simplifié d’exécution de ces tâches a été conçu au fil de nombreuses sessions de cocréation avec les utilisateurs.
Le succès de l’application PayMe est dû à l’approche design thinking appliquée tout au long du développement du produit, laquelle a impliqué la collaboration des utilisateurs cibles, des designers, des commerçants et des développeurs. Les besoins de l’utilisateur cible et le feedback continu sont ainsi restés au centre de la conception du produit.
Résultat : l’application a été lancée en 2017 et est devenue l’une des applications de paiement les plus populaires chez les jeunes à Hong Kong. Elle a déjà gagné un quart de la population de la ville.
Ces dernières années, la mobilité a radicalement changé. Ce phénomène se constate tout particulièrement dans les villes et dans le contexte de la pandémie, où les voyageurs se sont tournés vers des modes de transport individuels pour éviter de s’exposer au risque d’infection.
Outre les modes de transport existants (bus, métro, train et taxis), on voit apparaître des scooters, des vélos électriques, des motos, des voitures partagées, etc. Dans de nombreux cas, ces modes de transport sont gérés par différents prestataires de services, ce qui signifie que les utilisateurs paient ces services séparément. Cette situation est source de désagréments et parfois d’incohérences lorsque d’anciens modes de paiement – billets papier, cartes de voyage, etc. – et de nouveaux modes de paiement sont utilisés sur un même trajet.
L’innovation technologique d’Hitachi en matière de billetterie intelligente est un bon exemple de solution à ce problème. Elle témoigne d’une excellente approche en matière de design thinking pour créer un nouveau service innovant à partir de zéro.
Le parcours utilisateur présenté ci-dessous illustre la technologie de billetterie intelligente unique d’Hitachi du point de vue de l’utilisateur, en passant par l’utilisation de la technologie depuis le téléchargement initial et l’enregistrement, l’utilisation de l’application pendant le trajet multimodal et le calcul automatique du tarif à la sortie.
Là encore, l’approche du design thinking joue un rôle important, en étudiant les différents types de voyageurs, leurs déplacements et leurs besoins, et en identifiant les points de douleur liés au paiement de transports multimodaux.
Comme nous l’avons vu dans le premier article, notre société fait actuellement face à une nouvelle norme : vivre avec une pandémie en adoptant de nouvelles stratégies pour relever les défis auxquels sont confrontés nos systèmes de santé. Le Covid n’ayant pas encore disparu, nous devons adapter des stratégies d’amélioration continue pour faire face à un avenir imprévisible.
Les principaux défis auxquels le système de santé est confronté durant les premières phases de pandémie, et connus à ce jour, sont les suivants :
En appliquant la méthode du design thinking, ces défis mondiaux du secteur de la santé pourraient être transformés en opportunités.
Par exemple, le manque de ressources sanitaires (personnel, équipement et espace) pourrait être comblé en identifiant de nouvelles méthodes d’éducation, en formant les individus aux activités de soins de santé. On pourrait également envisager la co-conception de nouveaux équipements mobiles et d’espaces flexibles pouvant être facilement transformés selon les besoins.
Un autre enjeu notable est celui des soins préventifs – qui pourraient être abordés sur le lieu de travail par différentes organisations pour éviter la surcharge des hôpitaux.
Ce ne sont là que quelques idées qui, grâce au pouvoir du processus de design thinking, pourraient encourager la co-idéation, la co-création, puis le co-développement et les tests afin de trouver de nouvelles solutions.
Le smartphone, une simple machine à écrire ? Au moment où j’écris ces lignes, je me trouve dans un pays en proie à la répression et le gouvernement vient de décider de couper Internet, dans tout le pays, « pour la sécurité du peuple » … Et voilà, mon smartphone est réduit à une simple […]
Lire la suite de (In)accessibilité des services hors connexionRetrouvez la version originale de l’article de Think Design en anglais : How to create personas driven by data ?
Dans cet article, nous nous penchons sur le rôle de la data comme puissant levier dans le processus de création de persona. À mesure que nous améliorons la connaissance et la compréhension de nos clients, cela permet d’enrichir les produits et services et d’améliorer leur ergonomie.
Les personas ont pour but de vous aider à mieux comprendre vos utilisateurs, leurs besoins, leurs comportements et leurs attentes. Il s’agit d’archétypes représentatifs de traits spécifiques et propres à votre cible.
1. Le persona comme hypothèse : un profil qui caractérise un groupe d’utilisateurs hypothétiques.
2. La persona comme synthèse : Grâce à la recherche primaire, et une fois que vous avez compris vos utilisateurs, vous êtes dès lors en mesure d’envisager des catégories d’utilisateurs basées sur différents types de comportement.
3. Le persona comme segment utilisateur.
La description d’un persona doit inclure, sans s’y limiter : l’éducation, le mode de vie, les intérêts, les valeurs, les objectifs, les besoins, les comportements, les attitudes et tous autres éléments distinctifs récurrents.
Bien que riches en données comportementales et d’interactions, ces personas représentent un instantané dans le temps. Au premier abord, cela devrait être suffisant pour vous permettre de démarrer et résoudre des problèmes d’ergonomie. Toutefois, sont-ils véritablement pertinents à terme ?
Les personas les plus efficaces ne se contentent pas de décrire les utilisateurs, mais aident à prévoir leur comportement. Bien entendu, pour que les personas puissent permettre ce genre de prédictions, ils doivent reposer sur plus que des intuitions et des anecdotes.
Pour répondre à ce besoin, il est donc impératif d’adopter une approche centrée sur la donnée dans leur conception.
Facebook, en enquêtant sur des plaintes anonymes, a créé un persona pour ses plaignants. Grâce à ses données sur les utilisateurs, la société a constaté que parmi les adolescents qui se sont plaints d’une photo sur laquelle ils étaient identifiés, la plupart étaient gênés par le fait qu’ils aient été identifiés.
Dans ce cas de figure, la proportion de filles gênées par la publication était plus élevée que celle des garçons. Par ailleurs, Facebook a également pu observer que ses utilisateurs étaient plus susceptibles de partager le problème plutôt que de le signaler. Une enquête plus approfondie a finalement révélé que si ces derniers n’ont pas signalé la publication, c’est avant tout parce qu’ils ne voulaient pas que leurs amis s’inquiètent.
En recueillant des informations clés sur l’âge, le sexe, le comportement, les points de friction et les motivations de ses plaignants, Facebook a pu améliorer son système de signalement et de support client.
De même, Netflix alimente son algorithme de recommandation de contenu avec des données déclaratives fournies par les abonnés ainsi qu’une très large quantité de données comportementales et d’interaction. L’entreprise américaine utilise également ces données pour rationaliser son interface utilisateur.
Le problème de nombreux personas est qu’ils sont basés sur des données non pertinentes, des données mal sourcées, voire aucune donnée (mais des hypothèses dans le cadre d’utilisateurs fictifs).
La première étape consiste à identifier les éléments clés à l’origine de la majorité des conversions de votre entreprise, car l’identification de ces éléments vous aidera à identifier votre cible principale.
Connaître son cœur de cible nous permet d’extraire des données précieuses.
1. À la fois des données qui peuvent être collectées par le biais de recherches utilisateur.
2. Et des données quantitatives obtenues via le suivi d’interactions contextuelles de votre cible avec vos produits ou services.
La conjugaison d’actions utilisateurs, dans un laps de temps continu, avec les éléments qui influencent leurs interactions (motivations, données démographiques, etc.), nous permet de prédire le comportement utilisateur avec plus de précision face à d’éventuels changements apportés aux produits ou services.
Pour comprendre les motivations, les attitudes, les comportements et les attentes de nos clients, il faut s’appuyer sur de multiples sources de données. La diversité des sources de données permet de dresser un tableau complet d’un segment de consommateurs. C’est ainsi que l’on peut suivre leurs interactions, leur niveau d’engagement, et leur parcours au fil du temps au travers de différents points de contact.
a. Les sondages de sortie, les questionnaires en ligne, et les sondages d’opinion
Les enquêtes de sortie de site sont conçues de manière à ce qu’une seule question apparaisse sur votre site à un moment donné. Les questions posées dépendent ensuite de l’objectif visé.
Voulez-vous savoir si votre site ou vos produits/services répondent aux besoins de vos clients ? Ou voulez-vous comprendre les sources de friction qui empêchent les clients de s’engager ou d’acheter ?
Ces questions peuvent apporter des informations précieuses sur ce qui fonctionne et ce qui fait obstacle à l’engagement.
b. Données Web analytics et des systèmes CRM
Les données Web Analytics peuvent révéler le comportement d’utilisateurs clés sur votre site.
Les informations de Google Analytics sur vos segments, par exemple, peuvent être utilisées pour créer des listes reposant sur des données démographiques telles que l’âge, le sexe, la langue de l’utilisateur, la localisation et le stade dans votre funnel d’achat. Outre les analyses basées sur une dimension primaire (comme l’âge), il est également possible d’ajouter une dimension auxiliaire (comme l’affinité) afin de mieux comprendre les comportements correspondant à l’âge sélectionné. Il est également possible de filtrer par langue et par lieu afin de savoir d’où dans le monde notre public nous rend visite.
c. Données réseaux sociaux
La popularité des plateformes de réseaux sociaux offre de nombreuses possibilités en matière de collecte d’informations, notamment sur les intérêts, les goûts et les interactions de vos utilisateurs. Étant donné que les données fournies par les plateformes de social analytics (e.g. YouTube Analytics, Google Analytics, Linkedin Analytics, Facebook Insights) sont toujours agrégées à un niveau groupe, elles ne fournissent pas d’informations sur les utilisateurs individuels de ces plateformes. L’utilisation de ces données agrégées implique uniquement l’utilisation d’informations qui ne sont pas identifiables à un individu particulier.
Après avoir collecté nos données, il nous faut les relier et les unifier de la même manière qu’avec une plateforme de données clients. La méthode à suivre serait de faire passer les différentes sources de données à travers un filtre commun à même de les traiter sous un même format.
En utilisant ces informations, combinées avec des données qualitatives issues de recherches utilisateur, nous pourrons ensuite construire nos personas. Ces personas axés sur les données vont alors progressivement prendre en compte les interactions et comportements utilisateur dans leur conception et selon de nouvelles évolutions. Cela garantit la création de nouveaux produits, services ou contenus issus de comportements client réels et consolidés.
Si un persona reflète la perspective d’un utilisateur et de son état d’esprit à un moment donné, il prend tout son sens grâce à la combinaison de contextes, d’événements déclenchés et de comportements utilisateurs. Cela crée alors des possibilités de versions multiples de personas, qui naissent et évoluent en fonction de tout changement dans cette combinaison.
Grâce à cette approche axée sur les données, il est donc possible de créer des personas en temps réel, à partir d’analyses automatisées et évolutives en provenance de sources multiples. Ces personas sont ensuite automatiquement mis à jour dans un feedback loop de données, et recalculées selon les personas déjà existants.
En traitant les informations à partir de profils utilisateur unifiés, cela permet d’éclairer nos décisions en matière de création de contenu, de gestion de persona, et en vue de futurs projets centrés client. Ce type d’informations unifiées offre alors de nouveaux niveaux d’empathie et de compréhension de vos utilisateurs et personas.
L’intérêt est clair – en offrant à vos clients et utilisateurs un service pertinent et personnalisé, basé sur une compréhension évolutive de leurs besoins, vous augmentez l’engagement, les ventes et la fidélité.
Plus ces personas axés sur les données évoluent, plus ils seront susceptibles de maintenir un produit ou service à jour et donc pertinent aux yeux de vos clients.
Pour toute organisation axée sur les données, le persona classique n’est plus suffisant. Les entreprises prêtes à unifier et enrichir leur compréhension du consommateur bénéficieront de clients plus engagés et réactifs dans les années à venir.
Dans cet article, nous explorerons quelques pistes sur les opportunités d’enrichissement du processus de création et de collecte de données que le design peut offrir afin de recueillir des informations sur les comportements utilisateurs. Ou encore comment les designers de produit peuvent tirer parti de la dynamique phénoménale entre données et design afin de créer […]
Lire la suite de Données et design : aller au-delà du data driven designUn des avantages à mettre en place cette méthode est la possibilité de changer les priorités plus facilement, de pouvoir adapter la roadmap du produit constamment. Ce qui facilite le travail au quotidien des ingénieurs et des consultants. En tant que designer, nous avons besoin d’avoir une autre vision que ces petites briques par sprint, nous voyons la construction dans son ensemble, nous concevons des parcours utilisateurs d’un produit tels qu’ils pourront être dans 6 mois, 1 an, 2 ans…
Ces deux dynamiques assez différentes peuvent représenter un écueil courant rencontré dans cette collaboration Design + Technologie + Agile. Chez ekino, nous menons nos projets avec une vision holistique. Depuis plus de 10 ans, ingénieurs, designers, consultants et data scientists collaborent ensemble pour une gestion plus efficace des projets.
Cet article, sous la forme d’un retour d’expérience, a pour objectif d’aider les designers et les ingénieurs à mieux collaborer ensemble dans un projet Agile. Suivez le guide !
Pour débuter ce retour d’expérience, je dois remonter le temps de quelques années et revenir sur ma découverte de cette fameuse méthode lors de ma première longue mission chez un client en tant qu’UX designer.
Notre client était un assureur qui souhaitait refondre sa principale plateforme client, commune à toutes les branches de l’entreprise à l’international. Le projet avait débuté 2 ans auparavant et la plateforme commençait à être utilisée par ses premiers utilisateurs. Nous étions 4 designers ekino à intégrer cette équipe constituée de quelques internes (product owners et ingénieurs) et une majorité de consultants employés par diverses sociétés.
Même si la méthode Agile n’est pas nouvelle, beaucoup d’entreprises françaises découvrent encore cette méthode de gestion de projet. C’était le cas pour notre client, qui voulait la tester sur ce projet pilote pour ensuite l’étendre à l’ensemble des projets de l’entreprise.
J’ai donc découvert un plateau agile; 15 ingénieurs répartis en 3 squads, chacune avec leur PO, scrum master et designer. Des cérémonies “Sprint planning” “Refinement” “Rétrospective” “Sprint review” ponctuaient nos semaines. Au cours de ces premiers mois, j’ai pu identifier plusieurs problèmes, notamment liés au fait que nous devions répondre aux attentes de deux métiers différents chez notre client, et qu’elles étaient rarement alignées :
Répondre à ces attentes divergentes imposait une répartition de la charge de travail différente des designers et une manière d’aborder les sujets avec des temporalités différentes. Du design très opérationnel d’un côté avec des backlogs contraints et des plannings à respecter, et de l’autre du design plus exploratoire avec des enjeux d’alignement des parties prenantes autour de la vision.
Sans surprise, notre cœur balançait plus du côté des utilisateurs, mais la directive était de suivre à tout prix le backlog produit et gare à ceux qui s’égareraient dans la “recherche utilisateur et des workshops; soit une perte de temps…”. Cela n’empêchait pas le marketing de nous confier les tests utilisateurs, qui venaient dangereusement empiéter sur notre temps normalement complètement dévoué à la production.
La vie quotidienne consistait donc à suivre le backlog sur lequel nous n’avions aucun levier et de préparer les fonctionnalités qui partaient en développement au sprint 01, puis au sprint 02 et ainsi de suite. Nous devions constamment nous adapter aux changements réguliers et aux dé-priorisations des fonctionnalités à venir, ce qui ne facilitait pas notre travail.
Alors que les ingénieurs voyaient leur sprint de façon claire avec une estimation de temps précise via leurs User stories JIRA , nous avions, de notre côté des difficultés à suivre :
Préparer les livrables des fonctionnalités qui étaient à développer pour le prochain sprint, ceux pour les prochains trimestres, etc… les multiples sollicitations des ingénieurs pour la revue de leur travail ; les démos aux divers représentants des pays client de l’application ; et les cérémonies agiles où notre présence était obligatoire, alors que n’avions parfois pas plus d’utilité qu’une plante verte…
Après ce premier temps d’adaptation et de découverte du projet, les challenges à relever étaient maintenant plus clairs pour moi :
Donner une vraie visibilité sur notre charge de travail à la direction produit et aux POs.
Pouvoir aligner les différentes parties prenantes sur nos priorités.
Avoir une meilleure collaboration avec les ingénieurs.
Améliorer notre répartition des sujets, notre communication entre designers.
Pouvoir s’aligner avec le backlog des features et …cerise sur le gâteau…
Avoir une influence sur la stratégie du produit.
Venant d’une agence qui fait collaborer différents métiers depuis des années, j’avais l’avantage de l’expérience, et je comptais bien m’appuyer sur cette vision holistique pour relever les différents challenges de ce projet.
Avec l’objectif global d’avoir une meilleure intégration au sein de l’équipe, il était évident d’utiliser l’outil commun, celui qui permettait à toute l’équipe de voir en temps réel l’état d’avancement d’un sprint de développement : JIRA.
À la seule évocation de cet outil, les poils se dressent sur nombre de mes confrères designers. Mais l’adopter offrait des avantages : notre charge de travail serait visible par tous les membres de l’équipe, Scrum Masters, POs, ingénieurs et direction du produit. Et ils ne feraient aucune difficulté pour le consulter puisque c’était leur outil quotidien.
Pour cela, nous avons adapté l’outil à nos besoins. En changeant par exemple les labels qui était purement à destination des ingénieurs pour des labels qui nous correspondaient. Son adoption n’a donc pas été si difficile pour les designers, et nous n’avons pu nous en passer par la suite.
Ce tableau JIRA spécial design était partagé chaque semaine en point hebdomadaire avec les POs et en daily de chaque squad. Les POs avaient donc une visibilité complète de notre charge de travail. Les ingénieurs pouvaient suivre notre avancée et s’apercevoir du nombre d’étapes de validation auxquels nos livrables étaient soumis, et comprendre tout le travail fourni sur ces fonctionnalités avant d’arriver dans leur propre JIRA.
Challenges relevés :
Donner une vraie visibilité sur notre charge de travail à la direction du produit et aux POs.
Avoir une meilleure collaboration avec les ingénieurs.
Pour alimenter et gérer ce tableau JIRA, nous avions notre propre design planning. Nous avons repris quelques méthodes utilisées en sprint planning par les ingénieurs et nous les avons encore une fois adaptées aux besoins des designers.
Nous calculions notre “capacité” de chaque sprint en enlevant les temps de congés, des points internes agence, des cérémonies agiles et de suivi de la production.
Nous déduisions nos tâches du sprint en fonction des prévisions des sprints de développement et d’un point d’alignement avec le PO de chaque squad. En plus des tâches liées à la production, nous avions distingué les tâches relevant des demandes du marketing et de la gestion de notre Design system.
Nous évaluions notre charge de travail par heure travaillée en veillant à ne pas dépasser notre capacité totale.
En milieu de sprint nous faisions un point sur notre avancement afin de nous organiser pour respecter les délais impartis. Comme nous étions souvent en binôme sur une fonctionnalité (un UX designer + un UI designer), nous pouvions aisément voir l’avancement du travail de notre binôme en suivant ses tickets JIRA.
Et enfin, nous avons adapté le format des rétrospectives de sprint aux besoins des designers. Ces points trimestriels étaient l’occasion de revenir sur notre façon de collaborer, de soulever des problèmes et de trouver des solutions tous ensemble pour y remédier.
Challenges relevés :
Améliorer notre répartition des sujets
Améliorer notre communication entre designers.
Ce point hebdomadaire avait pour objectif initial de passer en revue les écrans devant les POs, le PM et le Marketing, les ingénieurs étant également les bienvenus. Il a permis d’améliorer l’alignement entre les parties; notamment en statuant sur certaines priorités du backlog. D’autres instances de travail les réunissaient, mais sans les designers et sans avoir les propositions d’expérience utilisateurs sous les yeux.
Nous pouvions désormais avoir une validation commune de notre travail et de nos priorités, éliminer les allers et retours superflus et atténuer cette sensation constante de tiraillement vers des objectifs différents. Et le compte rendu envoyé après chaque design review permettait d’acter noir sur blanc les décisions prises.
La dernière validation consistait pour les designers à montrer les écrans aux représentants de chaque pays offrant l’application à ses clients. Nous profitions de la sprint review où ils étaient présents pour leur exposer notre travail à la suite de la démonstration des développements.
Challenge relevé :
Pouvoir aligner les différentes parties prenantes sur nos priorités
Chaque trimestre commençait par un “Big room”; une journée entière où étaient réunis l’ensemble des acteurs du projet, équipes de développement, partenaires fournisseurs de données (API)…
Pendant cette journée, il y avait une réunion par fonctionnalité, l’occasion de montrer les parcours utilisateurs imaginés qui allaient prendre enfin forme durant le trimestre. Et le backlog des fonctionnalités du trimestre était retravaillé en fonction des discussions émanant de ces réunions et des dates de livraisons des API.
Le backlog comprenait une ligne par équipe de développement sans se soucier du calendrier des designers, et de leur capacité ou non de pouvoir délivrer les écrans terminés et validés par les parties prenantes. Nous avons donc ajouté notre propre ligne, une manière de signaler haut et fort que les développements étaient dépendants du travail des designers, et de nous rendre plus visibles auprès de tous. Nous avions donc désormais un planning prévisionnel de tout ce que nous devions livrer sur un trimestre :
En parallèle des livrables à fournir durant le trimestre (en suivant ce planning), nous avons mené un travail de fond de notre propre initiative. Nous réfléchissions à des améliorations globales de l’application, en nous affranchissant de la roadmap du produit. Ces améliorations étaient souvent inspirées par des retours utilisateurs que nous avions depuis l’application ou depuis de grandes enquêtes de satisfaction qui étaient menées régulièrement.
Nous organisons ensuite des présentations aux parties prenantes, marketing et représentants des pays afin de leur proposer nos idées. Une d’entre elles a ainsi réussi à intégrer le backlog produit.
Challenges relevés :
Pouvoir s’aligner avec le backlog des features.
Avoir une influence sur la stratégie du produit.
Nous avons su tirer de nombreux bénéfices de la pratique de la méthode agile. Cependant, pour améliorer notre collaboration avec les ingénieurs du projet, nous voulions aussi les faire rentrer dans notre propre univers. Je voulais me servir de mon expérience acquise chez ekino pour faire évoluer la vision globale du projet, et transmettre cette approche globale que nous mettons en place depuis la création de l’agence.
J’ai donc animé une session de sensibilisation au Design thinking. Cela a eu le mérite d’ouvrir le débat et d’envisager l’intégration d’outils dans le travail quotidien des équipes de design et de développement. Le client s’est rendu compte que ses ingénieurs ressentaient également le besoin d’avoir des contacts plus directs avec les utilisateurs finaux, afin de connaître davantage les conséquences de leur travail. Nous les avons donc sollicités lors de la rédaction d’un de nos questionnaires de satisfaction.
Certains ingénieurs et les POs avaient également une réelle envie de ce travail collaboratif, et de pouvoir être embarqués dès les premières réflexions sur les fonctionnalités à venir. L’idée était donc de faire davantage de workshops en réunissant, PO, marketing, API, ingénieurs et designers.
Challenges relevés :
Avoir une meilleure collaboration avec les ingénieurs.
Avoir une influence sur la stratégie du produit.
Ce choix d’embrasser la méthode, et de faire collaborer différents métiers en les faisant travailler sur les mêmes outils a clairement porté ses fruits.
Les outils de l’agilité ont été inspirants et peuvent réellement apporter de l’intérêt dans n’importe quelle organisation d’équipe et pas seulement pour le développement. Cela permet aux designers d’être directement intégrés dans le flux de production du produit, de gagner plus rapidement la confiance des POs et de mieux communiquer avec les ingénieurs.
Il est aussi important d’avoir du recul sur la production et de garder cette vision à plus long terme pour penser les expériences et surtout préparer celles qui viendront dans le futur.
Et pour cela, il faut continuer à propager notre propre univers. Faire en sorte que les mots comme “Empathie”, “Définition”, “Ideation”, “Prototype”, ou encore “Test” soit aussi inspirants pour les ingénieurs et POs qu’ont pu l’être “Backlog produit”, “Sprint planning”, “Rétrospective” ou “Sprint démo” pour les designers de ce projet. C’est une vision que nous portons chez ekino depuis longtemps, et qui nous permet de mieux comprendre les métiers de chacun.
Les clés du succès d’une stratégie Direct to Consumer (D2C) D’après la FEVAD (Fédération e-commerce et vente à distance), en 20 ans, le chiffre d’affaires du e-commerce a été multiplié par 100. C’est aujourd’hui un fait : la pandémie a été un puissant vecteur de consommation à distance. De nombreuses entreprises, particulièrement dans les secteurs de […]
Lire la suite de Les clés du succès d’une stratégie Direct to Consumer (D2C)