🧠 UX/UI Designer

1.1 UX/UI Designer — rôle, livrables, KPI, maturité

Mission (vraie vie produit)

Comprendre qui utilise, pourquoi, dans quel contexte, et avec quels freins.
Transformer des besoins flous en parcours simples, mesurables et cohérents.
Réduire le risque : tester vite avant de coder “trop”.
Assurer cohérence multi-écrans : web, mobile, back-office.
Concilier business, tech et usages (trade-offs explicites).

Delivering value = réduire la friction

Signal UX : moins de friction => plus de conversion / activation / rétention moins d’erreurs => moins de support plus de clarté => confiance & adoption

UX vs UI (simple)

UX	UI	Les deux
Comprendre besoins	Look & feel	Parcours
Flows & IA	Composants	Prototypes
Tests utilisateurs	Micro-interactions	Accessibilité
Priorisation	Guidelines	QA UI

Interfaces avec les autres métiers

PM/PO : discovery, scope, hypothèses, roadmap.
Dev : faisabilité, composants, handoff, QA.
Data : mesure, funnels, instrumentation.
Support/Sales : pain points réels, retours terrain.

Livrables (de la discovery à la delivery)

Étape	Livrables	But
Discovery	Problem statement, JTBD, personas, insights	Alignement
IA/Flows	Sitemap, task flows, user journeys	Clarté
Design	Wireframes, UI screens, states	Solution
Proto	Prototype interactif	Tester
Handoff	Specs, tokens, assets, AC	Construire
QA	Checklist, bugs UI, a11y	Qualité

States indispensables

Loading / skeleton, empty state, error state, success, disabled, permission denied.
Responsive : mobile / tablet / desktop.
Formulaires : validation inline + messages exploitables.

Definition of Done (design)

- parcours validé (flows + edge cases) - écrans + composants + responsive - states (loading/empty/error/success) - accessibility baseline (focus, contrast) - handoff (tokens, specs, assets) - instrumentation plan (events/funnels) - risque explicité (assumptions) + tests

Design documentation (mini)

- Règles de layout (grille, spacing) - Typographie (scale) - Color tokens - Components usage & dos/don’ts - Patterns (forms, tables, modals)

KPI UX (ceux qui comptent)

KPI	Définition	Pourquoi
Conversion	% qui atteignent l’objectif	Business
Time-to-task	Temps pour accomplir tâche	Friction
Error rate	Erreurs / abandons	Qualité
Activation	Atteinte “Aha moment”	Adoption
Rétention	Retour à J+7/J+30	Valeur
Support tickets	Volume tickets liés UI	Coût ↓

Instrumentation (plan)

- events: view_screen, click_cta, submit_form, error_validation - properties: plan, device, locale, segment - funnel: landing -> signup -> activation -> purchase

Quali vs quanti

Quanti : analytics, funnels, heatmaps → “quoi se passe”.
Quali : tests, interviews → “pourquoi”.
Le senior combine les deux pour éviter de “designer dans le vide”.

KPI sans insight = optimisation aveugle. Insight sans KPI = storytelling sans preuve.

Paradigme “Senior” (UX/UI)

Un senior ne “fait pas des écrans” : il réduit un risque produit.
Il structure le travail : hypothèses → test → décision → itération.
Il sait dire “non” (scope, complexité) et justifier via data/insights.
Il pense système : cohérence, tokens, components, gouvernance.

Senior checklist

- problème clairement formulé ? - user & context connus ? - alternatives comparées ? - edge cases couverts ? - états UI complets ? - a11y baseline ? - impact mesurable (KPI) ? - handoff dev “sans ambiguïté” ?

Maturité (L1→L5)

L1 : UI “au feeling”, pas de tests.
L2 : wireframes + quelques interviews.
L3 : prototypes + tests + analytics.
L4 : design system + instrumentation + a11y.
L5 : culture produit, gouvernance, recherche continue.

Objectif ultime : des décisions design traçables, testées, et reproductibles via le design system.

1.2 Research — interviews, JTBD, analytics, insights actionnables

Méthodes (panorama)

Méthode	Quand	Sortie
Interviews	Comprendre motivations	Insights
Surveys	Quantifier besoins	Priorités
Usability tests	Valider parcours	Friction points
Analytics	Mesurer usage	Funnels
Heatmaps	Détection UI	Zones ignorées
Card sorting	IA/navigation	Structure

JTBD (Jobs To Be Done)

Quand je [situation], je veux [motivation], afin de [résultat mesurable], malgré [contraintes].

Très utile pour éviter de “dessiner une feature” au lieu de résoudre un besoin.

Hypothèses testables

Hypothèse: "Si on simplifie l’onboarding à 3 étapes, alors l’activation augmente de +15% (J+7)." Test: Prototype + test utilisateur + AB test.

Interviews : guide court

Objectif : comprendre contexte, motivations, contraintes, vocabulaire.
Éviter questions “oui/non” ; demander des exemples réels.
Creuser : “qu’est-ce qui te bloque ?”, “comment tu fais aujourd’hui ?”.

Questions efficaces

- Décris la dernière fois que tu as fait X - Qu’est-ce qui t’a pris le plus de temps ? - Qu’est-ce qui t’a frustré ? - Comment sais-tu que c’est “réussi” ? - Qu’est-ce qui te ferait abandonner ?

Pièges

Interviewer “les collègues” uniquement (biais).
Confondre préférences (“j’aime”) avec besoins (“je dois”).
Tester des écrans trop finis trop tôt (biais esthétique).

L’interview n’est pas un sondage d’opinion : c’est une extraction de réalité terrain.

Analytics : ce qu’un designer doit lire

Funnels (où ça drop), time-to-activate, cohorts.
Events : click rates, errors, rage clicks (Hotjar).
Segments : device, locale, plan, source traffic.

Mini-funnel

landing -> signup -> onboarding -> activation -> retention drop points -> hypothèses -> tests -> itération

Instrumentation avec les devs

Pour chaque écran : - event: view_screen - actions: click_primary_cta, submit_form - erreurs: validation_error + reason - propriétés: device, plan, locale

Synthèse (format actionnable)

Insight	Preuve	Action
Les users ne comprennent pas “X”	6/8 tests	Renommer + help
Abandon étape 2	Funnel 60% drop	Réduire champs
Erreurs fréquentes	Logs validation	Inline guidance

Priorisation (impact/effort)

- Quick wins (high impact, low effort) - Bets (high impact, high effort) - Fill-ins (low impact)

But : Transformer une recherche en décisions. Pas en PDF “joli” oublié.

1.3 Information Architecture & User Flows — navigation, journeys, edge cases

IA : structure avant pixels

Définir sections, contenus, routes, et règles d’accès (roles).
Réduire profondeur : moins de clics, plus de clarté.
Nommer avec le vocabulaire utilisateur (pas interne).

User flows (template)

Goal: "Créer un projet" 1) Dashboard -> CTA "Nouveau projet" 2) Form: nom, type, owner 3) Validation -> success -> redirect Edge cases: - permission denied - duplicate name - network error / retry

Edge cases = qualité UX

Permissions, erreurs réseau, timeouts.
Empty states (0 items), pagination, search no results.
Bulk actions, undo, confirmations “smart”.

Les bugs UX les plus chers : ceux des parcours “non parfaits” (erreurs, vides, permissions).

2.1 UI Design — hiérarchie, grilles, micro-interactions, states

Hiérarchie visuelle (règles)

Un écran = 1 objectif principal (CTA).
Typo scale : titres > sous-titres > labels > hints.
Espacement = structure (8pt grid).
Contraste : lisibilité d’abord.

States UI (checklist)

- default - hover / focus - active / selected - disabled - loading / skeleton - empty - error - success / toast

Micro-interactions

Feedback immédiat : hover, pressed, loader.
Transitions légères (150–250ms).
Animations utiles (pas décoratives) : guider l’attention.

Design rule : Chaque action doit “répondre” (sinon l’utilisateur reclique).

2.2 Design System — tokens, composants, gouvernance, adoption

Tokens : la base “scalable”

Color tokens (primary, surface, text, danger…).
Spacing, radius, shadow, typography scale.
Permet thèmes (dark/light) + cohérence globale.

Exemple tokens

-- color --primary: #3b82f6; --surface: #0b1220; --text: #e2e8f0; --danger: #ef4444; -- radius --r-md: 12px; --r-lg: 18px;

Token pitfalls

Multiplier les tokens sans gouvernance = chaos.
Tokens “non sémantiques” (blue-500) partout = pas de thème.

Toujours préférer : primary / surface / text plutôt que: blue-500 / gray-900

Composants (catalogue)

Catégorie	Composants	Notes
Actions	Button, IconButton, Split	Variants + states
Forms	Input, Select, Date, Checkbox	Validation
Layout	Card, Grid, Modal, Tabs	Responsive
Data	Table, Pagination, Filters	Empty/errors
Feedback	Toast, Alert, Spinner	Durée

Doc composant (template)

Component: Modal - Usage: confirmations / forms / details - Variants: small/medium/large - States: open/close, loading, error - Keyboard: ESC close, focus trap - A11y: aria-modal, labelledby - Do/Don't: (ex)

Gouvernance : versioning & adoption

Roadmap DS + changelog.
Process : proposition → review → release.
Mesurer adoption : % écrans conformes, dette UI.

RACI simplifié

Owner DS: lead designer + FE lead Contributors: product teams Approvers: design council (light)

Anti-patterns DS

DS “figma only” sans implémentation code.
Pas de règles → forks → incohérence.
Pas de tokens → thèmes impossibles.

Design ↔ Dev : alignement

Storybook = source de vérité côté code.
Tokens partagés (CSS vars / JSON tokens).
Handoff : states & edge cases explicités.

Checklist modal (dev-ready)

- focus trap - ESC / backdrop close (option) - aria-labelledby / describedby - scroll lock - responsive sizes - long content (scroll) - actions (primary/secondary)

Le DS sert à réduire : - divergence design/dev - temps de delivery - bugs UI récurrents

2.3 Accessibilité (A11y) — WCAG, focus, clavier, ARIA, audit

WCAG : les bases à retenir

Perceivable : contraste, texte alternatif.
Operable : clavier, focus visible, pas de piège.
Understandable : labels, erreurs claires.
Robust : ARIA correct + HTML sémantique.

Checklist rapide

- contrast ratio OK - focus visible - navigation clavier complète - labels + aria-describedby - erreurs lisibles & associées - alt text (images)

Pièges fréquents

Placeholders utilisés comme labels.
Focus trap absent dans modals.
Couleur seule pour signifier un état.

Accessibilité ≠ “option” C’est de la qualité produit.

3.1 Prototypage & Tests — low/high fidelity, Maze, AB tests

Prototypage : niveaux

Niveau	But	Quand
Low-fi	Tester structure	Très tôt
Mid-fi	Tester flows	Avant UI final
High-fi	Tester perception + détails	Avant dev

Test modéré (script)

1) contexte & objectif 2) tâche (sans guider) 3) observer + questions 4) score (succès/temps/erreurs) 5) synthèse + next actions

AB testing (quand c’est utile)

Quand le volume est suffisant pour la significativité.
Hypothèse claire + KPI cible + durée fixée.
Éviter AB sur micro-détails sans impact.

Test d’abord le concept (proto), puis mesure à grande échelle (AB), pas l’inverse.

3.2 Handoff — specs, tokens, assets, acceptance criteria, QA UI

Handoff (ce que les devs attendent)

Composants réutilisables (pas 12 variantes “quasi identiques”).
États UI complets + responsive.
Tokens (colors, spacing, typography) plutôt que “valeurs magic”.
Assets optimisés (SVG/PNG) + noms propres.

Acceptance criteria (ex)

- L’utilisateur peut créer un projet en < 60s - Validation inline: nom obligatoire, min 3 chars - En cas d’erreur réseau: message + retry - Responsive: mobile/tablet/desktop - A11y: focus trap modal + labels

QA UI (checklist)

- alignements & spacing - typographies cohérentes - hover/focus/disabled - states (empty/error/loading) - contrast & focus visible - clavier (tab order) - i18n (text expansion) - performance (images)

Design + Dev + QA : le triangle qui évite les régressions.

4.0 Parcours & Interviews — portfolio, case study, questions, maturité

Progression

Junior : UI, composants, wireframes, collaboration.
Mid : flows, tests, analytics, IA.
Senior : stratégie, discovery, gouvernance DS, mentoring.
Lead/Staff : vision produit, cross-team, culture design.

Compétences “senior signal”

Capacité à mesurer impact (KPI + insights).
Structurer un design system (tokens + gouvernance).
Gérer complexité (tables, forms, permissions, edge cases).
Communication : story claire + trade-offs assumés.

Case study (structure gagnante)

1) Contexte & problème 2) Objectifs & KPI 3) Recherche (méthodes + synthèse) 4) Hypothèses & options 5) Prototype & tests (résultats) 6) Décisions & design final 7) Handoff & QA 8) Résultats (KPI) + learnings

Ce qu’un portfolio doit prouver

Raisonnement (pas juste jolis écrans).
Maîtrise du process (discovery→delivery).
Impact mesuré ou au moins hypothèses testées.
Capacité à gérer contraintes (tech, business, délais).

Questions classiques

Comment tu passes d’un besoin flou à une solution ?
Exemple de décision basée sur data (quanti + quali).
Comment tu gères un désaccord avec PM / dev ?
Comment tu priorises des améliorations UX ?
Comment tu conçois l’accessibilité ?
Comment tu construis/maintient un design system ?

Réponse attendue (style senior)

- clarifier objectifs & KPI - décrire recherche + insights - proposer options + trade-offs - tester rapidement (proto) - décider + documenter - mesurer après release - itérer (continuous discovery)

Rôle, responsabilités & livrables

Research & insights

IA, parcours & flows

UI Design & micro-interactions

Design System

Accessibilité (A11y)

Prototypage & tests

Handoff vers les devs

Parcours, portfolio & interviews