Implémentation de la documentation de support pour votre système de conception

Parlons d'un cadre pour la création d'une documentation de support en tant qu'élément clé de la création de votre système de conception.

La documentation du système de conception n'est pas une réflexion après coup mais une partie du processus de conception et de développement. Mais pour les équipes moins disciplinées, qui travaillent sur la documentation après la publication ou pendant la publication, le système manque de qualité des informations. Pourquoi? Par exemple, une fois le code fusionné, les accessoires de nommage sont systématiquement ignorés. Un bouton peut être confondu avec un lien. Si une équipe de conception estime qu'un composant ne devrait pas être autorisé à faire une certaine chose, il doit être documenté afin que ces cas particuliers ne soient pas construits pendant le développement.

Vos utilisateurs apprécieront également la documentation que vous avez créée pour chaque composant. Une documentation complète doit comprendre au moins des directives de langage visuel, des directives de code, des directives d'accessibilité, une mise en route, des notes de version et un processus d'assistance.

Si votre équipe manque de ressources d'assistance, une bonne documentation peut combler le vide d'une équipe d'assistance. Lorsque vous recevez un flot de questions, vous pouvez les diriger vers le site ou le hub de documentation central.

Alors, comment intégrer la documentation au flux de travail de votre équipe ?

Quelle que soit la structure de votre équipe système, votre équipe est chargée de créer l'intégralité des fonctionnalités d'un composant : conception visuelle, interface utilisateur, UX et notes de version. C'est ce que votre équipe système doit fournir. La façon dont vous construisez et livrez dépend de vous. Un bon flux de travail, cependant, devrait tenir compte de la documentation. Voyons comment !

Découverte → Conception → Construction → Doc → Publier

J'ai appris ce processus de workflow de Nathan Curtis qui est un expert en système de conception et était autrefois mon mentor. Je ne peux pas imaginer travailler sans ce cadre. Même les noms de ticket dans JIRA sont étiquetés comme l'un d'entre eux pour identifier à quelle étape du processus se trouve l'équipe avec un composant donné.

Un mot d'avertissement sur le flux de travail. Ces étapes peuvent se chevaucher ou être revues à tout moment du processus. Ils ne sont pas séquentiels, ce qui signifie qu'il n'est pas nécessaire d'en faire avant de passer au suivant. Build et Doc peuvent tous deux être travaillés en parallèle. Mais la Design doit être terminée avant que la Build se produise.

1. Découverte

C'est la première étape d'une nouvelle fonctionnalité. Cela nécessite une analyse concurrentielle, une analyse des besoins internes et une collaboration avec les adoptants potentiels. Ce qu'il faut poursuivre et ne pas poursuivre est l'objectif de ce voyage.

La découverte peut être décomposée en divergence et convergence.

La découverte initiale doit être aussi divergente que possible, c'est-à-dire examiner chaque cas d'utilisation potentiel, ses limites et sa pertinence. . (Consultez mon article précédent pour plus d'idées pour une phase de découverte complète.)

Ensuite, présentez vos découvertes à l'équipe. Après avoir reçu des commentaires et pris certaines décisions, il est temps d'affiner la découverte et de documenter vos conclusions. C'est ce qu'on appelle la convergence. Des idées sur ce qu'il faut faire commencent à émerger.

Cela peut être fait par n'importe qui : un développeurdesigner ou chef de produit. Mais cela devrait être fait par quelqu'un qui a plus de contexte sur le besoin de cette fonctionnalité.

2. Conception

L'étape de conception explore les permutations et les combinaisons d'un composant. Combien de variantes un composant doit-il avoir ? Qu'en est-il des tailles et de l'association d'autres éléments en tant que sous-composant ? La conception doit également explorer le style visuel et les modèles visuels.

Une fois les décisions de conception prises, un concepteur doit collaborer avec d'autres concepteurs lors d'une session de critique. Cela garantit la cohérence et la standardisation. Les concepteurs sont généralement critiques, donc obtenir les commentaires d'autres concepteurs ne fait que solidifier tous les cas limites.

Une fois les décisions prises sur la conception finale, un concepteur doit finaliser les wireframes et la documentation. La documentation doit être aussi complète que possible pour être transmise à un développeur.

Cette étape est généralement effectuée par un concepteur.

3. Build

L'étape de build permet de transformer la conception en code. Généralement, le code est construit en utilisant HTML, CSS et JavaScript. Il existe également de nombreux frameworks JavaScript. L'objectif ici est de s'assurer que le code est aligné sur les besoins de conception. Par exemple, le code doit prendre en charge différentes variantes et tailles.

Une fois le code écrit, il doit y avoir un test unitaire et une couverture de test visuel pour éviter tout échec imprévu. Une fois le code finalisé et approuvé, un développeur doit travailler avec le concepteur pour s'assurer que la qualité et les normes d'un composant sont respectées.

Une fois le code fusionné, la documentation doit être complétée par un développeur. Cette documentation présente l'installation, l'utilisation, tous les accessoires, événements et emplacements disponibles, le cas échéant. Une bonne documentation doit également prendre en charge l'accessibilité avec des étiquettes aria appropriées.

L'étape de construction est généralement menée par un développeur, mais un concepteur ayant une formation en développement ne devrait pas hésiter à effectuer cette étape.

4. Doc

Une fois le code fusionné, la documentation de la conception et du développement doit être fusionnée dans un endroit central.

Le document doit couvrir les normes de conception, les normes de code, les variations et les tailles disponibles sur un nouveau composant, des exemples à l'appui (interactifs si possible ), documentation sur l'accessibilité, images de support, journal des modifications et autres guides utiles.

Cette documentation peut être rédigée par un développeur, un concepteur ou un propriétaire de produit. Une fois la documentation rédigée, elle doit être modifiée par au moins deux membres de l'équipe pour s'assurer qu'aucun détail n'est ignoré. Une documentation approfondie entraîne moins de questions, ce qui permet en fin de compte à un système de se développer.

5. Publier

La dernière étape est assez simple. Toute la documentation doit être publiée dans un emplacement central. Il est important de prendre en charge un hub de documentation plutôt que de gérer plusieurs hubs séparément pour les concepteurs, les développeurs et les chefs de produit.

De nombreux systèmes de conception sont hébergés publiquement. Cela se fait pour différentes raisons mais surtout pour soutenir les adoptants et attirer des talents extérieurs. Les systèmes de conception font aujourd'hui partie intégrante de l'image de marque. Dans le monde numérique, votre système de conception peut présenter numériquement votre stratégie organisationnelle sans en dire beaucoup.

Que votre système de conception soit hébergé publiquement ou en privé, assurez-vous que toute l'équipe y a accès.

La dernière étape de la publication peut être. effectué par n'importe quel membre de l'équipe.

Conclusion

Les cinq étapes (Découverte, Conception, Construction, Documentation et Publication) ne sont pas nécessairement destinées à être suivies de manière séquentielle, mais ensemble, elles racontent une belle histoire des progrès réalisés pour chaque composant en cours de construction. Si une équipe construit trois composants simultanément, un chef de produit peut déterminer à quelle étape du processus se trouve un composant. Cela permet également à un système de conception de communiquer avec ses utilisateurs et de définir les attentes concernant le calendrier de livraison en conséquence.

Comme vous pouvez également le voir, la documentation joue un rôle du début à la fin. Bien que la documentation ne soit pas nécessaire à chaque étape, elle joue un rôle important de communication et de collaboration.

Imaginez si un développeur ne sait pas quoi ne pas construire, mais qu'un développeur construit quand même. Imaginez si un concepteur ne fournit pas de documentation sur l'espacement. Dans quelle mesure serait-il difficile pour un développeur de savoir quel rembourrage et quelles marges appliquer ? C'est un moyen rapide de perdre la cohérence de votre produit final.

Et encore une chose : vous devez documenter quelle est votre structure pour la façon dont vous construisez des composants. Ces étapes ne sont qu'un cadre de création de documentation, mais quelle que soit la stratégie suivie par votre équipe, vous devez la communiquer à vos utilisateurs sur votre site ou hub de documentation.