Le rôle hybride designer-développeur n'est ni un conseil de carrière à la mode ni un tour de passe-passe de licorne. C'est une position opérationnelle précise sur le marché qu'un sous-ensemble de praticiens peut occuper, et la prime pour bien la tenir est plus élevée que la plupart des gens ne l'imaginent. Ce post explique comment décider si vous devez poursuivre ce chemin, et comment construire la compétence si c'est le cas.
Devriez-vous poursuivre ce chemin ? Trois questions
Avant d'investir des années dans la seconde compétence, répondez à celles-ci. Si vous répondez non à l'une d'elles, le chemin du spécialiste est plus propre.
- Avez-vous déjà une profondeur professionnelle dans l'une des deux disciplines ? L'hybride n'est pas un raccourci. Deux compétences superficielles n'égalent pas une double compétence. Vous construisez la seconde compétence par-dessus une autre déjà à un niveau senior.
- Aimez-vous activement l'autre discipline assez pour la pratiquer sur votre propre temps ? Les signaux du marché pour l'hybride sont réels, mais la seconde compétence demande des années de pratique délibérée en plus d'un emploi à temps plein. Sans intérêt intrinsèque, vous ne tiendrez pas.
- Travaillez-vous (ou voulez-vous travailler) dans le type d'entreprises où l'hybride bat le spécialiste ? Startups, équipes de design systems, cabinets de conseil produit, entreprises d'outils pour développeurs ou designers. Les grandes entreprises avec des échelles de spécialistes profondes récompensent davantage la spécialisation.
Ce à quoi ressemble réellement le marché
Le marché de l'emploi pour les designers UX purs et les développeurs front-end purs est raisonnablement bien défini. Titres de poste, fourchettes de salaire, plans de carrière. Tout cela existe et est lisible. Le marché pour les rôles hybrides est moins lisible mais il n'est pas petit.
Cherchez ces signaux : des offres d'emploi qui listent à la fois Figma et TypeScript/Angular dans les exigences. Des titres comme 'UI Engineer', 'Design Engineer', 'Front-End Designer', 'UX Developer'. Des annonces dans des entreprises produit et des cabinets de conseil orientés design qui mentionnent 'pont entre le design et l'ingénierie' ou 'posséder l'interface de bout en bout'. Ces rôles existent en nombre significatif, et ils sont cadrés pour qu'une seule personne possède ce que deux personnes se partageraient autrement.
Les entreprises qui valorisent le plus les rôles hybrides : les startups et scale-ups où les équipes lean ont besoin de personnes polyvalentes. Les équipes de design systems dans les grandes organisations (c'est probablement le meilleur foyer structuré pour les compétences hybrides en entreprise). Les cabinets de conseil produit où les livrables clients couvrent à la fois le design et l'implémentation. Les entreprises qui construisent des outils de développeur ou des outils de design eux-mêmes. Elles valorisent les personnes qui comprennent les deux mondes en profondeur.
Comment les entreprises bénéficient de quelqu'un qui peut faire les deux
Du point de vue d'une entreprise, la valeur d'une personne hybride n'est pas juste d'éliminer un headcount. C'est d'éliminer un type de friction coûteux et difficile à mesurer.
Le handoff design-développement est l'un des points de friction les plus élevés dans la livraison de logiciels. Quand un designer transmet des spécifications à un développeur, de l'information est perdue. Les nuances sur l'intention d'interaction, le comportement dans les cas limites, les breakpoints responsives, les considérations d'accessibilité. Tout cela vit souvent dans la tête du designer et ne passe pas entièrement dans la spécification. Le développeur doit faire des choix. Certains sont bons ; d'autres introduisent de l'incohérence.
Une personne hybride élimine cette perte entièrement pour le travail qu'elle possède. Elle conçoit en sachant ce qu'elle va construire. Elle construit en sachant ce qu'elle a conçu. Le résultat est plus cohérent, les cycles d'itération sont plus courts, et l'interface résultante est plus complète techniquement et en termes d'expérience.
- Itération plus rapide : pas de cycle de handoff signifie que le feedback des prototypes atteint l'implémentation de qualité production plus vite
- Moins de lacunes de cas limites : un développeur qui pensait comme un designer pendant le design a détecté les états vides, les états d'erreur et les états de chargement dans la phase de design
- Meilleur design d'API de composants : un designer qui code conçoit des composants de système avec la bonne surface. Assez de flexibilité pour les besoins design, assez de contrainte pour la sécurité d'implémentation
- Cycles de revue réduits : les conversations 'ce n'est pas ce que j'ai conçu' n'arrivent pas quand le designer et l'implémenteur sont la même personne
- Accessibilité par défaut : les praticiens hybrides intègrent typiquement l'accessibilité plus tôt parce qu'ils comprennent à la fois l'intention d'interaction (design) et l'implémentation technique (développement)
Comment construire la double compétence intentionnellement
Le mot clé est intentionnellement. La plupart des développeurs qui 'connaissent aussi le design' ont acquis quelques compétences Figma de manière décontractée et ont des opinions sur le design visuel. Ce n'est pas une double compétence. Et la plupart des designers qui 'savent coder' ont écrit du HTML et CSS et peut-être un peu de JavaScript. Ce n'est pas une double compétence non plus.
Une vraie double compétence signifie que vous pouvez opérer indépendamment dans les deux disciplines à un niveau professionnel. Voici à quoi cela ressemble en pratique et comment je la construirais :
Si vous êtes développeur et construisez des compétences en design
- Apprenez les principes de design, pas juste les outils. Principes de Gestalt, hiérarchie typographique, théorie des couleurs, rythme visuel. C'est la grammaire du design. Figma n'est que le crayon.
- Étudiez les design systems intentionnellement. Material Design de Google, HIG d'Apple, Carbon d'IBM. Lisez-les comme des documents qui expliquent le raisonnement derrière les décisions. C'est de la pensée design à un niveau professionnel.
- Pratiquez l'UX spécifiquement : apprenez les flux utilisateur, le wireframing, l'architecture de l'information. La partie design visuel est apprenable rapidement. La partie pensée UX prend plus de temps et a plus de valeur.
- Contribuez aux revues de design. Si votre organisation a des revues ou des critiques de design, demandez à participer. Observez comment les designers pensent et parlent des problèmes.
- Construisez un portfolio de design aux côtés de votre portfolio de code. Montrer uniquement du code quand vous prétendez faire les deux n'est pas convaincant. Montrez des wireframes, des flux utilisateur, des décisions de design de composants avec le raisonnement.
Si vous êtes designer et construisez des compétences en développement
- Allez plus loin que le CSS. CSS et HTML vous amèneront à un niveau de fidélité de prototype basique. JavaScript et TypeScript sont ce qui vous rend crédible comme développeur. Choisissez un framework moderne et allez en vraie profondeur.
- Apprenez à construire des interfaces complètes et fonctionnelles, pas juste des maquettes visuelles. Cela signifie comprendre l'état, les données asynchrones, la gestion d'erreurs et le comportement responsive dans le code.
- Comprenez l'implémentation de l'accessibilité, pas juste le design d'accessibilité. Il y a un écart entre concevoir un composant accessible et l'implémenter correctement avec ARIA. Comblez cet écart.
- Contribuez aux revues de code. Si votre équipe fait des revues de PR, demandez à revoir pour la qualité visuelle et d'interaction. Cela vous expose à comment les décisions d'implémentation affectent les résultats de design.
- Construisez des bibliothèques de composants. Construire une bibliothèque de composants est l'expression la plus pure de la compétence hybride. Cela nécessite de penser comme un designer (quelles variations sont nécessaires ?) et un développeur (quelle API rend cela réutilisable et sûr ?) simultanément.
Implications salariales et de positionnement
Laissez-moi être direct sur la rémunération. Si vous comparez un rôle hybride à un rôle de spécialiste senior dans l'une ou l'autre discipline, vous trouverez souvent que le spécialiste senior gagne plus dans une grande organisation. Un Principal UX Researcher ou un Staff Front-End Engineer dans une grande entreprise tech peut gagner plus qu'un UI Engineer hybride.
Mais cette comparaison manque la réalité du marché pour la plupart des gens. Le plafond de carrière pour les spécialistes est élevé mais étroit. Vous devez être dans la bonne entreprise, la bonne équipe, au bon moment de leur cycle de recrutement. Le marché pour les rôles hybrides est plus large et plus constant. La personne hybride a plus d'options, plus de levier, et plus de capacité à naviguer les changements d'entreprise parce qu'elle ne dépend pas de l'existence d'une fonction spécialiste spécifique.
La compétence hybride est aussi plus facile à vendre en consulting, en freelance et en agence boutique, parce que le client achète une seule personne pour ce qui prendrait autrement deux personnes. Ce que ça vaut en tarif varie trop selon le marché et le client pour que je vous donne un chiffre, alors traitez ça comme un levier dans la négociation plutôt que comme une prime garantie.
Le problème de positionnement et comment le résoudre
Le principal risque de carrière du chemin hybride est le flou de positionnement. Si vous dites 'je suis à la fois designer et développeur' sans identité principale claire, les gens ne savent pas pour quoi vous embaucher et vous finissez entre les rôles plutôt qu'au sommet de l'un d'eux.
La solution : avoir un primaire et un amplificateur décrit. 'Développeur Angular Senior qui conçoit les systèmes de composants qu'il construit.' 'Designer UX qui code ses prototypes et revoit l'implémentation front-end.' Le primaire dit à quelqu'un pour quoi vous embaucher. L'amplificateur dit pourquoi vous êtes meilleur dans votre primaire que quelqu'un qui n'a pas la seconde compétence.
En entretien d'embauche, la manière dont vous décrivez l'hybride est cruciale. Ne menez pas avec comme si c'était inhabituel ou nécessitait une explication. Traitez-le comme une partie naturelle de votre workflow. 'Quand je conçois un nouveau composant, je pense aux états de design et à l'implémentation Angular simultanément. Cela signifie généralement que je détecte les cas limites techniques dans la phase de design et les cas limites d'interaction dans la phase de build.' C'est confiant et spécifique, pas défensif ou sur-explicatif.
Les meilleures interfaces que j'ai jamais construites étaient celles où j'étais à la fois la personne qui les a imaginées et la personne qui les a rendues réelles. Cette possession complète change la manière dont on travaille.
Références
- Figma. Guide to Developer Handoff. https://www.figma.com/best-practices/guide-to-developer-handoff/
- CSS-Tricks. The Great Divide (Chris Coyier on the split inside front-end between JavaScript-focused and HTML/CSS/design-focused work). https://css-tricks.com/the-great-divide/