Retour aux travaux
Plateforme d'entrepriseAdministrationExplorance

Plusieurs consoles bâties par des développeurs, réunies en une seule

L'administration des produits Explorance passait par des interfaces autonomes, conçues au fil des besoins par les équipes de développement. Chacune avait son accès, sa logique et sa mise en page. J'ai été le seul designer sur la refonte qui les a rassemblées en une console unique.

9
Domaines d'administration réunis sous une même console
1
Designer sur le projet
v2.11
Onze itérations mineures après la première version
Adaptatif
Chaque écran décliné sur plusieurs largeurs
Vue d'ensemble de la console d'administration Explorance
Rôle
Product Designer, seul designer sur le projet
Entreprise
Explorance
Domaine
Administration de plateforme d'entreprise
Statut
Livré et en service

Contexte

L'administration, cette partie du produit que personne ne conçoit

Explorance vend plusieurs produits à de grandes organisations. Derrière chacun, il faut gérer des comptes, des droits, l'authentification, des réglages système, des tâches planifiées. Ce travail est indispensable et invisible, alors il se construit rarement avec un designer.

Chez Explorance, ces outils existaient déjà. Ils avaient été conçus par les équipes de développement, au fil des besoins, chacun de son côté.

Le problème

Des accès séparés, aucune unification

Un administrateur devait passer d'une interface à l'autre, avec des accès distincts, pour accomplir des tâches qui appartenaient au même travail. Rien ne garantissait qu'un réglage vu à un endroit correspondait à celui d'un autre outil. Chaque interface avait sa propre façon de nommer les mêmes objets.

Le problème n'était pas que ces outils étaient laids. C'était qu'ils n'avaient jamais été pensés comme un même produit.

La difficulté d'une refonte comme celle-là n'est pas de redessiner des écrans. C'est de reconstituer un modèle mental cohérent à partir d'outils qui ont chacun le leur.

Mon rôle

Seul designer sur un projet d'architecture

J'ai porté la conception de bout en bout, du modèle d'information jusqu'aux composants. La première partie du travail a été de comprendre ce que chaque outil existant faisait réellement, puis de décider ce qui devait cohabiter sous un même toit et sous quel nom.

  • Architecture d'information : regroupement des domaines et vocabulaire commun
  • Navigation latérale, avec son propre guide de style distinct des composants
  • Guide de style de composants pour la console
  • Déclinaison de chaque écran sur plusieurs largeurs
  • Animations de contenu et transitions entre les vues

L'architecture

Neuf domaines sous une autorité centrale

La console rassemble la vue d'ensemble, la sécurité, l'authentification unique, la gestion des applications, les réglages système, le journal d'erreurs, la langue du système, la gestion du planificateur et les réglages de profil en écrasement.

La gestion des applications a demandé le plus de travail, parce qu'elle réunit à elle seule la configuration, les périodes d'essai, les journaux, l'accès aux produits et les quotas. Ce sont des écrans qu'on ne dessine que lorsqu'un produit est réellement en service et que les cas réels remontent.

Gestion des applications dans la console

La gestion des applications, la section la plus dense de la console.

Les pouvoirs d'exception

Concevoir les écrans qui peuvent tout casser

Une console d'administration contient des actions qu'un utilisateur normal ne devrait jamais pouvoir déclencher. Écraser les réglages d'un profil, purger des données, forcer un état système. Ce sont les écrans les plus risqués du produit et les moins souvent conçus.

Je les ai traités comme des parcours à part entière : dire clairement ce qui va se passer, à qui ça s'applique, et ce qui ne pourra pas être annulé. L'écran d'écrasement de profil porte un avertissement permanent plutôt qu'une simple confirmation, parce qu'une confirmation se clique sans se lire.

Un administrateur pressé qui se trompe d'écran ne fait pas une erreur personnelle. Il en fait une pour toute une organisation.

Décisions et compromis

Trois arbitrages

Un vocabulaire, pas neuf

Renommer des objets que les équipes appelaient différemment depuis des années. Impopulaire au départ, indispensable pour que la console tienne.

La navigation comme système à part

Un guide de style dédié à la navigation latérale, séparé de celui des composants, parce que c'est elle qui porte la cohérence de l'ensemble.

L'adaptatif dès la conception

Chaque écran décliné sur plusieurs largeurs plutôt que laissé à l'interprétation du développement.

Ne pas cacher la complexité

Un administrateur a besoin de voir l'état réel du système. La clarté passait par la hiérarchie, pas par la simplification.

Ce que j'en retiens

Unifier, c'est surtout se mettre d'accord sur les mots

La partie visible du projet était une refonte d'interface. La partie décisive a été de faire converger des équipes qui avaient chacune leur vocabulaire et leur modèle mental, hérités d'outils construits séparément.

Le numéro de version du fichier en dit long : onze itérations mineures après la première livraison. Une console d'administration n'est jamais terminée, elle suit les produits qu'elle administre.

La console a été livrée et mise en service. La mention en cours restée sur la couverture du fichier est un statut que personne n'a pris le temps de changer, ce qui est assez représentatif du sort réservé aux outils d'administration.

ÉTUDE DE CAS PRÉCÉDENTE
Douze composants d'analytique, conçus seul, en six mois
ÉTUDE DE CAS SUIVANTE
Onze scénarios pour une seule porte d'entrée