Comment communiquer les spécifications de la maquette de conception Web aux développeurs frontaux?
Vous recherchez les meilleures pratiques pour communiquer les spécifications de conception de sites Web aux développeurs frontaux à des fins de découpage.
Sachant que les développeurs auront besoin de plus d'informations qu'une représentation visuelle de la conception, je recherche des moyens utiles pour communiquer spécifications détaillées de conception de nos maquettes graphiques, par exemple, les pixels et le remplissage entre les différents éléments de la conception, afin qu'ils puissent être efficacement découpés en HTML et CSS. J'utilise Adobe Illustrator CS5 pour créer les maquettes graphiques. Nous avons une relation de travail avec nos développeurs front-end.
La question: selon votre expérience, quels sont les bons moyens ou les meilleures pratiques que vous suivez pour communiquer clairement les spécifications de conception Web aux développeurs pour les exécuter sur le Web?
J'ai trouvé que la meilleure façon était de construire le front-end dans tous les outils que les ingénieurs du front-end utilisent. Dans notre cas, c'est Angular Material.
J'ai donc construit un guide de style en utilisant Angular Material (que j'ai appris au fur et à mesure) qui montre les différents éléments qui composent la plupart de nos applications: listes, boutons, éléments de formulaire, tableaux, etc. J'ai utilisé autant que possible des éléments matériels Angular avec des remplacements minimaux pour s'adapter à la marque ou à des utilisations spécifiques. L'équipe front-end est encouragée à copier mon code HTML et CSS. Si je marque quelque chose comme une table, par exemple, il y a une bonne raison de l'utiliser, et il ne devrait pas simplement être construit avec un tas de divs pour approximer l'apparence d'une table.
Maintenant, je n'ai généralement besoin que de compositions haute résolution pour "vendre" des fonctionnalités aux parties prenantes dans des présentations formelles ou pour des tests utilisateur rapides et sales, puis détailler les fonctionnalités et divers états dans des structures filaires basse résolution pour les ingénieurs frontaux.
Je ferai aussi parfois des compositions haute résolution pour l'équipe frontale s'il y a une légère modification nécessaire à un élément ou s'il y a un tout nouvel élément unique qui n'a pas besoin d'être dans le guide de style. Cela aide également à montrer comment certains éléments se combinent parce que je trouve que l'équipe frontale ne sait pas toujours comment combiner les éléments du guide de style (trop peu/trop d'espace entre les deux) ou il y a un élément supplémentaire (lignes, arrière-plan différent à définir quelque chose à part, etc.). nécessaire.
S'il s'agit d'une nouvelle application ou d'une fonctionnalité complexe, je ferai aussi parfois un prototype HTML haute résolution pour communiquer des transitions et des animations (happy path uniquement). Si j'obtiens un temps réel de test utilisateur formel (trop rare!), Je construirai également un prototype HTML happy-path. L'équipe d'ingénierie trouve cela extrêmement utile et ils aimeraient que je construise un prototype pour tout!
Personnellement, j'adore Balsamiq car cela vous permet de vous concentrer sur l'information et l'interaction, et non sur des détails inutiles. C'est le bon niveau pour la conception fonctionnelle qui doit être distribué et convenu.
Cependant, cela doit être traduit en une disposition spécifique détaillée. Cela est mieux fait par le développeur réel, et éventuellement avec un cycle de révision agile avec quelqu'un de plus spécialisé dans la conception visuelle. Je ne l'ai jamais vu bien fonctionner en créant une conception détaillée au niveau des pixels à l'avance à partir du code réel - c'est trop de travail et il n'y a pas assez de gain. Il est préférable d'avoir le concepteur visuel assis à côté du programmeur avec une implémentation de base et de modifier la disposition détaillée jusqu'à ce qu'elle soit visuellement attrayante, avec de vraies données.
Cela étant dit, j'ai travaillé avec des concepteurs visuels qui utilisent Adobe pour créer des exemples de mise en page au début du projet. Ceux-ci sont utiles pour se faire une idée générale, mais ils n'aident JAMAIS dans le travail de détail, car vous ne savez tout simplement pas assez sur l'interaction détaillée entre les différentes exigences. Nous JETONS TOUJOURS ceux-ci, et impliquons directement le concepteur visuel dans le code.
Plus sur mon blog I Guideline Resources .
Après avoir considéré mes expériences de projets plus récents, je pense que l'adoption ou la création d'un cadre de conception/développement est le moyen le plus efficace et le plus efficace de communiquer les spécifications de conception avec les développeurs front-end.
Je pense que la popularité des cadres de développement liés à bootstrap, et l'émergence des cadres de développement liés à Google Material Design est une indication que ces approches commencent à résoudre de nombreux problèmes de communication pour les concepteurs et les développeurs.
Je trouve que la meilleure façon est d'annoter vos fichiers PSD avec les spécifications de conception. Cela présente deux avantages: premièrement, les concepteurs peuvent voir exactement à quoi ressemble la conception, et deuxièmement, ils peuvent également obtenir le CSS directement annoté sur vos spécifications de conception (ou de la manière qui convient le mieux au concepteur et au développeur). Ensuite, vous pouvez simplement exporter le fichier dans une image de plus petite taille et le coller dans un guide de style, qui peut ensuite être référencé par d'autres concepteurs ou développeurs travaillant sur le projet maintenant ou plus tard.
La meilleure pratique consiste à créer le front-end. Les équipes UX devraient être en mesure de fournir la couche de présentation dans le cadre de leurs livrables. La conception interactive est, par nature, interactive et ne peut donc pas être facilement annotée entièrement dans des documents statiques.
Certes, en raison du personnel, de la politique de l'entreprise ou des budgets, ce n'est pas toujours faisable. Donc, sauf cela, cela va prendre du travail. Une option consiste en différents volumes de documentation. Mais c'est une documentation qui ne sert à rien d'autre que de traduire un type de document (PSD ou filaire) en un autre ensemble de documents (HTML, CSS et JS) qui, en fin de compte, est généralement jeté de toute façon.
En tant que tel, je suggère de sauter toute cette couche supplémentaire de documentation. Demandez à votre équipe UX de travailler étroitement et étroitement avec votre équipe de développement front-end. Les stand-up quotidiens sont un excellent moyen de gérer cela. Les développeurs peuvent travailler à partir de vos primitives et au fur et à mesure que les interactions et les détails visuels sont affinés, l'équipe UX peut intervenir avec des ajustements et des suggestions selon les besoins.
Je me considère comme un designer web/designer front-end, ou peut-être développeur front-end comme vous diriez? (essentiellement 90% du temps, mon travail se déroule entre photoshop, css, html et js/jquery)
Parce que je n'ai jamais utilisé illustrator pour convew des mises en page Web, expliquer le remplissage/marges exact en pixels n'a jamais été aussi difficile. Dans le passé, lorsque je travaillais sur des conceptions pendant que quelqu'un d'autre faisait le CSS, je coupais généralement le psd moi-même, remettais les images au développeur une par une, et expliquais où cela devait aller, quelles hauteurs, largeur et autres spécifications étaient nécessaires, et une sorte de stratégie pour le mettre en œuvre, si c'était quelque chose d'un peu plus sophistiqué que votre CSS typique.
Cela dit, j'ai l'impression qu'il s'agissait d'un cas inhabituel, où s'il s'agissait d'une organisation plus grande, et non d'une entreprise composée de deux personnes, je l'aurais simplement codé moi-même au lieu d'essayer de répartir le travail parce que nos compétences se chevauchaient.
En ce qui concerne les interactions telles que les états de survol, il vous suffit vraiment de l'annoter ou de l'expliquer séparément au développeur. J'aurais au moins une couche distincte clairement étiquetée en survol si vous transmettez un psd, mais si vous découpez vous-même des images et transmettez une image Sprite, il devrait être assez évident de savoir quoi faire.
Il ne semble pas y avoir de processus standard. Je pense que chaque organisation répartit le travail un peu différemment en fonction des compétences des personnes au bureau.
D'un autre côté, y a-t-il un avantage à utiliser Illustrator pour des maquettes de sites Web?
Lorsque le développeur front-end effectue le "découpage", c'est-à-dire la conversion en html/css (à ne pas confondre avec l'ancien découpage qui ne sera jamais effectué sur un flux de travail de développeur moderne, enfin peut-être parfois), il aura besoin du .psd des dossiers. De là, il mesurera tout à l'aide des outils intégrés. Pour la conception, Photoshop est un meilleur outil à la place d'Illustrator, à moins que nous ayons besoin de formes vectorielles qui doivent être exportées sous forme de fichiers svg.
Ce dont vous avez besoin, c'est de demander quels cadres ils utiliseront pour le projet, car cela changera considérablement la façon dont ils construiront les choses.
par exemple: s'ils utilisent bootstrap (99% l'utilisent), alors vous devez prendre cela en considération
le conteneur a un rembourrage de 15 pixels à gauche et à droite, la rangée a une marge de -15 pixels à gauche et à droite, le col- * aura un rembourrage de 15 pixels à gauche et à droite
ce qui veut dire que le contenu commence de gauche à 15px et en bettween text1 et text2, vous avez une distance de 30px ...
si vous suivez ces mesures, je suis sûr que le développeur frontal vous aimera :), car il n'a pas besoin de travailler contre le framework
si elles sont personnalisées jusqu'au bout, une bonne pratique si elles ont besoin de sites vraiment rapides, c'est encore mieux, libérez votre créativité :)
...
Un guide de style en direct est la meilleure approche, mais si vous avez conçu sans système de grille, rien de ce que vous faites n'a vraiment d'importance, car le développeur se battra constamment avec la perfection des pixels. Il en va de même si vous avez d'abord conçu le bureau puis le mobile, le développement des annonces se fait d'abord sur le mobile.
La meilleure approche est de parler aux développeurs et de voir ce qu'ils aimeraient comme référence, et de rester ouvert à eux, ne vous contentez pas de transmettre le projet.