Table des matières
Les listes de ce genre sortent recyclées tous les mois de janvier. Les mêmes dix compétences, légèrement reformulées, chaque année. Celle-ci reflète ce qui a vraiment bougé sur les douze derniers mois et ce que je chercherais à recruter aujourd'hui si je rebâtissais une équipe de design. L'ordre suit l'impact réel sur le travail quotidien, pas ce qui fait bien sur un CV.
1. Intégrer l'IA dans le processus de conception
L'IA a changé ma façon de travailler en 2024. ChatGPT et Claude génèrent des idées et de la copie pour remplir les maquettes. DALL-E produit des visuels temporaires quand je n'ai pas encore les vrais assets. La bascule plus profonde est venue avec Claude couplé à v0 : une description écrite devient un prototype interactif fonctionnel, pas un écran statique. Pour les projets qui passent de Figma au code de production, ça fait sauter l'étape de traduction la plus pénible.
Ce que l'IA fait bien en design aujourd'hui :
- Générer du contenu temporaire pour remplir des maquettes.
- Transformer une description écrite en prototype cliquable avec Claude et v0.
- Convertir des maquettes en code.
- Proposer des variantes de copie pour les boutons, les erreurs et les états vides.
Ce que l'IA fait mal : le jugement visuel, les cas limites, tout ce qui demande d'avoir vu un vrai utilisateur galérer. Les UIs générées tombent toujours sur la moyenne. Le job du designer, c'est de repérer quand le modèle débite quelque chose de médiocre avec assurance et de tout reprendre sous un angle différent.
Le workflow qui marche pour moi : écrire un paragraphe de problème, demander à l'IA trois approches, en jeter deux, développer la troisième à la main. L'IA est rapide pour produire des options, lente pour choisir entre elles. À utiliser dans cet ordre.
Pour aller plus loin, lis intégrer l'IA dans le design UX.
2. Maîtrise des outils nocode
Webflow et Bubble permettent de livrer un prototype fonctionnel sans écrire de code. Ça transforme un mois de travail d'ingénierie en une semaine d'exercice de design. J'ai utilisé Webflow sur des projets en phase précoce pour valider des idées avec de vrais utilisateurs avant de mobiliser les développeurs.
Les outils ont leurs limites. Bubble devient cher rapidement à l'échelle. Le CMS de Webflow se cogne aux murs dès qu'il faut des données vraiment relationnelles. Framer est excellent pour les landing pages et mauvais pour ce qui est stateful. Aucun ne remplace l'ingénierie de production une fois que le produit doit vraiment travailler. À utiliser pour la validation, pas pour le build.
Le piège, c'est l'équipe qui livre le prototype Webflow à de vrais clients et ne réécrit jamais. Le site reste « temporairement » sur la stack prototype pendant deux ans. Chaque plateforme nocode a son cimetière de produits qui ont grandi là et n'en sont jamais sortis. Planifie la migration avant de commencer, pas après que la boîte dépend du prototype.
3. Compétences en gestion de produit
Un designer incapable de prioriser est un wireframeur. Comprendre comment les fonctionnalités se font couper, pourquoi les délais comptent, et ce qui rend une feuille de route cohérente, ça te place dans la pièce quand les décisions se prennent. Les designers qui ont le plus d'impact sont ceux qui parlent la même langue qu'un chef de produit.
Les choses précises à apprendre : comment un PRD est structuré, ce qu'un OKR contraint vraiment, lire un backlog JIRA et savoir quels items vont sortir et lesquels non, ce qu'est une carte de parties prenantes, comment les décisions de stratégie produit cascadent en contraintes de design. La plupart des designers absorbent ça par osmose en travaillant avec des PMs, ce qui marche mais prend des années.
Le chemin plus rapide, c'est de lire ce que les PMs lisent. Inspired de Marty Cagan et Continuous Discovery Habits de Teresa Torres sont les deux livres qui reviennent le plus dans les book clubs PM. Ensuite, assister aux rituels PM (sprint planning, revues de roadmap, OKR-setting) même quand tu n'es pas obligé. En six mois, tu cesses d'être quelqu'un qui designe ce que le PM te tend et tu deviens quelqu'un que le PM consulte avant de décider.
4. Design systems et passage à l'échelle
Un design system donne de la cohérence à grande échelle et accélère les décisions sur les patterns récurrents. Pour les produits à multiples surfaces, ça libère du temps pour les vrais problèmes au lieu de débattre de la couleur des boutons. Le travail est surtout de la maintenance, ce que les designers sous-estiment avant d'en commencer un.
Les modes d'échec courants : des tokens qui dérivent du code, des composants que personne n'utilise parce qu'ils ne collent pas à ce dont les designers ont vraiment besoin, des réunions de gouvernance qui s'éternisent parce que personne ne possède le système. La règle pratique : un design system a un mainteneur, sinon il meurt. Mi-temps à petite échelle. Plein temps à grande échelle. En dessous, le système pourrit en six mois.
Quand ne pas en construire un : un seul designer, un seul produit, moins de cinq surfaces. La maintenance coûte plus que ce qu'elle économise. Une bibliothèque Figma partagée suffit. Construis le système quand tu as plusieurs produits, plusieurs designers, ou les deux, et que quelqu'un est prêt à en porter la responsabilité.
Pour aller plus loin, lis les principes de design d'interface.
5. Connaissance de la psychologie et des sciences cognitives (compétences UX)
Savoir comment fonctionnent vraiment l'attention, la mémoire et la charge cognitive vaut mieux que mémoriser les lois UX. Un flow qui respecte la charge cognitive survit au réel. Un flow qui l'ignore se fait raccourcir en production par un développeur qui essaie de le faire tenir sur un téléphone.
Les concepts qui aident vraiment en pratique : les limites de la mémoire de travail (environ quatre chunks à la fois, pas sept malgré le cliché), la reconnaissance versus le rappel (toujours montrer les options au lieu de demander à l'utilisateur de s'en souvenir), la loi de Hick (le temps de décision croît avec le nombre d'options, mais regrouper en catégories peut le réduire), la loi de Fitts (la taille et la distance de la cible comptent pour tout élément cliquable). Ce ne sont pas des notions académiques. Elles reviennent dans chaque revue de design où quelqu'un dit « ça semble confus » sans pouvoir dire pourquoi.
La plupart des designers les apprennent mal parce que le métier les répète sans les comprendre. Les gens connaissent le nom « loi de Hick » mais ne savent pas dire quand elle s'applique et quand non. Lis les sources originales quand tu peux. Don Norman The Design of Everyday Things, Steve Krug Don't Make Me Think, et Susan Weinschenk 100 Things Every Designer Needs to Know About People, pas les résumés de seconde main qui circulent sur Twitter.
6. Agilité et apprentissage continu
Les outils qui comptaient en 2022 ne sont pas ceux qui comptent en 2025. Si ton stack ne se rafraîchit pas tous les six mois, il prend la poussière. Ça veut dire lire et essayer des choses dans des projets réels, pas collectionner des certificats de cours qu'on ne finit jamais.
Les sources que je trouve fiables : Nielsen Norman Group pour de l'UX appuyée sur la recherche, Smashing Magazine pour la craft, The Pragmatic Engineer pour le côté ingénierie de comment les produits se construisent, Amy Hoy pour l'intersection design-business. Évite tout ce dont le titre est « X conseils pour Y ». C'est exactement le type d'article qui t'a fait lire cette liste de dix-là en premier lieu.
Time-box l'apprentissage. Une heure par semaine suffit si tu lis attentivement. Cinq heures par semaine te place devant la majorité du métier. Le piège, c'est le designer qui lit quarante newsletters et n'essaie jamais rien. Choisis deux idées par mois, applique-les sur un vrai projet, jette celles qui n'aident pas.
7. Conscience éthique et responsabilité sociale
Les choix de design ont des conséquences. Le contraste de couleur, le langage clair, les patterns qu'on choisit d'utiliser ou de refuser. La conformité WCAG est le minimum.
Le travail intéressant commence après le minimum : repérer les dark patterns avant que le produit les demande, nommer les groupes exclus des recherches utilisateurs, pousser contre les flows qui exploitent l'attention. Les outils précis qui aident : axe DevTools et WAVE pour les vérifications d'accessibilité automatisées, les W3C Authoring Tool Accessibility Guidelines pour ce que la revue manuelle doit couvrir, Privacy by Design comme cadre pour les flux de données. Ce n'est plus optionnel en 2025 dans aucun marché régulé, et la plupart le sont devenus.
La compétence plus dure, c'est savoir quoi refuser. Cases cochées par défaut trompeuses. Flux d'abonnement forcés. Compteurs d'urgence manipulateurs. Essais auto-renouvelables avec boutons d'annulation cachés. Un designer qui construit ça en est responsable. « C'était l'idée du PM » n'est pas une défense en UE. Ça ne le sera plus nulle part dans cinq ans.
8. Pensée stratégique et résolution de problèmes complexes
Le design tactique résout un écran. Le design stratégique décide quels écrans construire en premier lieu. Les designers que je vois passer senior sont ceux qui apprennent à pousser sur le brief, pas ceux qui l'exécutent proprement. Une formulation claire du problème économise plus d'heures de design qu'aucun outil ne l'a jamais fait.
La technique que j'utilise le plus : poser cinq fois de suite « qu'est-ce que l'utilisateur essaie vraiment de faire ? ». La première réponse, c'est la demande de fonctionnalité. La cinquième, c'est ce pour quoi le produit existe. L'écart entre les deux, c'est là où vivent les décisions stratégiques. Si l'équipe dit « les utilisateurs veulent une page de réglages de notifications », la cinquième réponse pourrait être « les utilisateurs ne nous font pas confiance pour ne les emailer que quand ça compte vraiment ». Ce sont deux problèmes très différents avec des solutions de design très différentes.
La pensée stratégique, c'est aussi accepter qu'on se trompera parfois sur quel problème résoudre, et apprendre à le découvrir plus vite. Écris l'hypothèse, définis quelle preuve te ferait changer d'avis, puis va la chercher. C'est plus dur que ça en a l'air. La plupart des équipes n'écrivent rien et débattent ensuite de qui avait raison après coup.
9. Collaboration interdisciplinaire
Le design n'est pas une activité solo. Le résultat dépend du développeur qui le construit, du chef de produit qui l'a cadré, du chercheur qui l'a testé. Connaître assez chaque rôle pour poser des questions utiles vaut plus que d'être le meilleur designer de la pièce.
Ça passe par écouter les gens qui ont plus de contexte que toi, traduire les contraintes en décisions de design au lieu de leur résister, écrire les choses parce que l'asynchrone est devenu la norme dans la plupart des équipes, et porter les bouts ingrats que personne d'autre ne veut. Les meilleures solutions émergent à l'intersection de ces perspectives, délibérément, jamais par accident.
La partie pas glamour : la majorité du travail interéquipes, c'est de la communication. Un design doc clair en deux paragraphes bat un beau fichier Figma dans 80 % des cas. Les développeurs veulent connaître les contraintes, les cas limites et la forme du modèle de données. Le marketing veut connaître l'angle de lancement. Les PMs veulent que les arbitrages soient écrits. Le support veut savoir quels nouveaux tickets s'attendre. Aucun ne veut scroller dans des frames pour trouver la réponse.
10. Adaptabilité aux nouvelles technologies
RA, voix, agents, ce qui vient ensuite. Tu n'as pas besoin de courir après chaque nouvelle techno, mais tu dois savoir reconnaître quand quelque chose passe au mainstream. Les designers qui se sont mis à l'aise avec le mobile en 2010 sont ceux qui ont sorti les apps qui ont marqué 2012.
La règle pragmatique : choisis une nouvelle technologie par an et construis quelque chose de réel avec. Pas un tutoriel. Un petit projet qui doit vraiment marcher. Certaines années, le choix est évident. Les agents IA en 2024 étaient impossibles à ignorer. D'autres années, il faut parier, et tu te tromperas parfois. Le coût d'un mauvais pari, c'est quelques week-ends. Le coût de ne parier sur rien, c'est tes compétences qui prennent l'âge.
Ce qu'il faut ignorer : tout ce dont la démo est le produit complet. Crypto et web3 ont eu ce problème pendant des années. Certains outils IA l'ont en ce moment. Si un outil est impressionnant en trente secondes de vidéo et décevant dans un vrai workflow, passe ton chemin. Le vrai signal, c'est si des équipes livrent des produits avec dans trois ans, pas si le lancement devient viral sur Twitter.
Si tu ne dois retenir que deux compétences de cette liste cette année, prends le prototypage IA et la gestion de produit. Tout le reste se construit sur ces deux-là.
