Aller au contenu
case — tehtrisproduct design · design system · direction artistiqueread: 3 min

Product design · UX en environnement complexe

Rendre une console de cybersécurité lisible sous pression.

Les analystes travaillent avec des centaines d’événements simultanés et quelques secondes pour décider. Le travail a porté sur la hiérarchie de l’information, la lecture des états critiques et la réduction du nombre de décisions à prendre par écran.

Client
Tehtris
Rôle
Product designer
Période
À compléter
Équipe
Produit, tech, analystes
Projet sous NDA — aucune capture publiable

Le produit traite des données de sécurité réelles : rien n’est publiable, pas même flouté. Ce schéma reproduit uniquement la structure des zones et le poids relatif des états. Le détail des écrans, des livrables et des arbitrages peut être présenté de vive voix, sous accord de confidentialité.

Schéma d’abstraction — proportions et zones de l’interface, sans contenu client.

01

Le contexte et le problème

La console concentre la détection, l’investigation et la réponse dans une même interface. Chaque écran doit servir à la fois la vue d’ensemble et l’examen d’un événement précis, sans obliger l’analyste à changer de contexte.

Le problème posé n’était pas esthétique : les utilisateurs voyaient tout, donc ne voyaient plus rien. La densité était nécessaire, sa hiérarchie non traitée.

  • contrainte: densité non négociable
  • contrainte: utilisateurs experts, formés
  • contrainte: états critiques lisibles en < 3 s
  • contrainte: vocabulaire métier existant à respecter

02

Comment j’ai travaillé

Le travail a commencé par observer des sessions réelles plutôt que par redessiner des écrans. Ce qui bloquait était le chemin entre l’alerte et la décision, pas le style des composants.

  1. Étape 1 — Terrain

    Observer des sessions réelles

    Sessions d’observation avec les analystes, relevé des contournements et des points de perte de contexte.

    • observation
    • entretiens
    • parcours réels
    Livrables
    • Synthèse des sessions d’observation
    • Cartographie des points de perte de contexte
    • Liste des contournements adoptés par les analystes
  2. Étape 2 — Structure

    Reprendre la hiérarchie

    Priorisation des informations par écran, échelle de gravité unique, ordre des actions selon leur fréquence réelle.

    • hiérarchie
    • wireframes
    • arbitrages
    Livrables
    • Règles de hiérarchie appliquées à tous les écrans
    • Échelle de gravité unique documentée
    • Wireframes des vues les plus chargées
  3. Étape 3 — Validation

    Tester puis systématiser

    Prototypes confrontés aux cas les plus lourds, puis passage des motifs validés dans les composants partagés.

    • prototypes
    • tests
    • composants
    Livrables
    • Prototypes testés sur les cas limites
    • Motifs validés versés dans la librairie
    • Spécifications d’états pour le développement

03

Décisions de conception

Hiérarchie des états critiques

Avant

Tous les niveaux de gravité traités avec le même poids visuel.

Après

Une échelle unique appliquée partout, lisible avant la lecture du texte.

Charge par écran

Avant

Chaque vue proposait toutes les actions possibles en permanence.

Après

Actions ordonnées par fréquence réelle, le reste accessible sans encombrer.

Continuité de l’investigation

Avant

L’analyste perdait son contexte en changeant de vue.

Après

Le contexte de l’événement suit l’utilisateur d’une étape à l’autre.

04

Ce que le travail a produit

Les écrans ne sont pas montrables. Les principes qui les gouvernent le sont : voici les motifs d’interface conçus pour ce produit, décrits sans révéler de contenu client.

  • Motif 01

    Échelle de gravité unique

    Une seule échelle visuelle, appliquée à tous les écrans, lisible avant même la lecture du texte.

  • Motif 02

    Densité par paliers

    Trois niveaux de détail dans une même liste : balayage, lecture, examen. L’analyste choisit sans changer d’écran.

  • Motif 03

    Contexte persistant

    L’événement en cours d’investigation reste visible pendant tout le parcours, jusqu’à la décision.

  • Motif 04

    Actions ordonnées par fréquence

    Les actions rares quittent la surface principale sans devenir introuvables.

05

Résultats

--cognitive.load:
undefined

Mesure à renseigner : retours analystes ou test de charge perçue.

--task.time:
undefined

Temps de traitement d’un événement avant / après.

--errors:
undefined

Erreurs de qualification ou retours en arrière évités.

// valeurs à remplacer par les chiffres réels — laissez « undefined » si le contexte est confidentiel

06

Ce que j’en retiens

  1. 01

    En environnement expert, simplifier ne veut pas dire retirer de l’information : cela veut dire la ranger.

  2. 02

    Les utilisateurs formés compensent les défauts d’interface en silence. Il faut les observer, pas seulement les interroger.

  3. 03

    La hiérarchie visuelle est une décision produit : elle dit ce qui compte en premier.

STATUS: OPEN_TO_WORK

Un contexte proche du vôtre ?

Je peux détailler les livrables, les arbitrages et les fichiers de travail lors d’un échange.

email