Accueil›Blog›Test technique UX design pour dashboards : discovery, wireframes, bonnes pratiques
Guide recrutement data
Test technique UX design pour dashboards : discovery, wireframes, bonnes pratiques
Construire des dashboards beaux ne suffit pas. Un Data Analyst Senior sait mener une phase de discovery, questionner les vrais besoins, choisir le bon visuel et organiser l'information pour que les décisions soient prises rapidement.
Data Builder·Juin 2025·8 min de lecture·Data Analyst
La plupart des Data Analysts construisent des dashboards sans avoir interrogé les utilisateurs. Résultat : des rapports techniquement corrects mais inutilisés. En entretien Senior, on évalue la capacité à mener une vraie phase de discovery avant d'ouvrir Power BI ou Tableau.
1UX vs UI : comprendre la différence
Question discriminante
Quelle est la différence entre UX et UI dans le contexte d'un dashboard ? Laquelle prime selon vous ?
- UX (User Experience) — ce que l'utilisateur ressent en utilisant le dashboard : est-ce qu'il trouve rapidement ce qu'il cherche ? Est-ce que les questions métier sont répondues ?
- UI (User Interface) — l'apparence visuelle : couleurs, typographie, alignements, icônes
- L'UX pilote l'UI — on commence toujours par comprendre les besoins, puis on conçoit l'interface. Faire l'inverse produit des dashboards beaux mais inutiles
- Double Diamond — découvrir le problème → définir le problème → idéer des solutions → livrer. S'appliquer aux projets de dashboards
Règle fondamentale : "You are not the user." Jakob Nielsen. Le Data Analyst qui construit le dashboard n'est pas représentatif de l'utilisateur final. L'observation et les entretiens sont indispensables.
2Phase de discovery : avant de toucher l'outil
Question discriminante
Quel est votre processus avant de commencer à construire un dashboard ? Quelles questions posez-vous ?
Un projet de dashboard se décompose en trois niveaux de découverte :
- Le projet — quel est le contexte ? Qui est le commanditaire ? Quel est l'objectif business ? Quelle est la fréquence d'utilisation ?
- Les données — quelles données sont disponibles ? Quelle est leur fraîcheur ? Qui les produit ? Y a-t-il des problèmes de qualité connus ?
- Les besoins utilisateurs — qui sont les utilisateurs finaux ? Quelles décisions prennent-ils ? Quel est leur niveau technique ? Quels outils utilisent-ils aujourd'hui ?
- Entretiens individuels — 3 à 5 entretiens semi-structurés avec des utilisateurs représentatifs. À faire en discovery avant toute conception
- Ateliers — session de groupe (5-6 personnes) pour aligner les parties prenantes sur les priorités
- Observation — observer comment les utilisateurs travaillent avec leurs outils actuels (Excel, slides, emails)
3Savoir poser les bonnes questions
Question discriminante
Quelles questions posez-vous à un utilisateur métier pour comprendre ses vrais besoins ? Quelles questions évitez-vous ?
Questions ouvertes et efficaces :
- "Décrivez-moi une décision récente que vous avez prise grâce aux données. Comment l'avez-vous prise ?"
- "Qu'est-ce qui prend le plus de temps dans votre travail de reporting aujourd'hui ?"
- "Si le dashboard existait, à quelle fréquence l'ouvririez-vous ?"
- "Quels sont les indicateurs que vous regardez en premier chaque matin ?"
Questions à éviter :
- Fermées — "Voulez-vous un graphique en courbe ou en barres ?" → l'utilisateur n'est pas un designer
- Hypothétiques — "Que feriez-vous si vous aviez toutes les données du monde ?" → réponses non actionnables
- Biaisées — "Est-ce que vous aimeriez avoir un tableau de bord en temps réel ?" → personne ne dit non
4Choisir le bon visuel
Question discriminante
Dans quel cas recommandez-vous un tableau plutôt qu'un graphique ? Et quand évitez-vous les graphiques en secteurs ?
| Objectif analytique | Visuel recommandé | À éviter |
|---|
| Évolution dans le temps | Graphique en ligne | Camembert, barres empilées 3D |
| Comparaison de catégories | Barres horizontales ou verticales | Radar, bubble chart |
| KPIs de synthèse | Cartes (cards) avec tendance | Tables de chiffres sans mise en forme |
| Répartition en % | Donut (max 4-5 segments) | Camembert 3D, trop de segments |
| Détail granulaire | Table avec tri et recherche | Graphiques quand >3 dimensions |
| Distribution spatiale | Carte choroplèthe | Carte par défaut sans indicateur clair |
Règle des secteurs : les camemberts et secteurs sont à éviter dans la plupart des cas — l'œil humain compare mal les angles. Un graphique en barres est presque toujours plus lisible pour comparer des proportions.
5Layout et hiérarchie de l'information
Question discriminante
Comment organisez-vous une page de dashboard ? Quelle est votre logique de mise en page ?
- Effet entonnoir — de haut en bas : filtres globaux → KPIs de synthèse → graphiques → tables de détail
- F-pattern ou Z-pattern — l'œil lit de gauche à droite, de haut en bas. Les informations les plus importantes en haut à gauche
- Alignement et consistance — même police, mêmes couleurs, mêmes tailles pour les éléments équivalents
- Whitespace — l'espace vide n'est pas perdu. Il guide l'œil et réduit la charge cognitive
- 3-4 graphiques max par page — au-delà, l'utilisateur est submergé. Préférer plusieurs pages bien organisées
- Axe Y à zéro — toujours pour les graphiques en barres (sinon visuellement trompeur)
6Les erreurs classiques en entretien
- Construire sans discovery — partir directement dans l'outil sans comprendre les besoins
- "Réflexe carte" — ajouter une carte géographique par défaut parce que les données ont un pays, sans se demander si c'est utile
- Trop de couleurs — utiliser 8 couleurs différentes dans un seul graphique
- Filtres partout — ajouter tous les filtres possibles sans les prioriser
- Titre "Ventes" — les titres doivent être des insights ("Les ventes T3 sont en hausse de 12%") pas des labels ("Ventes par région")
- Interactivité sans logique — ne pas tester ce qui se passe quand on filtre sur un seul segment
7Grille par niveau
| Niveau | Maîtrise attendue | Signal GO | NO-GO |
|---|
| Junior | Sait choisir un graphique adapté, comprend les bases de mise en page | Justifie ses choix de visuels, évite les camemberts sans raison | Ne sait pas pourquoi il a choisi tel ou tel graphique |
| Confirmé | Mène une discovery simple, wireframes avant de coder, structure une page en entonnoir | Mentionne les entretiens utilisateurs, a des wireframes dans son processus | N'a jamais interrogé un utilisateur avant de construire un dashboard |
| Senior | Discovery complète, design thinking appliqué, tests utilisateurs, guidelines d'équipe | A mené des tests utilisateurs, a défini des guidelines de design pour son équipe | Ne connaît pas le Double Diamond, n'a jamais observé un utilisateur utiliser son dashboard |
Home›Blog›UX design technical interview for dashboards: discovery, wireframes, best practices \n
Data hiring guide
\n
UX design technical interview for dashboards: discovery, wireframes, best practices
\n
Building beautiful dashboards is not enough. A Senior Data Analyst knows how to run a discovery phase, question real needs, choose the right visual and organize information so decisions can be made quickly.
\n
Data Builder·June 2025·8 min read·Data Analyst
\n
\n
\n
Most Data Analysts build dashboards without having interviewed users. The result: technically correct but unused reports. In a Senior interview, the ability to run a real discovery phase before opening Power BI or Tableau is assessed.
\n\n
1UX vs UI: understanding the difference
\n
Discriminating question
What is the difference between UX and UI in the context of a dashboard? Which one takes priority in your opinion?
\n
\n- UX (User Experience) — what the user feels when using the dashboard: do they quickly find what they are looking for? Are the business questions answered?
\n- UI (User Interface) — the visual appearance: colors, typography, alignments, icons
\n- UX drives UI — you always start by understanding needs, then design the interface. Doing the opposite produces beautiful but useless dashboards
\n- Double Diamond — discover the problem → define the problem → ideate solutions → deliver. Applied to dashboard projects
\n
\n
Fundamental rule: "You are not the user." Jakob Nielsen. The Data Analyst who builds the dashboard is not representative of the end user. Observation and interviews are essential.
\n\n
2Discovery phase: before touching the tool
\n
Discriminating question
What is your process before starting to build a dashboard? What questions do you ask?
\n
A dashboard project breaks down into three levels of discovery:
\n
\n- The project — what is the context? Who is the sponsor? What is the business objective? What is the usage frequency?
\n- The data — what data is available? How fresh is it? Who produces it? Are there known quality issues?
\n- User needs — who are the end users? What decisions do they make? What is their technical level? What tools do they use today?
\n
\n
\n- Individual interviews — 3 to 5 semi-structured interviews with representative users. To be done in discovery before any design
\n- Workshops — group session (5-6 people) to align stakeholders on priorities
\n- Observation — observe how users work with their current tools (Excel, slides, emails)
\n
\n\n
3Asking the right questions
\n
Discriminating question
What questions do you ask a business user to understand their real needs? What questions do you avoid?
\n
Open and effective questions:
\n
\n- "Describe a recent decision you made using data. How did you make it?"
\n- "What takes the most time in your reporting work today?"
\n- "If the dashboard existed, how often would you open it?"
\n- "What are the indicators you look at first every morning?"
\n
\n
Questions to avoid:
\n
\n- Closed — "Do you want a line chart or a bar chart?" → the user is not a designer
\n- Hypothetical — "What would you do if you had all the data in the world?" → non-actionable answers
\n- Biased — "Would you like to have a real-time dashboard?" → nobody says no
\n
\n\n
4Choosing the right visual
\n
Discriminating question
In what case do you recommend a table rather than a chart? And when do you avoid pie charts?
\n
| Analytical objective | Recommended visual | To avoid |
|---|
\n| Trend over time | Line chart | Pie chart, 3D stacked bars |
\n| Category comparison | Horizontal or vertical bars | Radar, bubble chart |
\n| Summary KPIs | Cards with trend | Number tables without formatting |
\n| % breakdown | Donut (max 4-5 segments) | 3D pie chart, too many segments |
\n| Granular detail | Table with sort and search | Charts when >3 dimensions |
\n| Spatial distribution | Choropleth map | Default map without clear indicator |
\n
\n
Pie chart rule: pie charts and sector charts should be avoided in most cases — the human eye poorly compares angles. A bar chart is almost always more readable for comparing proportions.
\n\n
5Layout and information hierarchy
\n
Discriminating question
How do you organize a dashboard page? What is your layout logic?
\n
\n- Funnel effect — top to bottom: global filters → summary KPIs → charts → detail tables
\n- F-pattern or Z-pattern — the eye reads left to right, top to bottom. The most important information at the top left
\n- Alignment and consistency — same font, same colors, same sizes for equivalent elements
\n- Whitespace — empty space is not wasted. It guides the eye and reduces cognitive load
\n- 3-4 charts max per page — beyond that, the user is overwhelmed. Prefer multiple well-organized pages
\n- Y-axis at zero — always for bar charts (otherwise visually misleading)
\n
\n\n
6Classic mistakes in interviews
\n
\n- Building without discovery — jumping straight into the tool without understanding needs
\n- "Map reflex" — adding a geographic map by default because the data has a country field, without asking whether it is useful
\n- Too many colors — using 8 different colors in a single chart
\n- Filters everywhere — adding every possible filter without prioritizing them
\n- Title "Sales" — titles should be insights ("Q3 sales are up 12%") not labels ("Sales by region")
\n- Interactivity without logic — not testing what happens when filtering on a single segment
\n
\n\n
7Grid by level
\n
| Level | Expected mastery | GO signal | NO-GO |
|---|
\n| Junior | Knows how to choose an appropriate chart, understands layout basics | Justifies visual choices, avoids pie charts without reason | Does not know why they chose a particular chart |
\n| Mid-level | Runs a simple discovery, wireframes before coding, structures a page as a funnel | Mentions user interviews, has wireframes in their process | Has never interviewed a user before building a dashboard |
\n| Senior | Full discovery, applied design thinking, user testing, team guidelines | Has conducted user tests, has defined design guidelines for their team | Does not know the Double Diamond, has never observed a user using their dashboard |
\n
\n