Exemple de CV de designer UX : rendre les décisions de conception visibles

Un CV de designer UX doit expliquer brièvement votre raisonnement et donner un chemin clair vers un portfolio qui l’étaye. De beaux écrans seuls ne révèlent ni problème, ni contraintes, ni qualité du raisonnement. Montrez l’apprentissage sur les utilisateurs, les choix et les détails de mise en œuvre. CV et portfolio ont des fonctions différentes : le CV établit l’expérience pertinente, les études de cas permettent d’en examiner les éléments plus profondément.

La designer fictive travaille sur des processus administratifs : l’exemple privilégie états, permissions et clarté des tâches. Un portfolio de marque visuelle ne soutiendrait pas seul le même argument. Définissez les problèmes que le CV vous présente comme capable de résoudre, puis choisissez des cas qui permettent de les examiner. La cohérence compte plus qu’une étiquette de design à la mode.

Le profil fictif de Samira se concentre sur un parcours difficile plutôt qu’un style visuel. Le point de demande d’accès relie observation et changement précis. Les prototypes répondent à des questions, pas à un objectif de volume. Les composants incluent clavier et erreurs parce que la qualité dépasse les écrans par défaut. La revue après diffusion montre une implication après transmission. Tous les employeurs, projets et résultats sont des exemples pédagogiques inventés.

Le point sur les composants inclut les états vides et erreurs parce que l’interface ne se limite pas au parcours idéal. Si vous les avez améliorés, ne cachez pas cette contribution sous « créé des écrans ». Expliquez le comportement à spécifier et l’usage des indications par l’équipe. Un travail d’interaction détaillé montre de la maturité même avec peu d’images prêtes pour le portfolio.

Pour chaque cas, retrouvez problème initial, contraintes, options et éléments guidant le design. Notez votre travail, les apports d’un chercheur ou product manager et les changements du développement. Protégez les participants. Pour du travail non partageable, utilisez une explication anonyme approuvée ou un autre projet. Une décision claire peut être utile même si l’interface finale ne peut être publique.

Ajoutez une répartition des contributions aux notes : recherche fournie par d’autres, conception effectuée, décisions communes et changements d’implémentation. Cela évite de s’attribuer accidentellement le collectif. Notez aussi ce que vous n’avez pas appris. Une étude de navigation ne prouve pas l’adoption à long terme ni la préférence de tout le marché.

Le premier point ne prétend pas que six séances représentent tous les utilisateurs. Il explique une réponse à une difficulté observée. Dans votre version, précisez la tâche et le changement suivant la recherche. « Amélioré l’expérience » est trop large. Si vous avez mesuré l’achèvement des tâches, donnez les conditions. Sinon, problème observé et réponse mise en œuvre restent utiles sans taux de succès inventé.

La réécriture de demande d’accès doit mener à un moment concret du portfolio : statut confus et nouvelle action suivante. Montrez l’option envisagée si elle explique le choix. Un avant-après sans tâche peut pousser à juger seulement l’apparence. Le point du CV doit donner assez de contexte pour qu’une vraie question porte la comparaison visuelle.

Les mesures d’utilisabilité demandent le contexte : tâche, participants, cadre et comparaison. Un petit test modéré repère des problèmes mais ne fournit pas une estimation de performance pour toute la population. L’adoption après refonte peut refléter d’autres changements. Décrivez prudemment les constats et utilisez le qualitatif s’il constitue vos données. Un système de design peut montrer son périmètre par composants, équipes ou comportements documentés sans réduire la qualité au nombre d’écrans.

Reliez méthodes et travail accompli. Un test d’utilisabilité peut s’appuyer sur une question et un choix qui en découle ; le prototypage, sur l’incertitude résolue. L’accessibilité doit décrire le travail réel, comme les spécifications clavier ou la collaboration spécialisée, sans conformité universelle. Listez les outils brièvement. Une longue liste remplace rarement un cas aux contributions et décisions justifiables.

Recherche et conception sont liées mais distinctes. Conduire des entretiens, analyser les résultats et les traduire en interaction sont des contributions différentes : décrivez les vôtres. Connaître une bibliothèque diffère de définir des comportements réutilisables ou d’en encadrer l’adoption. Utiliser un système existant ne doit pas suggérer sa création intégrale.

Les débutants peuvent utiliser cours, bénévolat ou projets personnels si le cadre est explicite. Une refonte spéculative doit nommer ses hypothèses sans suggérer l’accès aux utilisateurs ou données internes d’une entreprise. Montrez les itérations et la raison du changement final. Incluez les vraies contraintes, comme le recrutement ou les moyens de réalisation. Un cas ciblé sur un problème modeste apporte souvent plus qu’un processus inventé couvrant toutes les méthodes de recherche.

Les designers expérimentés doivent montrer l’élargissement de leur influence : cadrage ambigu, modèles partagés, contraintes entre équipes ou accompagnement. Ne faites pas de chaque point confirmé un atelier. Expliquez ce qu’il résolvait et l’effet de la décision sur le produit. Pour le management, donnez équipe et responsabilités. Pour l’expertise individuelle, décrivez le périmètre et les partenariats sans autorité hiérarchique inexistante.

Un designer venant d’une autre discipline peut utiliser un projet bien délimité pour montrer sa pratique actuelle. Expliquez les hypothèses utilisateurs et identifiez le spéculatif. Gardez les expériences antérieures de collaboration ou de domaine, mais laissez le nouveau projet établir la compétence de design. Ne convertissez pas après coup chaque ancien rôle en UX.

Imaginez qu’un administrateur de compte attribue régulièrement des accès au mauvais espace de travail. Votre travail de design commence par la compréhension de la tâche et de l’origine de la confusion, et non par le choix d’une nouvelle palette de couleurs. L’interface actuelle masque peut-être le contexte de l’espace de travail après la première étape. Dans vos notes, distinguez les observations des hypothèses et indiquez qui a participé à la recherche. Décrivez ensuite les solutions explorées, par exemple le maintien du contexte à l’écran ou la modification de l’étape de confirmation. Cela construit une étude de cas utile, même si la modification visuelle finale semble minime.

Un point fictif pourrait être : « Revu la sélection et la confirmation d’espace après des tests révélant une confusion de contexte, avec des libellés persistants et une vérification explicite avant envoi. » Il relie constat et interaction sans annoncer l’élimination de toutes les erreurs. Dans le portfolio, expliquez la direction choisie et les contraintes techniques. Montrez erreurs et clavier, pas seulement le meilleur écran. Si la version diffusée différait du prototype, dites-le honnêtement.

Le CV doit ensuite renvoyer vers l’étude de cas avec assez de cohérence pour que le lecteur la reconnaisse immédiatement. Utilisez le même titre de projet, les mêmes dates et la même description de votre contribution. Vérifiez le premier écran de l’étude de cas : il doit présenter le problème et votre rôle avant une longue chronologie du processus. Si la recherche a été menée par un collègue, reconnaissez sa contribution et mettez en avant votre réponse de design. Une présentation transparente de la collaboration est plus utile qu’un récit soigné où un seul designer semble avoir exercé toutes les disciplines.

Les logiciels d’entreprise demandent des exemples de complexité, permissions et processus répétés. Le mobile grand public peut valoriser interactions, intégration et contraintes de plateforme. Réordonnez les cas selon l’argument du CV et gardez mêmes noms et rôles. Si le visuel a vieilli mais que le raisonnement reste pertinent, expliquez le contexte au lieu de remplacer le fond par une maquette soignée sans rapport.

Examinez les interfaces et contraintes de l’équipe visée. Un logiciel de bureau complexe peut demander information dense et permissions ; le mobile, petits écrans et conventions de plateforme. Choisissez des contraintes comparables. Sans correspondance exacte, expliquez la décision transférable plutôt que de repeindre un projet sans rapport aux couleurs du produit de l’employeur.

Les faiblesses fréquentes sont les beaux schémas sans décision et les portfolios demandant un accès inexpliqué ou ouvrant sur une page inachevée. Vérifiez la compréhension du CV sans portfolio. Ne vous attribuez pas tout le collectif. Ne présentez pas des personas génériques comme des résultats de recherche et retirez identifiants de participants ou contenus clients confidentiels du PDF et des cas liés.

Ouvrez le lien exporté sans être connecté. Vérifiez sur petit écran images, légendes et textes expliquant votre rôle. Traitez correctement mots de passe ou consignes d’accès et excluez les détails de participants des fichiers. Comparez chaque point du CV au cas : périmètre, recherche et état de diffusion doivent correspondre.

• Reliez les observations de recherche à une décision de conception réelle.
• Distinguez votre rôle de celui du reste de l’équipe.
• Vérifiez l’accès au portfolio et la cohérence des noms de projets avec le CV.
• Décrivez précisément l’accessibilité sans conformité non étayée.