Contexte – Refonte du produit AOS

AOS : Le logiciel de gestion d’appels d’Offres BTP en ligne

AOS (pour appel d’offre simplifié) est un logiciel SaaS orienté B2B dans le secteur du BTP immobilier et de la construction. Il permet aux clients de gérer des appels d’offres du lancement de projet jusqu’à la signature de contrat.

Welcome to my home office 🙂

Mon rôle

Product designer 🎨

J’ai rejoint AOS pour aider le produit à faire peau neuve. En parallèle, j’ai travaillé sur le design de nouvelles fonctionnalités sur la plateforme existante.

En résumé :

Refonte produit (UI design, UX research, user testing, content strategy, wireframing, idéation, user flow)

Apport de solution UX pour de nouvelles fonctionnalités et conception UI sur le logiciel en pair avec l’équipe de PO et de développeurs.

Travail au sein d’une équipe de 4 designers sous la direction du head of design UI/UX

Première impression

Dès la première prise en main, on est premièrement pris par la complexité du logiciel qui est essentiellement provoquée par un manque de hiérarchie et des problèmes de UI et UX divers. 

Lorsque j’entame un travail de refonte, les points que j’observe sont les suivants : La structure, la typographie, les contrastes et les couleurs puis le travail sur les icônes. Les problèmes se situent souvent là.

C’est une manière simple de commencer avant de se pencher sur les problèmes de fonctionnalités ou sur le branding du produit.

Premiers problèmes notés

Trop de “white space"

Le white space ( l’espace entre et à l’intérieur des éléments ) donne une certaine lisibilité dans l’UI et quand elle est maîtrisée elle rend l’interface simple et élégante.

Sur le logiciel, elle est trop élevée notamment à l’intérieur des blocs. Ce qui donne des éléments flottants.

Il n’y a pas d’équilibre ou de structure cohérente.

Étonnamment sur d’autres écrans le problème est inverse, elles sont totalement encombrée par une multitude d’informations.

Mais que fait la police ?

La mise en forme du texte à travers la plateforme est incohérente ( taille, couleurs, alignements ) pas idéal pour une lecture confortable ou l’accessibilité …

Modal or not ?

Le logiciel comporte plusieurs modales qui abritent des fonctionnalités complexes
( tel que des tableaux éditables ou des formulaires ) or ce n’est pas une utilisation recommandée.
Dans le logiciel, les modales sont utilisées pour résoudre des problèmes de place sur des écrans déjà saturés. Normalement leur rôle est d’apporter plus de contexte à une page, ou attirer l’attention d’un utilisateur sur l’information importante.

Où sont les priorités ?

À première vue, sans lire les informations, on ne sait pas ce qui est prioritaire. Pour aider les utilisateurs à aller plus vite et à faire moins d’erreur, ce serait judicieux de les guider vers ce qui nécessite en priorité leur attention. Sur le logiciel il y a aucune hiérarchie de l’information, rien ne ressort.

Processus de recherche et d’exploration 

Après une formation sur le logiciel, j’ai travaillé sur un document de recensement des problématiques UI/UX déjà entamé par la team design auquel le support client (OPS) a apporté des observations.

Le but était de relever écran par écran les problèmes existants avec la rédaction de petites cards.

Exemple de cards de problématiques

Découpage

La refonte a été découpée en deux parties : Côté entreprise et côté Donneur d’ordre ( Le logiciel a deux types de comptes : “Entreprises" et “Donneur d’ordre" qui ont des fonctionnalités différentes ).

Chaque designer avait un flow attribué
( inscription, réponse au projet, etc … ) et était en charge d’y apporter des idées puis d’en faire les wireframes.

Atelier tri de carte

Nous avons réalisé plusieurs ateliers de tri de cartes en compagnie de l’équipe support client qui représente une bonne source des avis et les problèmes rencontrés par les utilisateurs.
Chaque flow/page a eu le droit à son atelier de 1H.

Les wireframes

Maintenant que les problèmes ont été identifiés. Nous nous sommes lancés dans des wireframes simples avec des blocs en nuances de gris ( plus complet d’un zoning ).

Pourquoi commencer par des wireframes en nuance de gris ? C’est important de se concentrer sur la structure et les fonctionnalités avant de passer à l’habillage couleur qui est une autre problématique. Ce sont souvent des « brouillons » qui permettent de présenter rapidement différents design aux équipes.

Nous avons prototypé des wireframes HD pleinement fonctionnels, ce qui nous a grandement aidé au moment de la présentation aux équipes dev et po.

Premiers wireframes exploratoires réalisés par mes soins.
( Page d’accueil )

Wireframe réalisé en équipe après discussion et ateliers tri de carte

Design : User feedback

Avec notre prototype en main, nous avons rencontré plusieurs clients pour observer leur comportement face à la nouvelle interface. J’ai eu le plaisir de conduire mon propre atelier. Les ateliers étaient scriptés selon un déroulé précis. Le testeur était libre pendant les tâches à accomplir. Le but était d’encourager l’exploration et la découverte sans intervention ou influence.

Déroulé type de l’atelier :

01: Préparation

Mail pré-test
(avec indication sur le lien skype à rejoindre).

02: Introduction

Expliquer le déroulement de l’atelier et donner des instructions générales.

03: L’atelier – Prototype interactif

L’utilisateur a 4 petites tâches à accomplir en autonomie dans le prototype; sous l’œil neutre et attentif du designer.

04: Conclusion

Fin de l’atelier : Echange libre, l’utilisateur partage ses impressions sur l’atelier, la refonte et ses idées. Remise d’un questionnaire en ligne pour qu’il puisse en privé noter l’atelier et ses observations.

Les ateliers nous ont permis d’avoir la perspective des utilisateurs finaux et de prendre conscience de nouvelles problématiques. C’est toujours un moment instructif. Nous avons relevé des usages imprévus ce qui nous a permis de challenger et remettre en question notre travail.

Aperçu de mon atelier test utilisateur

Ligne directrice design

Chaque designer de l’équipe a eu l’occasion de proposer un moodboard avec des idées pour la nouvelle UI. Premièrement j’ai pensé à une UI monochrome. AOS a été créé dans le but de rendre la vie facile aux acteurs du secteur du BTP. C’est exactement cette ligne directrice que doit suivre l’UI. L’une des solutions : une palette de couleur monochromatique et des icônes minimalistes. Avec ça ce sera plus facile d’avoir un design cohérent et facilement modulable dans le futur.

Après la présentation de différentes idées, nous avons discuté et créé un moodboard commun. 

L’idée générale est de partir sur couleur primaire forte et des niveaux de gris pour l’adoucir, et en complément quelques touches de couleurs secondaires pour montrer des statuts, tag, alerte, erreur …

Tour d’horizon des différentes recherche d’UI

Ma première proposition de design sur la base du dernier wireframe

Avec plusieurs tests de cards

Proposition réalisée en binôme avec un autre designer de l’équipe

UI retenue et réalisée en équipe après plusieurs recherches et discussions

Construction d’un nouveau design system

Le changement d’UI implique un nouveau design system. L’ancien design system était incomplet (aucune guideline, pas de composants) et pas toujours à jour l’état du logiciel en production. Ces problèmes peuvent occasionner des petites erreurs de cohérence, surtout lorsque plusieurs designers travaillent sur des fonctionnalités différentes. Et aussi complexifier l’ajout/modifications de contenu.

Pour résoudre ces problèmes, nous avons choisi de partir sur un nouveau design system basé sur l’atomic design. 

La phase de création du nouveau design system a commencé par un benchmark ( Polaris – Shopify, Carbon – IBM, Airbus … ) et le choix du design system manager, l’hésitation s’est portée entre Sketch et Figma.

Le choix s’est porté sur  Figma car c’est beaucoup plus adapté à la collaboration et à la création d’un design system par rapport à XD ( meilleure gestion des librairies, système de création de composants simple et complète, utilisation facile d’un auto-layout).

 Nous avons crée un design system modulable et complet ! 

200 + composants

crée avec leurs variantes et leurs états
( Hover, focused, disabled … )

Spécifications design

contenant le fonctionnement, le guide d’usage, l’anatomie … à destination des développeurs.

Guidelines

rédigée sur la typographie, les couleurs, l’accessibilité …