Techniques de guide de style UX
J'ai récemment commencé une refonte majeure d'un grand outil financier basé sur le Web. Pour faciliter le développement futur, je prévois de générer un guide de style UX qui décrit les meilleures pratiques pour des choses comme les formulaires, les mises en page, les animations, etc.
L'application existante est un gros fouillis de formulaires avec peu de regroupement ou d'organisation. Je peux voir quelques catégories principales (formulaires Object CRUD, données statiques, contrôles de gestion de session utilisateur, etc ...) mais il y a beaucoup de fonctionnalités très personnalisées qui ne correspondent pas au moule.
La société avec laquelle je travaille effectue son développement à l'étranger et cette documentation est destinée à soutenir le développement futur. Je ne cherche pas à concevoir l'UX le plus étonnant jamais, je veux juste que les choses soient fonctionnelles . Quelle est la meilleure façon de communiquer des conceptions à des équipes distantes?
Voici ma question:
Quelle est la meilleure façon d'aborder un gros projet comme ça? (Les groupes principaux d'abord, puis se concentrer sur chaque fonction personnalisée? Incluez-vous même les fonctions personnalisées dans la documentation?)
Exemples de guides de style
Par exemple, les guides de style applicables aux applications, vous pouvez parcourir les guides de style de plateforme habituels (par exemple, Windows , Apple , Gnome ) pour le l'organisation, les problèmes et les sujets que vous voudrez peut-être avoir. De nombreux sujets de ces guides ne concernent pas les interfaces utilisateur orientées formulaire, mais la plupart des instructions pour les contrôles, les messages et les boîtes de dialogue complimentent les formulaires. Il existe également des directives pour les sites Web (par exemple, sability.gov ), mais celles-ci seront généralement moins utiles pour les applications.
Éléments à inclure
Pour l'approche de base, voir les réponses à Comment avez-vous créé des directives de conception pour votre organisation? Pour répondre à votre question spécifique, je fais une distinction entre les "éléments" ou les éléments d'une interface utilisateur (enregistrements, champs, mise en page, formulaires, commandes et commentaires) et "fonctions" (ce que certains pourraient appeler des "modèles"), qui assemblent plusieurs éléments dans une interface utilisateur standard pour une étape commune dans les tâches de l'utilisateur (par exemple, connexion, requête, rapports, annulation) , trier, zoomer, aider). Je couvre les deux dans un guide de style.
L'idée d'un guide de style est de vous éviter d'avoir à tout concevoir vous-même. Par conséquent, si une fonction personnalisée n'existe que sous une seule forme, ne l'incluez pas dans le guide de style. Cependant, vous souhaiterez peut-être inclure des composants ou des abstractions de la fonction qui sont couramment utilisés dans l'outil ou la suite.
Les livrables
Idéalement, la forme ultime du guide de style devrait être celle qui fonctionne le mieux pour vos utilisateurs - pas les utilisateurs de l'outil/de la suite, mais les développeurs et les concepteurs qui utiliseront le guide de style pour fabriquer l'outil. Un guide de style devrait faciliter leur travail, pas plus difficile. S'il est trop difficile pour vos utilisateurs de trouver les bonnes directives pour un cas particulier, ou de les apprendre et de les comprendre, ou de les mettre en œuvre, ils ne le feront pas. Vous pouvez appliquer vos compétences UX à la réalisation des livrables des directives en interviewant et en observant vos concepteurs et développeurs pour savoir ce qui fonctionnera pour eux (dans votre cas, vous pouvez être limité à des entretiens téléphoniques avec vos développeurs; mieux que rien).
Cela implique que le produit peut utiliser plusieurs supports. Il y a de fortes chances que le produit "principal" soit une sorte de document contenant un lien hypertexte, qui présente des avantages évidents pour le matériel de référence. Cependant, il peut également y avoir un guide de référence rapide ou des listes de contrôle, des affiches imprimables pour promouvoir les lignes directrices et mettre en évidence les fonctionnalités clés, une bibliothèque de modèles/modèles/CSS compatibles avec les guides de style, et des séminaires et des ateliers (éventuellement menés à distance) pour vous. présenter personnellement les lignes directrices et montrer leurs avantages pour les concepteurs et les développeurs. Franchement, la création des lignes directrices n'est qu'un début. La plupart du travail consiste à promouvoir et à appliquer les directives. Essayez d'obtenir le temps, le budget et le soutien organisationnel nécessaires.
Je sais qu'il y a une réponse acceptée, et je suis généralement assez d'accord avec Michael, mais cela me dérange encore pendant deux jours.
En tant que développeur, je détestais le Apple HIG
Cela ne m'a tout simplement pas dit quoi faire, comment faire les choses en pratique.
La directive Windows a été ressentie comme "vide", mais il se pourrait que ce soit le cas car il semble que, sous Windows, personne ne les suit.
Gardez à l'esprit que je devais avoir une relation intime vraiment avec l'interface graphique de Windows: nous devions être capables d'écrire de courts programmes Windows même sur papier =.
Je connaissais chaque widget, comment il fonctionne, quel est son objectif et comment l'appeler. Par cœur, littéralement.
C'était comme un mariage forcé.
Pourtant, je ne savais pas comment créer de superbes trucs, et ni le HIG ne m'a dit comment faire ça.
Si ce n'est pas le HIG, qu'est-ce qui rend les applications OS X si uniformément bonnes?
Bien sûr, les produits Apple Apple eux-mêmes ont été merveilleusement conçus, et tout le monde a juste essayé de les copier. Quand une copie a bien réussi, ils ont également copié les bonnes pièces. Mais les développeurs ont compris les modèles parce qu'ils utilisaient eux-mêmes les applications. Chaque fois qu'un développeur utilisateur Windows devait faire des applications mac, le résultat était presque un désastre complet.
(Si les développeurs n'utilisent pas le système - comme, vous avez mentionné ailleurs que c'est un logiciel bancaire - préparez-vous à de mauvaises choses)
Peut-être que les bonnes métaphores ont également aidé: des widgets bien conçus étaient connectés les uns aux autres, tout comme les briques lego.
Mais aussi: ils avaient modèles: on pourrait dire: c'est une application web basée sur des documents. C'est une application Web de données de base. Je suis presque sûr que le Web regorge de didacticiels CoreData + WebView quelque part comme en 2006-2007, nous venons de voir littéralement une pléthore de telles applications.
Les modèles de conception dans leur sens original des années 70 sont recettes: "Si vous avez ce problème, faites ceci": une fois que vous avez établi comment aborder le problème, vous êtes sur un chemin gagnant.
Un langage visuel est toujours un langage
Et les widgets sont son vocabulaire.
Pour moi, bootstrap ressemble à ceci:
Le développeur est invité à écrire une lettre complète écrite dans cette langue.
Pire: le développeur n'est pas intéressé par cette langue.
Il n'apprend pas cela pour le plaisir, on lui a dit de l'utiliser. Une certaine rationalisation aiderait, mais dans le cas de la langue d'une page Web, l'externalisation, avec un domaine séparé, aucun contact utilisateur, les développeurs ne s'en soucient pas.
Donc, généralement, ce qui se passe ici est que le développeur ouvre le vocabulaire, corrige les choses ensemble et soumet du code.
Vous avez besoin d'un guide de conversation complet au lieu d'un simple vocabulaire.
Ici encore, des lettres doivent être écrites. En chinois.
Vous devez dire, quand une phrase doit être utilisée. Vous devez montrer exemples, probablement à partir de des applications existantes écrites dans la même langue pour le même domaine problématique.
Chaque langage visuel a un langage de modèle sous-jacent, même s'il est implicite
Alexander's classic est une bonne lecture. C'est lui qui a introduit les modèles dans la pensée de l'ingénierie, et grâce au génie logiciel, il a également atterri dans l'UX. Un peu hors sujet, mais ça vaut la peine de lire son IEEE talk .
Ce que vous essayez de réaliser avec un guide de style UX est très-très similaire à ce qu'Alexandre a essayé de réaliser avec ses langages de modèle: il a essayé de définir les génériques et de mettre les décisions entre les mains des utilisateurs.
(Remarque: entre les mains des utilisateurs, pas entre les mains des développeurs)
Mais je pense toujours les recettes sont importantes: un catalogue de modèles de conception est toujours un catalogue de phrases. Il se pourrait qu'il ressemble davantage à l'Oxford Dictionary (contenant des définitions, à quel moment utiliser et exemples) plutôt qu'à un simple vocabulaire.
Cela manquait complètement aux HIG. Vous étiez là, il y avait des directives générales, et vous étiez comme, "OK, alors comment commencer?"
Un OS HIG n'est pas votre guide, exactement parce qu'un OS HIG est écrit dans le cas général: des applications de dessin aux lecteurs mp3, des lecteurs de courrier aux systèmes de catalogues des hôpitaux, tout pourrait théoriquement fonctionner sur un OS.
Il en va de même pour Twitter Bootstrap: c'est un langage de conception générique.
Vous devez trouver vos spécificités: où pouvez-vous personnaliser le contenu?
Modifier :
De quoi je parle en disant des détails?
Tout d'abord, vous identifierez sûrement les modèles des applications.
Il y aura généralement deux types de modèles:
- Modèles architecturaux, c'est-à-dire quel type d'applications y a-t-il principalement (vous avez mentionné que la plupart d'entre elles sont CRUD)
- Les modèles de widgets, c'est-à-dire que vous trouverez en fait des modèles de conception UX spécifiques qui peuvent être définis soit comme des widgets, soit comme une interaction de widgets, et vous définirez un en fonction de la bibliothèque de widgets qui leur correspond.
Vous devez également spécifier une troisième catégorie, généralement fortement liée à la première:
- Disposition
Conception d'interfaces Web a fait un excellent travail sur collecte des dispositions typiques pour les applications Web. Je recommanderais quand même le livre.
Vous devez distiller cela dans vos propres cas. Surtout, vous devrez trouver des modules d'application qui bénéficieraient réellement de ces dispositions, et les concevoir entièrement.
Ensuite, faites un choix aux développeurs: quel type d'application créez-vous? Un tableau de bord? Un système de formulaires? Ceci est la disposition d'un système de formulaire, ce sont les éléments requis, ce sont les éléments facultatifs (+ quand utiliser), c'est ainsi qu'ils devraient fonctionner ensemble.
Ce serait une bonne idée d'enseigner aux développeurs à penser réellement dans les flux d'utilisateurs, mais je doute qu'il serait facile de concevoir un processus complet orienté UX, en particulier. si vous sous-traitez.
Les développeurs les utiliseront si c'est moins d'efforts pour l'utiliser et inventer quelque chose par eux-mêmes que pour le gâcher complètement. Autrement dit, si vous avez des codes passe-partout complets à utiliser, qu'ils peuvent simplement saisir, cela fonctionnera bien.
En outre, fournissez-leur un ensemble de règles générales: au lieu de dire que "l'accessibilité est importante pour les personnes ayant des déficiences visuelles et des contrastes et des daltonisme et blahblah", il est beaucoup plus facile de suivre cela: "toutes les pages doivent être blanches sur noir, aucun rouge associé au bleu n'est autorisé".
Bien sûr, moins de fantaisie, mais je veux dire, construisons-nous des solutions suffisamment bonnes, ou essayons-nous de créer des concepteurs UX à part entière à partir de développeurs?
L'inconvénient sera que les développeurs feront écho à ces règles générales même après des années, et ils n'en entendront pas parler. Les exemples sont les règles 7 + -1 (elles continuent à l'enseigner à l'université!), Et fondamentalement quelque chose que vous trouverez à Mythes UX Non, ils ont gagné ' t lire les descriptions et les contraintes.
Mais je suppose que ce serait le problème de quelqu'un d'autre ...
Le développement à l'étranger est souvent le code d'un développement "pauvre". Je n'ai trouvé aucune quantité de guides de style pour résoudre ces problèmes. Mais c'est un sujet différent.
Quant à ce qui fonctionne, cela varie énormément d'une équipe à l'autre, d'un projet à l'autre. Alors que nous construisons des applications Web plus complexes, avec des interactions plus complexes et autres, je trouve que le meilleur chemin à parcourir est les bibliothèques de modèles/composants.
Ce sont des documents évolutifs qui sont conçus comme un référentiel central pour UX, Dev et Business. L'idée est de créer un hub central dont tout le monde peut tirer.
Vous identifieriez un composant qui a besoin d'être documenté. Vous mentionnez des formulaires dans votre exemple, qui peuvent alors avoir un grand nombre de composants individuels. Prenons un choix d'option, par exemple. Votre document peut alors contenir des informations telles que:
- Nom du motif
- utilise (quand l'utiliser, quand ne pas l'utiliser)
- Styles visuels (couleurs, polices, tailles)
- Documentation d'interaction (décrit les comportements du composant)
- versions alternatives
- exemple HTML/CSS/JS (pour l'équipe de développement)
- exemples de modèles filaires (pour l'équipe UX)
- états d'erreur
- exigences d'accessibilité
L'inconvénient? Je n'ai pas encore trouvé de produit capable de bien gérer une bibliothèque de modèles. Je l'ai vu essayé avec SharePoint, avec Axure, avec Word, mais tous ont des inconvénients. La meilleure option en termes d'outils en ligne que j'ai vu est patternry.com qui semble avoir du potentiel, mais qui manque également dans certains domaines.
Sauf tout cela, et en combinant le fait que vous externalisez le développement, si votre équipe et votre organisation peuvent le soutenir, le meilleur livrable est vraiment le code de la couche de présentation. Aucune quantité de documentation papier n'entraînera une traduction parfaite une fois de retour du développement à l'étranger, donc plus vous pourrez faire vous-même, plus vous aurez de contrôle sur l'UX à long terme.
J'ai récemment rencontré celui ci-dessous et leur ai demandé la permission de l'utiliser comme exemple pour celui que j'écris moi-même. Permission accordée:)
Je vous suggère d'utiliser un cadre. J'utilise Twitter Bootstrap . Il a son propre guide de style et garantit une uniformité de niveau avec peu d'effort.