Par quoi commence vraiment un bon projet ?
Dans les parties précédentes, nous sommes arrivés à une conclusion importante - nous ne concevons pas un site simplement parce que l'entreprise a besoin d'une « nouvelle site ».
Nous concevons un outil destiné à résoudre un problème concret.
Parfois, le problème est une faible vente. Parfois, un nombre trop restreint de demandes. Parfois, les clients ne parviennent pas à trouver l'information. D'autres fois, les commerciaux répondent chaque jour aux mêmes questions parce que le site ne communique pas les informations de base. Il arrive aussi que l'entreprise ait simplement grandi et que l'ancien site ne corresponde plus à son échelle réelle.
C'est pourquoi la première étape ne devrait pas être Photoshop, Figma ni le choix d'un framework.
La première étape devrait être une conversation.
D'abord, nous découvrons l'entreprise
Un bon designer UX n'a pas besoin de devenir expert dans chaque secteur pour lequel il conçoit. Il doit cependant comprendre suffisamment le business du client pour savoir quels problèmes il cherche à résoudre.
C'est pourquoi nous posons des questions qui, au début, peuvent sembler sans rapport avec le design ;
- D'où viennent les clients ?
- Pourquoi choisissent-ils précisément cette entreprise ?
- Pourquoi partent-ils ?
- Que demandent-ils le plus souvent avant d'acheter ?
- À quoi ressemble le processus de vente ?
- Qui est responsable du traitement des demandes ?
- Que se passe-t-il avec un lead après l'envoi du formulaire ?
- Quels produits sont les plus importants ?
- Quels services ont le plus grand potentiel ?
- L'entreprise veut-elle augmenter le nombre de demandes, la valeur des commandes, le nombre de clients ou souhaite-t-elle surtout améliorer son image ?
Ce n'est qu'en répondant à ces questions que l'on peut déterminer ce que nous devons réellement concevoir.
Discovery - avant la première maquette
Dans les projets numériques, on utilise souvent le terme Discovery.
C'est l'étape consistant à comprendre le problème, les utilisateurs, les objectifs business, les contraintes et les possibilités technologiques avant de commencer la conception et le développement proprement dits.
Ce n'est pas une « perte de temps avant de commencer le travail ». Dans un projet bien mené, le Discovery vise à réduire le risque de construire quelque chose qui sera joli mais qui ne résoudra pas le problème réel.
Nous pouvons découvrir, par exemple, que le client n'a pas du tout besoin d'un nouveau site.
Il peut avoir besoin d'une meilleure architecture de l'information.
Ou d'une simplification du processus d'achat.
Ou d'une intégration du site avec le CRM.
Ou d'une automatisation du traitement des demandes.
Ou d'une manière complètement différente de présenter l'offre.
Et c'est précisément pourquoi il vaut parfois la peine de s'arrêter avant de lancer la production.
L'UX ne commence pas par l'apparence
L'UX, c'est-à-dire User Experience, signifie l'expérience de l'utilisateur lorsqu'il utilise un produit ou un service.
Pour un site web, cela englobe bien plus que l'apparence de l'interface.
C'est aussi :
- la manière de naviguer sur le site,
- la facilité à trouver l'information,
- la clarté des messages,
- le parcours d'achat,
- les formulaires,
- la hiérarchie des contenus,
- la vitesse d'exécution des tâches,
- la réaction du système aux actions de l'utilisateur,
- l'accessibilité,
- le sentiment de sécurité et de confiance.
C'est pourquoi l'UX commence avant que quelqu'un dessine le premier écran.
Il faut d'abord comprendre ce que l'utilisateur essaie d'accomplir.
User Flow - par quel chemin l'utilisateur doit-il atteindre son objectif ?
Un des outils de base du design UX est le User Flow. C'est la description du chemin que l'utilisateur parcourt pour accomplir une tâche donnée.
Par exemple, dans une boutique, cela peut ressembler à : publicité → page produit → choix du variant → panier → livraison → paiement → confirmation de commande.
Dans une entreprise de services : Google → page du service → réalisations → références → formulaire → contact avec le commercial.
Pour un fabricant : recherche → produit → spécifications techniques → documentation → demande de devis.
Chacun de ces parcours nécessite des décisions de conception différentes.
Si l'objectif principal de l'utilisateur est l'achat, on ne peut pas le forcer à lire une douzaine d'écrans de texte. En revanche, si le produit est cher, complexe et nécessite une consultation, pousser trop vite vers le formulaire peut être également une mauvaise solution.
L'UX consiste notamment à trouver le bon niveau d'accompagnement de l'utilisateur.
Wireframe - avant de « rendre joli »
L'étape suivante peut être le wireframe, c'est-à-dire un schéma simplifié d'un écran montrant la disposition des contenus et des fonctionnalités.
Le wireframe n'a pas besoin d'être beau. Et tant mieux. À ce stade, il ne s'agit pas de savoir si la couleur du bouton sera correctement choisie.
Il s'agit de répondre aux questions :
- Que verra l'utilisateur en premier ?
- Qu'est-ce qui sera le plus important ?
- Qu'est-ce qui doit être placé plus haut ?
- Où placerons-nous les informations supplémentaires ?
- Comment l'utilisateur passera-t-il à l'étape suivante ?
- Que se passera-t-il au clic ?
C'est un peu comme concevoir un appartement.
D'abord, nous décidons où seront les murs, les portes et les pièces. Ce n'est qu'ensuite que nous pensons à la couleur des murs.
Design system - pour que le projet ne soit pas un assemblage d'éléments aléatoires
Dans les projets plus importants, apparaît un autre élément essentiel - le Design System.
C'est un ensemble organisé de règles, composants et patterns qui définissent la manière de construire l'interface.
Il peut inclure, entre autres :
- les couleurs,
- la typographie,
- les boutons,
- les formulaires,
- les cartes,
- les tableaux,
- les messages,
- les icônes,
- les espacements,
- les règles de responsivité,
- les comportements des composants.
Pourquoi ? - pour que l'interface soit cohérente.
Si sur une page un bouton se comporte d'une manière et sur une autre page complètement différemment, l'utilisateur doit apprendre l'interface à chaque fois.
Le Design System aide aussi l'équipe de développement. Au lieu de recréer un composant à chaque fois, on peut réutiliser des éléments pré-définis.
Cela se traduit par plus de cohérence, un développement plus facile et souvent aussi un coût de maintenance réduit.
Et la technologie dans tout ça ?
La technologie devrait intervenir assez tôt, mais elle ne devrait pas dicter l'ensemble du projet. C'est une distinction importante.
Le designer peut imaginer une excellente fonctionnalité qui a du sens du point de vue business. Le développeur peut cependant remarquer que son implémentation sera très coûteuse ou posera des problèmes de performance.
Inversement, le développeur peut proposer une solution technologique facile à mettre en œuvre, mais qui, du point de vue utilisateur, ne résout pas suffisamment bien le problème.
C'est pourquoi les meilleurs projets naissent là où l'UX, le design, le développement et le business dialoguent ensemble dès le départ.
Pas sous la forme : « d'abord les designers, puis les développeurs ».
Mais : « réfléchissons ensemble à la meilleure façon de résoudre le problème ».
La technologie ne doit pas être choisie parce qu'elle est à la mode
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, CMS headless, application native, PWA... On peut énumérer les technologies longtemps.
Sauf que le client n'achète pas une technologie. Il achète une solution.
Donc la question : « Quel framework utiliserons-nous ? »
est souvent bien moins importante que : « Quels problèmes le système doit-il résoudre ? » Ce n'est qu'ensuite qu'on peut choisir l'architecture appropriée.
Une technologie différente est nécessaire pour un site vitrine simple, une autre pour une boutique traitant des milliers de commandes, et encore une autre pour une plateforme B2B avec des intégrations étendues et des permissions utilisateurs personnalisées.
La technologie doit découler des exigences, et non l'inverse.
Backend, frontend et la partie que l'utilisateur ne voit pas
Il faut aussi se rappeler qu'un site web n'est pas seulement ce que nous voyons dans le navigateur.
Le frontend est responsable de la partie de l'application avec laquelle l'utilisateur interagit directement.
Le backend gère la logique côté serveur - traitement des données, communication avec la base, gestion des processus ou intégrations.
Et entre eux, il y a souvent tout un écosystème d'éléments additionnels ;
- CRM.
- ERP.
- Système de paiement.
- Plateforme d'emailing.
- Système de gestion des stocks.
- API.
- Analytics.
- Automatisations.
- Système de support client.
Si nous concevons un nouveau site sans prendre en compte cet écosystème, nous pouvons créer un superbe frontend qui fonctionnera comme une île isolée.
Or l'objectif devrait être tout autre.
Un bon site peut faire bien plus que « collecter des formulaires »
Un site moderne peut être un élément d'un processus business plus large ;
- L'utilisateur envoie une demande.
- Le système reconnaît son sujet.
- Le lead est envoyé au CRM.
- Le commercial reçoit une notification.
- Le client reçoit une confirmation automatique.
- Les données sont classées dans la catégorie appropriée.
- Le système peut vérifier la disponibilité du produit.
- Il peut préparer des informations pour le commercial.
- Il peut déclencher un workflow donné.
Dans une boutique, la commande peut automatiquement passer par les étapes de traitement. En B2B, le client peut avoir accès à des prix individuels, des documents et l'historique des commandes.
Alors le site cesse d'être une simple « carte de visite ». Il devient une partie de l'infrastructure business.
Qu'en est-il de l'IA ?
L'IA peut aussi faire partie d'un tel système. Mais encore une fois - elle ne doit pas être ajoutée simplement parce que « tout le monde a maintenant de l'IA ».
Si un chatbot ne résout aucun problème réel, il ne sera qu'une nouvelle fenêtre sur le site.
En revanche, si grâce à l'IA l'utilisateur peut plus rapidement trouver le bon produit, configurer un service, obtenir une réponse à sa question ou traverser le processus de choix, alors la technologie devient justifiée.
Il en va de même pour la personnalisation.
Nous pouvons afficher à l'utilisateur des contenus différents selon son comportement, sa source d'entrée ou le stade du processus d'achat. Nous pouvons analyser les données et mieux prédire les besoins des clients.
Mais nous devons toujours commencer par la question : « Quel problème résolvons-nous ? »
Puis ensuite : « L'IA est-elle la meilleure manière de le résoudre ? »
Nous testons pas seulement si ça marche
Une des erreurs les plus courantes est de tester le site seulement à la fin. C'est alors que nous découvrons que le formulaire est trop long, que le processus d'achat est peu intuitif ou que l'utilisateur ne trouve pas l'information la plus importante.
Plus nous découvrons ce type de problème tard, plus sa correction coûtera cher.
C'est pourquoi il vaut mieux tester le projet par étapes. Nous pouvons vérifier le prototype. Nous pouvons observer le comportement des utilisateurs. Nous pouvons réaliser des tests d'utilisabilité. Nous pouvons analyser les données de Google Analytics ou d'autres outils analytiques. Nous pouvons utiliser des enregistrements de sessions ou des heatmaps, si elles sont mises en œuvre conformément aux exigences de confidentialité. Nous pouvons aussi simplement discuter avec les commerciaux.
Cette dernière source est souvent sous-estimée.
Le commercial entend quotidiennement les questions des clients ; il sait ce qu'ils ne comprennent pas. Il sait ce qui les inquiète. Il sait quelles informations doivent être communiquées avant l'achat.
C'est une énorme connaissance pour le design.
MVP ne signifie pas n'importe quoi
Dans les projets numériques, on entend souvent le terme MVP - Minimum Viable Product.
Il s'agit de la première version du produit contenant le jeu minimum de fonctionnalités nécessaires pour vérifier les hypothèses et apporter de la valeur aux utilisateurs.
MVP ne doit pas signifier : « Faisons n'importe quoi et on verra plus tard ».
Un bon MVP doit répondre à la question : « Quelle est la plus petite version de la solution qui nous permettra de vérifier si nous sommes sur la bonne voie ? »
C'est très important aussi pour les sites web et les applications.
Au lieu de développer immédiatement trente fonctionnalités, il est parfois préférable de lancer cinq fonctionnalités clés et d'observer comment les utilisateurs les utilisent. Ensuite, on développe le système à partir de données réelles et non uniquement d'hypothèses issues de la première réunion.
Le site ne s'arrête pas le jour de la publication
C'est une autre chose que l'on oublie souvent.
Le moment de la publication du site est en réalité le début de sa vraie vie. Ce n'est qu'alors que des utilisateurs réels apparaissent. Ce n'est qu'alors que nous voyons quels contenus fonctionnent. Ce n'est qu'alors que nous savons quels éléments sont ignorés. Ce n'est qu'alors que nous pouvons vérifier si le nombre de demandes, les ventes, le temps passé sur le site ou d'autres indicateurs que nous avons définis ont augmenté.
C'est pourquoi le projet doit être développé ;
- Analyse.
- Conclusions.
- Changement.
- Test.
- Nouvelle analyse.
C'est plus un cycle qu'un événement ponctuel.
Qu'est-ce qu'il faut mesurer exactement ?
Cela dépend de l'objectif du projet.
Pour une boutique en ligne, cela peut être :
- le taux de conversion,
- la valeur moyenne des commandes,
- les abandons de panier,
- le chiffre d'affaires,
- la valeur client à long terme.
Pour une entreprise de services :
- le nombre de leads qualifiés,
- le taux de conversion des formulaires,
- le nombre de consultations prises,
- le coût d'acquisition d'un lead,
- la qualité des demandes.
Pour un site d'information :
- la recherche d'informations spécifiques,
- l'engagement des utilisateurs,
- le nombre de retours,
- les téléchargements de ressources.
Il n'est pas nécessaire de tout mesurer. Il faut cependant savoir ce qui est important.
Car si l'entreprise veut augmenter le nombre de demandes utiles, une simple augmentation du trafic n'est pas forcément un succès. On peut avoir dix fois plus de visites et aucun client supplémentaire.
La plus grande erreur ? Concevoir sans répondre à la question « pourquoi ? »
On peut créer un site visuellement superbe.
On peut utiliser une stack technologique moderne.
On peut préparer des animations parfaites.
On peut soigner chaque pixel.
Et pourtant le projet peut ne pas apporter les résultats attendus au business. - Pourquoi ?
Parce qu'il a manqué la réponse à la question la plus importante : Pourquoi faisons-nous tout cela ?
Si la réponse est : « Parce que l'ancien site est moche »,
c'est un peu insuffisant.
Si en revanche elle est : « Nous voulons augmenter le nombre de demandes des clients B2B, réduire le temps d'accès au service approprié et soulager l'équipe commerciale des réponses aux questions répétitives »,
nous avons soudainement un problème concret à résoudre.
Et nous pouvons concevoir une solution.
Chez Web24, nous ne voulons pas seulement livrer des sites
C'est la différence entre exécuter un contrat et collaborer technologiquement.
Si le client vient avec une idée précise, cela ne signifie pas que notre rôle est de la réaliser sans réflexion.
Notre rôle est aussi de dire : « Ça a du sens ».
Ou : « On peut le faire mieux ».
Ou : « Techniquement, nous pouvons le construire, mais nous ne voyons pas de justification commerciale ».
Ou : « Avant de le faire, nous vérifierons si les utilisateurs en ont réellement besoin ».
Parfois la meilleure décision de design est d'ajouter une fonctionnalité. Parfois de la supprimer. Parfois de changer complètement les hypothèses.
Et c'est précisément l'expérience de l'équipe : non pas « nous savons tout construire », mais « nous savons reconnaître ce qu'il vaut vraiment la peine de construire ».
Il n'y a pas deux projets identiques
Revenons au point de départ.
Nous pouvons avoir deux clients du même secteur. Deux fabricants. Deux boutiques. Deux cabinets. Deux software houses.
Leurs sites peuvent se ressembler. Mais ils ne devraient pas être identiques uniquement parce qu'ils opèrent dans la même catégorie.
Parce que ce qui les différencie, ce sont les personnes. La stratégie. Le processus de vente. L'offre. Le budget. La technologie. Les clients. Les objectifs.
Et c'est pourquoi chaque projet nécessite des décisions propres.
Pas toujours spectaculaires. Pas toujours révolutionnaires. Mais conscientes.
Le site web comme outil, pas comme décoration
Un site bien conçu devrait être pour l'entreprise bien plus qu'une carte de visite numérique.
Il devrait aider l'utilisateur à prendre une décision. Il devrait faciliter la vente. Il devrait répondre aux questions. Il devrait instaurer la confiance. Il devrait soutenir les employés. Il devrait s'intégrer aux autres systèmes lorsque cela a du sens.
Et surtout, il devrait réaliser un objectif business concret.
C'est pourquoi il n'y a pas une seule réponse à la question : « À quoi devrait ressembler un bon site web ? »
Une meilleure question est : « Comment le site de cette entreprise spécifique doit-il fonctionner pour l'aider à atteindre ses objectifs ? »
Et c'est précisément à partir de cette question que tout bon projet devrait commencer.
Pour finir - la règle la plus importante
Nous ne concevons pas un site pour que le client puisse dire : « Comme c'est joli ».
Nous le concevons pour que, quelques mois plus tard, le client puisse dire : « Ça nous aide vraiment à faire du business ».
Parce que la différence entre un joli site et un bon produit numérique n'est souvent pas visible sur le premier écran.
On la voit seulement dans les résultats.
Résumé de toute la série
Dans cette série, nous avons examiné pourquoi nous ne concevons pas deux sites web identiques.
Nous avons commencé par une hypothèse simple : même secteur n'implique pas même business.
Ensuite, nous avons montré comment la stratégie de l'entreprise, le processus de vente, le public cible et les besoins des utilisateurs influencent l'UX, l'architecture de l'information et les fonctionnalités.
Dans la dernière partie, nous avons parcouru le processus de conception - du Discovery et de la découverte du business, au User Flow, aux wireframes et au Design System, jusqu'à la technologie, les intégrations, les tests, l'analytics et le développement continu.
Car un projet personnalisé ne signifie pas simplement « un look différent ».
Cela signifie des décisions différentes résultant d'un problème différent.
Et c'est pourquoi chaque entreprise devrait obtenir une solution conçue pour elle, et non pour la « société moyenne du secteur ».
