Comment avez-vous créé des directives de conception pour votre organisation?
En tant que spécialiste UX nouvellement embauché, je prévois de créer des directives de conception pour les développeurs et les testeurs QA dans mon organisation.
Le problème est que je ne sais pas quelle est la meilleure façon d'aborder cela. Dois-je commencer à l'écrire à partir de zéro? ou peut-être collecter des éléments dans les bibliothèques de modèles de conception? Je ne suis pas sûr.
Aucune suggestion?
Appréciez votre contribution :)
Il y a quatre sources d'informations à intégrer pour faire un guide de style:
Documentation existante sur les applications et l'organisation
Passez en revue les applications que votre organisation produit actuellement ainsi que les autres produits utilisés par vos utilisateurs. Vous recherchez deux choses:
Similitudes et différences entre les applications. Identifiez les éléments qui sont des normes de facto (par exemple, une icône pour une fonction particulière) qui devraient devenir des lignes directrices ainsi que les éléments qui doivent être normalisés (par exemple, la même fonction ayant deux icônes différentes selon l'application).
Mauvaise conception évidente et suspectée. Identifiez les fonctionnalités de conception répétées qui, selon vous, pourraient entraîner des problèmes de convivialité que vous souhaitez éliminer dans vos directives. Gardez également un œil sur les conceptions intelligentes qui aident les utilisateurs.
Cela comprend également l'examen de la documentation d'entreprise et la réunion avec le personnel marketing pour identifier les caractéristiques purement esthétiques qui doivent être normalisées pour établir une marque.
Normes de conception existantes
Vos directives peuvent citer des normes ou des modèles de conception existants, tels que les directives Windows UX, mais vous ne pouvez pas compter sur tout le monde pour les lire ou même les utiliser. Néanmoins, vous devez uniquement citer, et non reproduire, les normes existantes dans vos directives, sauf pour les violations flagrantes graves que vous avez découvertes dans votre examen des demandes qui méritent une attention particulière.
Surtout, vous voulez interpréter des directives pertinentes pour les types d'applications que fait votre organisation. Par exemple, les directives Web d'Usilability.Gov disent de "Mettre éléments importants et cliquables dans les mêmes emplacements , et plus près du haut de la page, où leur emplacement peut être mieux estimé." Dans vos directives, vous pouvez spécifier spécifiquement si une barre latérale ou un menu de marge supérieure sera utilisé, quels liens (ou types de liens) vont dans le menu de la barre latérale et quel ordre ils devraient avoir.
Plateforme et capacités techniques
Vos directives doivent être cohérentes avec la technologie utilisée par votre organisation. En particulier pour les applications Web, ce que vous pouvez faire dépend de la plateforme de développement exacte que vos développeurs utilisent. Par exemple, il est inutile de spécifier quand et comment utiliser les expandeurs lorsque la bibliothèque des développeurs n'inclut pas les expandeurs. Si vous n'êtes pas familier avec les détails de la technologie, rencontrez les développeurs et discutez de ce qui est et n'est pas faisable. Vous pourriez être surpris de ce qu'ils peuvent faire.
Résultats de recherche d'utilisateurs
Vous devrez peut-être effectuer des recherches et des tests d'utilisabilité pour certaines directives. Il peut s'agir de choses que vous soupçonnez de poser problème lors de votre examen initial des candidatures, mais dont vous n'êtes pas sûr, ou de choses difficiles (mais pas impossibles) à mettre en œuvre - vous voulez être sûr que cela en vaut la peine. Observez les utilisateurs à l'aide d'applications existantes ou testez-les sur des prototypes ou des démos pour de nouvelles applications ou technologies.
Lors de la rédaction des directives, tenez compte de leur utilité:
Fournissez un bref résumé des faits saillants (par exemple, une illustration annotée d'une fenêtre typique). Presque personne ne lira l'intégralité de vos directives, alors fournissez quelque chose de rapide qu'ils peuvent parcourir pour obtenir les points les plus importants.
Organisez-le, liez-le et/ou indexez-le comme le pensent les concepteurs et les développeurs. Pour une tâche de conception ou de développement donnée, vos lecteurs doivent pouvoir accéder rapidement aux directives pertinentes et les parcourir comme une liste de contrôle. Regardez comment votre organisation divise le travail pour des indices sur la façon d'organiser les lignes directrices.
Fournissez de nombreux exemples illustrés. Cela attire l'attention du lecteur, informe d'un simple coup d'œil, facilite l'interprétation du texte et, avouons-le, il est plus facile de copier quelque chose que de le fabriquer soi-même. Étant donné que vous pouvez vous attendre à ce que les concepteurs et les développeurs copient les exemples, assurez-vous que vos exemples sont entièrement conformes à tous vos directives, pas seulement les directives que vous souhaitez illustrer. Assurez-vous que les mauvais exemples sont clairement étiquetés comme de mauvais exemples.
Testez-le sur les concepteurs et les développeurs. Donnez à certains une tâche de conception simple et voyez s'ils peuvent trouver et utiliser toutes les directives pertinentes. Obtenez des commentaires de leur part sur la façon dont ils le trouvent utile et utile. S'il n'est pas facile à utiliser, ils ne l'utiliseront pas.
Soyez sur place pour répondre aux questions à ce sujet lorsque le moment sera venu pour les développeurs et les designers de se mettre au travail. Annoncez-vous en tant que gourou des lignes directrices.
Eric Schaffer de HFI a écrit un excellent guide étape par étape intitulé justement Comment développer une norme GUI efficace .
Je pense que la réponse de Michael est excellente. Un mot d'avertissement cependant: évoluer et changer un culture de l'organisation est tout aussi important que d'établir des directives. Cela ne peut se produire que lentement, au fil du temps, par exemple en envoyant par e-mail à vos collègues des captures d'écran occasionnelles de mauvaise conception (de préférence d'autres, pas celles de vos propres collègues), en organisant un déjeuner avec un sac brun avec une présentation, etc. quelques contraintes venant de Mars.
Cela peut s'appliquer ou non à votre organisation, mais j'ai pensé que cela valait quand même la peine d'être mentionné.
Je viens de créer un tel document pour mon entreprise. Au début, il était vraiment difficile de savoir par où commencer.
J'ai cherché des échantillons mais je n'ai rien trouvé d'utile. Ensuite, je commence à penser à comment je concevais. Puis écrit comme une liste ... (Pour les applications Web)
- Résolution d'écran (selon l'échelle d'âge du client)
- Lisibilité (taille de police - contraste - hauteur de ligne ...)
- Facile à utiliser (ordre de tabulation, utilisation de la zone de texte, commande, regroupement, boîtier progressif ..)
- Sécurité
- Importance du contenu
- Cohérence
- Logo, élément de menu, liens externes et bannières
- Cas d'utilisation CSS (externe, en ligne ... et type de support)
- Compatibilité du navigateur
- Charset
- Utilisation du cadre
- En-têtes, catégories et sous-groupes.
- Alignement des éléments
- Navigation (fil d'Ariane, pas à gauche ...)
- Utilisation de contrôles (ex: les boutons radio doivent être à l'intérieur de la balise d'étiquette pour être sélectionnés en cliquant sur leur texte ...)
- Utilisation de la table (en-tête, corps, pied de page, légende, réorganisation, filtre, pagination ...)
- Icônes ....
Bien sûr, vous pouvez trouver plus d'articles pour la liste, mais c'est la façon dont j'ai suivi. Gardez également à l'esprit que les documents "identité d'entreprise" sont également très utiles. Des entreprises et des universités de renommée mondiale partagent leurs documents sur le Web.
J'espère que cela aide.
Pour moi, une bonne directive de conception, celle-ci est empruntée au livret google sprint, devrait répondre à la question:
que représentons-nous, en tant qu'organisation, en termes de design?
Si vous remarquez, toutes les applications réussies comme airbnb, uber, gmail, Twitter ... elles ont un style authentique et reconnaissable que les utilisateurs peuvent indubitablement s'identifier et servir le but du service fourni. Par exemple, Uber, un sentiment noir haut de gamme astucieux convient "à ceux pour lesquels le temps est plus important que l'argent". Airbnb: une sensation de chaleur, de propreté et de sécurité, gmail ...
À mon avis, la première page d'un guide devrait répondre à cette question fondamentale, sinon, quelle que soit la qualité de l'expérience utilisateur ou le niveau de détail de votre directive d'interface utilisateur est décrite (voici Apples'iOS Human Interface Guidelines pour réf.), vos designers ne sauront pas dans quelle direction aller.