Comment pouvez-vous l'optimiser?

Comment pouvez-vous combler le fossé entre le développement et la conception pour créer la meilleure application possible? Suivez ce guide pour obtenir des conseils afin d'optimiser la manière dont les équipes de conception et de développement peuvent collaborer.

Aussi simple que cela puisse paraître, traduire le travail d'un concepteur UX en code n'est pas aussi simple que vous le pensez. ??‍♀️

Je n'ai même pas à discuter avec vous. Parce que si vous lisez cet article, à un moment ou à un autre, vous avez ressenti la douleur qui vient du fossé entre les développeurs ringards et les designers artistiques. ??‍???‍? (Je suis développeur, donc je peux nous appeler ringard.)

C'est pourquoi j'ai décidé aujourd'hui de creuser plus profondément dans cette lacune et comment pouvons-nous relever le défi d'optimiser réellement cela processus de collaboration. Traduisons un beau design en un code génial!

? Pourquoi faisons-nous autant d'histoires au sujet de la collaboration entre un concepteur et un développeur?

La réponse peut être évidente pour vous, mais passons en revue toutes nos hypothèses et essayons de répondre cette question pour les sceptiques.

Le propriétaire du produit (un client par exemple) est celui qui définit les lignes directrices d'un projet: à quoi devrait ressembler le produit fini, quelle valeur un utilisateur en retire, etc. [19659003] Tout cela entre en jeu pour le concepteur UX. Ils définissent le produit en fonction des besoins de ses utilisateurs attendus tout en s'assurant que les interfaces sont faciles à comprendre et à utiliser. De l'autre côté du rideau se trouve le développeur all-grêle dont le but est de donner vie à ce bébé.

Avoir un concepteur et un développeur travaillant ensemble est une vraie beauté ✨ parce que:

• Vous vous retrouvez avec un produit cohésif avec une excellente UX, UI et esthétique. ?
• Il ne sera pas nécessaire de travailler et de retravailler des composants ou des pages en raison de défauts d'alignement / mauvaise communication. En d'autres termes, vous économisez du temps à tout le monde à long terme.
• Ce qui signifie que le produit sera expédié plus rapidement et que la base de code sera propre et maintenable. ??

Et quand ils ne travaillent pas ensemble, vous obtenez le contraire de toutes ces belles choses que nous avons mentionnées. De plus, les inefficacités du flux de travail de conception à développement (D2D) ont tendance à s'aggraver avec le temps. Vous le savez parce que vous l'avez vu … ?

La dure réalité … ?

Vérifions la réalité: en travaillant ensemble sur le même produit (bon sang, même la même fonctionnalité), nous travailler séparément. ?

C'est parce que la MAJORITÉ frappante des projets adopte un flux de travail Over The Wall Design-to-Development (D2D). Dans lequel le seul échange d'informations qui se produit entre un concepteur et un développeur est lorsque le premier envoie les fichiers au second.

Parfois, ce transfert n'est même pas correct, juste des images en deux dimensions qui ne le disent pas. vous la user story, les spécifications, ni comment le produit interagit avec l'utilisateur.

Un autre cas que je trouve tout à fait frustrant est celui où il y a des itérations après le transfert avec des composants et / ou des mises en page nouveaux ou modifiés.

Ceci peut complètement démanteler la logique initiale sur laquelle un développeur a construit la base de code. Ce qui non seulement rend la fusion des modifications fastidieuse et prend du temps, mais est en soi un processus sujet aux erreurs.

En fin de compte, ce que nous ne prenons pas en considération est le fait que le vrai client du concepteur n'est pas uniquement le propriétaire du produit ou l'utilisateur. C'est aussi le développeur. Il est donc ahurissant qu'il y ait un tel écart entre eux. ?

? Comment en sommes-nous arrivés là?

Il y a des réponses évidentes et certaines le sont moins:

• Se concentrer sur des objectifs à très court terme (terminer un sprint / parcourir le backlog des fonctionnalités) au lieu de parfois juste une pause pour résoudre les inefficacités, non seulement dans la base de code mais dans le processus D2D.
• Des équipes éloignées qui vivent des villes / pays séparés. Ou simplement une équipe de conception et une équipe de développement qui sont hébergées dans différents départements ou même des bâtiments. Et, bien, mal gérer le processus D2D.
• Mauvais alignement entre le temps nécessaire pour implémenter la conception et le temps restant pour le lancement. La plupart du temps, nous pouvons remercier le chef de projet de ne pas avoir partagé ce petit détail à notre ami le concepteur UX. Ainsi, ils prendront simplement en considération leur propre date limite et concevront peut-être une interface utilisateur personnalisée impressionnante …
• Les outils sont excellents. Les outils sont faits pour améliorer notre vie. Certaines équipes ne les utilisent tout simplement pas. Pourquoi?! Pourquoi n'utiliseriez-vous pas un outil qui automatise le partage des spécifications de l'interface utilisateur?!

Par exemple, Storybook est un outil open source pour développer des composants d'interface utilisateur de manière isolée pour React, Vue et Angular. Cela rend la création d'interfaces utilisateur époustouflantes organisée et efficace. Vous pouvez trouver un exemple ici avec l'interface utilisateur de Coursera .

• Imaginez faire entendre votre voix en tant que concepteur UX unique qui doit travailler avec une équipe de 10 développeurs … C'est insensé, mais courant . Comment la voix de l'utilisateur peut-elle être entendue si la voix du concepteur UX ("expérience utilisateur") ne l'est pas?

Alors, quelle est la solution? ?

Certains diraient de devenir un touche-à-tout pour éviter ces tracas. Une fausse bonne idée ? ou comme on dit en français une fausse bonne idée mes chers .

J'ai pourtant entretenu l'idée. Mais je crois que concevoir et coder des expériences de grande qualité dans un délai optimal est très très difficile. Comme le dit le proverbe: "Homme à tout faire, maître de rien."

J'ai lu de nombreux articles affirmant que la meilleure façon de résoudre le fossé entre les concepteurs et les développeurs est d'apprendre le métier de l'autre. L'idée sous-jacente de cet argument est que les développeurs et les concepteurs viennent de deux mondes différents et pensent différemment. Qu'ils sont comme des extraterrestres les uns pour les autres, des nerds geek contre des hipsters artistiques. Que cela les aiderait à prendre du recul. Mais c'est faux à bien des niveaux!

Premièrement, je ne suis pas d'accord avec la façon dont chaque parti est représenté. Beaucoup d'entre nous, designers et développeurs, viennent d'horizons différents et ont des passe-temps et des intérêts différents. Donc, non, désolé, nous ne sommes pas comme deux espèces différentes.

Deuxièmement, vous pourriez gagner en perspective en apprenant quelques notions de base de l'art de l'autre. Cependant, si le bon flux de travail n'est pas implémenté pour lisser le processus D2D, il est inutile, et cela ne fait qu'une bonne conversation de table basse entre collègues.

D'autre part, le paradigme des composants qui a émergé avec React ou Vue gagne de nouveaux fans chaque jour. Sketch vous encourage également à concevoir vos interfaces à l'aide de composants. La combinaison de ces outils me semble vraiment être une affaire faite au paradis. Avoir des compétences pour chacun de ces outils (ou savoir comment ils fonctionnent) vous rendra beaucoup plus productif. Cela vous aidera à réfléchir aux interfaces et à les concevoir en tenant compte du travail que votre partenaire devra faire.

? Quel est le Flux de travail D2D optimal?

Un flux de travail par définition est une série d'étapes avec des outils qui permettent d'atteindre un objectif. ? Le but d'un flux de travail D2D est d'amener les concepteurs et les développeurs à travailler de manière ordonnée, organisée et complète dans l'ordre pour démarrer, faire évoluer et terminer un projet.

Il ne s'agit pas d'ajouter du travail supplémentaire des deux côtés. Bien au contraire, les étapes dont nous allons parler visent en fait à:

• Aider les concepteurs à concevoir pour le utilisateurs au lieu de l'ego
• Laissez les développeurs faire plus au lieu de se concentrer sur les distances de pixels

Impliquez l'équipe de développement dès le départ

Je ne dis pas que les développeurs devraient b e sur les épaules de chacun avant et pendant le processus de conception. Le simple fait d'intégrer le développeur principal dans le mix est généralement suffisant. De cette façon, le concepteur est conscient de ce qui peut être fait compte tenu de la pile utilisée et du délai disponible.

Si vous avez déjà eu à gérer des applications Android, vous savez à quel point il est difficile de s'en tenir à l'original. conception. Quelqu'un doit rappeler aux concepteurs de prendre en compte les spécifications Android, afin de réduire les retouches de conception. Ou pire encore, pour éviter d'avoir une application qui ressemble et se sent mal par rapport à la conception originale.

Certains frameworks sont livrés avec des icônes de police prédéfinies avec des composants par défaut et des dispositions et des paramètres de marge différents. Supposons que l'équipe de développement utilisera Bootstrap et que vous ayez commencé à concevoir votre canevas sans ces informations à l'esprit. Ce qui signifie qu'il y aura des écarts tels que les paramètres de marge dans votre plan de travail qui sont différents de la marge définie dans Bootstrap.

Il est important que le concepteur sache quel cadre sera utilisé au lieu d'avoir à faire des ajustements ou des compromis plus tard, que ce soit dans la qualité de la conception ou du produit final.

Templating réactif

Pour tout nouveau projet démarré, les concepteurs doivent toujours avoir trois modèles de largeurs différentes: mobile, tablette, ordinateur portable. Et c'est le MINIMUM. J'ai déjà eu des projets dans lesquels le concepteur ne fournit qu'une seule taille d'écran et vous laisse deviner tout le reste pour rendre le site Web réactif. Cela fait perdre un temps précieux à toute l'équipe de développement avec un résultat qui ne sera probablement pas bon.

Honnêtement, je préfère les conceptions basées sur un système de grille, car vous pouvez facilement concevoir pour différents points d'arrêt d'écran. En même temps, il vous permet de répondre à des tailles d'écran légèrement plus petites et plus grandes là où votre mise en page se brise.

Mais allons encore plus loin … ? Utilisons tous Mise en page automatique ! Un simple plugin Sketch qui changera votre vie en tant que concepteur: il vous permet de concevoir des écrans réactifs pour toutes les tailles d'écran (mettre l'accent sur TOUTES les tailles d'écran) en transformant les distances de pixels en pourcentages, puis permet au développeur de les exporter au format HTML. ? Exquis!

Implémenter un système de conception

Ne pas avoir de système de conception signifie que votre conception aura au moins quelques incohérences, si pas beaucoup. Ce qui se traduira par un développeur frustré, car ils devront certainement créer des composants compliqués et compliqués pour respecter cette conception.

Cela signifie également que nous perdons du temps à notre équipe de développement qui pourrait être mieux utilisé . Les futurs changements de développement seront plus compliqués et vous devrez maintenir une base de code plus lourde. D'un autre côté, avoir un système de conception aidera énormément à aligner la conception et les développeurs dès le début.

Ce qu'il ne faut pas comme sur un système de conception ? C'est une liste complète des composants réutilisables et des mises en page correctement structurés et organisé, chacun ayant un but avec ses différentes variations, états et spécifications. Cela facilite grandement les futures itérations UX et UI.

Dans votre système de conception, prêtez une attention particulière à:

• Y compris un Guide de style . C'est la base sur laquelle un système de conception est construit. Il comprend la palette de couleurs, la typographie et l'iconographie utilisées, les CTA, les ombres et les contrastes, ainsi que tout autre élément reproductible de votre conception. Sans cela, il sera difficile de développer une conception cohérente tout au long du projet, et ne soyez pas surpris si l'équipe de développement crée des écarts en termes de style d'interface utilisateur. Vous pouvez trouver de bons conseils ici .
• Utilisez Conventions de dénomination . Chaque composant, mise en page, page, ressource et fichier doit avoir une étiquette cohérente. N'utilisez pas seulement des noms génériques et des étiquettes de version. Cela ne veut rien dire et est assez inutile. Je recommanderais d'aller pour des étiquettes qui décrivent leur fonction.
• Fournissant tous les États possibles. S'il vous plaît, ne nous laissez pas deviner! ? Parcourez tous les états d'erreur, messages de validation et états désactivés pour les entrées et les boutons qu'un utilisateur peut rencontrer.

Remarque : Vous pouvez trouver une liste impressionnante de plus de 80 modèles systèmes conservés ici . Je vous recommande d'y jeter un œil au cas où vous auriez besoin d'inspiration. ?

Flux utilisateur

En vérité, ce que vous confiez à l'équipe de développement, ce n'est pas seulement des écrans de conception, mais un flux utilisateur que vous devriez être en mesure de raconter. Si vous ne pouvez pas raconter, cela signifie que vous rendez leur travail plus difficile. Si vous êtes perdu dans votre conception, l'utilisateur le sera aussi, et le développeur aura également du mal à corriger ces conceptions ensemble.

Raconter l'histoire de votre conception, c'est simplement être capable de dire ce qui se passe lorsqu'un utilisateur clique quelque part, pourquoi ils le font, que se passe-t-il quand ils le font et que se passe-t-il lorsque quelque chose qui ne devrait pas arriver se produit (comme avec les formulaires).

Remarque : Les flux d'utilisateurs sont généralement lorsque vous pouvez demander à vos spécialistes du marketing et à la croissance hackers pour collaborer avec vous. Surtout en ce qui concerne l'intégration du produit ou tous les entonnoirs importants que votre application peut avoir.

De plus, un développeur utilise l'histoire UX pour planifier son approche autour de la façon de créer les fonctionnalités. Assurez-vous donc de relier également tous les écrans entre eux. CHAQUE SEUL. Ne laissez pas certains écrans de côté et pensez que le développeur le comprendra. Non, ils ne sont généralement pas des lecteurs d'esprit. ?‍♀️?

Vous pouvez utiliser des outils comme Principle Figma ou inVision pour lier vos écrans et créer un prototype cliquable.

Je recommande Principe. Il vous permet de créer des prototypes de conception animés et entièrement interactifs en un clin d'œil. Cela ressemble vraiment à de la magie. ?‍♀️

Les prototypes de Principle sont vraiment formidables. Parce qu'en tant que développeur, nous ne recevons jamais les animations qui accompagnent l'exécution d'une action dans la conception. C'est assez étonnant de savoir que les animations et les micro-interactions ne sont pas seulement la cerise sur le gâteau, mais en fait une partie essentielle de la convivialité.

Une note rapide pour les développeurs : Essayez d'utiliser des animations CSS au lieu de celles de JavaScript. Ils sont beaucoup plus légers et fonctionnent mieux.

Spécifications visuelles de génération automatique

J'ai encore du mal à comprendre pourquoi un concepteur me confierait un projet sans utiliser un outil qui vous permet de voir les spécifications exactes d'un composant ( marges, rembourrages, codes couleurs, tailles, etc.). Vous pouvez facilement le générer automatiquement dans des outils comme InVision ou Zeplin .

C'est simple et cela permet aux développeurs d'éviter de passer leur temps à distancer les pixels. Pourtant, il est courant de ne pas utiliser cette option ou simplement d'oublier de leur donner l'accès approprié pour voir ces spécifications.

Actifs

Il y a deux choses que tout concepteur devrait faire en ce qui concerne les actifs:

• Store tous en un seul endroit ( Zeplin est parfait pour ça)
• Incluez les SVG chaque fois que vous le pouvez

Voilà. ?

Maintenir une liste de contrôle

Un nombre incalculable de fois, mon chef de produit m'a rappelé des designs de dernière minute que j'avais manqués. Cela aurait pu être évité en faisant une liste de toutes les fonctionnalités et scénarios de cas dont traite la conception (si et quand ils ne sont pas bien documentés dans le flux utilisateur ou le système de conception).

Alors? Où allons-nous à partir d'ici? ??‍?

Même si vous ne pouvez pas suivre tout cela (et ce n'est pas grave si vous ne pouvez pas), commencez simplement par implémenter ces méthodes une par une dans votre routine de travail. Même une autre bonne pratique fera progresser la collaboration entre un concepteur et un développeur.

Une dernière recommandation que j'ai consiste à organiser des réunions post-transfert qui incluent le chef de projet, les développeurs et l'équipe de conception. Habituellement, il y a des réunions entre le PM et l'équipe de développement, mais elles se concentrent uniquement sur le respect de la date limite. L'inclusion de l'équipe de conception est l'occasion non seulement de comparer chaque version de produit à la conception finale, mais également de déterminer quelles pratiques auraient pu être mises en œuvre pour éviter cela à l'avenir.

Vous pouvez me faire un ping sur Twitter @RifkiNada si vous voulez parler davantage de tout cela. ?