Guides de style d'interface utilisateur: base des composants vs écran
Nous sommes en train de mettre à jour certains de nos processus et résultats créatifs au sein de notre entreprise et l'un des éléments que nous avons expérimentés est la façon dont nous générons notre guide de style d'interface utilisateur pour les développeurs et les partenaires.
Dans le passé, nous avons créé des documents très complets pour chaque écran de l'application ou du site Web. Votre capture d'écran typique avec des dimensions parfaites en pixels et des appels que tout le monde a déjà vus. Il y a eu une douleur à créer depuis longtemps et dans la plupart des cas, devenir obsolète très rapidement.
Nous voulons commencer à implémenter un guide de style de base de composant qui spécifie comment les composants et/ou les modèles d'interface utilisateur doivent être mis en œuvre par rapport à l'obligation d'appliquer des instructions spécifiques sur chaque écran d'interface utilisateur. Nous pensons que cela créera plus d'efficacité et fournira une meilleure documentation pour les équipes de développement et nous facilitera la mise à jour (en particulier avec Responsive Design).
Notre objectif est de cesser éventuellement de produire les guides de style statiques PDF et de créer la version HTML. Mais notre première étape est de produire la version PDF et de passer lentement en HTML.
Nous avons essayé cela avec un projet majeur et cela a été plutôt réussi. Nous avons construit le statique PDF guide de style de base des composants et nous avons demandé à nos développeurs d'interface utilisateur de créer une version HTML de chaque composant. Ensuite, notre deuxième équipe de développement a utilisé le document HTML pour créer des pages. Il y en avait quelques-uns problèmes mineurs mais principalement dus au fait que les développeurs ne suivent pas le guide de style et font leur propre chose.
Cependant, nous avons essayé cela sur un projet plus petit et c'était difficile à comprendre pour les développeurs. Je dirais que le succès a été de 70% mais que les concepteurs ont dû passer plus de temps avec les développeurs pour fournir des commentaires ou des directives sur certaines pages. Cela pourrait éventuellement être un problème de compétences sur la partie développeurs, nous ne sommes tout simplement pas sûrs.
Il existe de nombreux liens parlant de ce sujet particulier, mais je voulais voir ce que vivent d'autres personnes dans la même situation. Est-ce que ça aide? Voyez-vous des améliorations? Avez-vous rencontré des problèmes?
Pourquoi ne pas créer un PSD de vos éléments d'interface utilisateur. Par exemple, il s'agit du guide de l'interface utilisateur créé par Teehan + Lax pour le site Medium .
Je ne suggérerais pas de faire un guide de style sur écran, mais je recommanderais de faire une composition visuelle .png de chaque vue - une image avec notation et une sans. La notation pointe vers des éléments personnalisés, mais la vue peut généralement être créée en référençant un guide de style en ligne central.
J'ai mis en place un guide de style d'interface utilisateur basé sur des composants (HTML) vivant dans notre entreprise. Il est organisé par type d'élément (avec un menu d'ancrage pour un accès rapide) et chaque élément a un code HTML correspondant.
Avoir un développeur front-end senior a été crucial pour combler l'écart entre la conception et le développement.
Au fur et à mesure que je conçois les interfaces, j'isole et note les composants, qui sont ensuite construits par le développeur front-end, et les composants terminés vont dans le guide de style en ligne. Nous avons une seule feuille de style "de démarrage" que toutes les équipes peuvent utiliser, y compris l'AQ.
J'ai des réunions avec l'AQ et les chefs d'équipe pour m'assurer qu'ils sont au courant des nouveaux développements. Je fais également équipe avec des développeurs frontaux pour affiner et créer les composants ensemble. Je m'assure de dessiner de nouvelles interfaces à partir de styles existants au lieu d'en créer de nouvelles (nous avons 16 styles de texte (fabriqués à partir de 2 polices personnalisées), 7 couleurs principales, 6 nuances de gris et un système rouge, vert et bleu.)
Même si notre première ébauche ne comporte que des styles de police, des couleurs et une poignée d'éléments, ce processus et la feuille de style en ligne vivante ont rationalisé de nombreux processus, et la qualité visuelle et la cohérence entre les produits sont très visibles. Mon étape de notation visuelle est devenue très simple, et dans certains cas inutile.
Mon équipe de développement produit un guide de style de vie qui répond aux deux objectifs que vous mentionnez. Nous ne nous soucions pas de quelque chose comme un fichier Photoshop ou un guide PDF parce que ceux-ci tombent rapidement à jour et nécessitent un travail de traduction sur votre support de production (HTML).
En utilisant HTML, vous pouvez produire un modèle vivant qui montre la bonne utilisation de tous vos composants ainsi qu'un exemple de vos styles de page globaux. Nous utilisons la nôtre à la fois comme vitrine et comme point de départ pour tous nos projets de développement. La meilleure partie de l'utilisation de votre support de production comme guide de style est qu'il est facile pour les développeurs d'inspecter simplement le modèle pour voir la bonne façon de faire les choses. Faire en sorte que votre guide de style mette en œuvre votre guide de style vous donne l'avantage de la "dogfooding" et valide que vos styles sont prêts pour la production.
Une pensée est le public. Vous mentionnez les développeurs, mais avez-vous également une équipe QA? Que diriez-vous des personnes écrivant les exigences?
La raison pour laquelle je mentionne les autres membres du public ou les utilisateurs de la "documentation" est que leurs besoins peuvent différer.
Nous utilisons pour utiliser un fichier Word/.chm, basé sur du texte, lorsque j'ai commencé. Pour mon équipe, j'ai pris des éléments clés et les ai transformés en visuels via visio (les psd sont très bien pour cela cependant), en créant des composants personnalisés et en annotant des détails pour aborder les styles, les normes et l'identité visuelle.
Cela permet aux BA/chefs de produit et QA, ainsi qu'aux développeurs, une maquette visuelle de ce qu'ils conçoivent.
Finalement, nous migrerons vers tout le HTML et produirons des guides annotés statiques représentatifs. Donc, peu importe comment vous y arrivez, si vous avez des personnes dont le but n'est pas de réutiliser le code mais de comprendre les normes de conception, certaines sorties statiques présentent des avantages.