Je suis en train de créer un ensemble de normes d'interface utilisateur pour une grande entreprise, pour plusieurs services qui se chevauchent (sites Web, applications mobiles, systèmes internes et extranets).
C'est la première fois que je tente quelque chose de cette envergure et j'apprécierais des conseils sur:
1) Dénomination Quel est le nom "correct" pour un tel document/processus? Je l'ai vendu comme "Normes d'interface utilisateur" mais je ne sais pas si c'est le terme commun? Un autre nom est-il plus communément reconnu?
2) Conten Ceci s'appliquera à un certain nombre d'interfaces B2C, B2B et internes. Quels sont les sujets appropriés à couvrir et le niveau de détail, par exemple pour les formulaires, les messages de validation, les couleurs, etc.
) Format Le format de sortie évident serait un PowerPoint avec des exemples. Y a-t-il une meilleure façon? J'anticipe que ce sera un document régulièrement mis à jour et en croissance, donc une sorte de Wiki pourrait être mieux?
Tout autre conseil serait apprécié.
Ce serait probablement appelé UI Style Guide ou UI Guidelines mais il n'y a pas de nom "correct". Apple appelle le leur iOS Human Interface Guidelines ', Microsoft appelle le leur Windows User Experience Interaction Guidelines '.
Les deux couvrent à peu près tout ce qui doit entrer dans un document comme celui-ci. D'autres exemples sont:
Il n'y a pas de nom "correct". Il existe plusieurs guides avec des noms différents. "Normes d'interface utilisateur" est un nom parfaitement raisonnable pour ce document.
Il n'y a aucune information "correcte" à inclure. Les informations que vous devez inclure dépendent de la maturité de l'expérience utilisateur dans votre organisation et du degré de définition de chacun de ces éléments. Après tout, ce n'est pas parce que vous avez un document que tout le monde va le suivre comme par magie. Si l'UX est une petite partie de votre entreprise ou n'a pas encore beaucoup de traction, commencez les lignes directrices avec un contenu sur lequel tout le monde peut s'entendre et développez-le au fil du temps pour inclure plus de contenu et plus de profondeur. Ne laissez pas le parfait être l'ennemi du bien - il est préférable de publier de bonnes informations maintenant plutôt que d'attendre d'avoir toutes les informations que vous pensez vouloir y entrer. Une fois que vous avez établi une norme et que vous l'avez publiée dans la nature, vous allez obtenir des commentaires à ce sujet (cas que vous n'avez pas couverts, ambiguïté involontaire, demandes d'exemples supplémentaires, changements dans les appareils pris en charge, ...) , la préparation des commentaires vous aidera à le mettre à jour de manière à mieux répondre aux besoins des utilisateurs de ce document.
Un PowerPoint ou Word statique ou tout autre type de document n'est certainement pas la bonne façon de formater votre sortie. Comme vous l'avez déjà identifié, vous souhaitez que ce document soit mis à jour à l'avenir. L'utilisation d'un document statique présente un risque élevé que quelqu'un obtienne des informations obsolètes car il a reçu une ancienne version du document par courrier électronique. Au lieu de cela, votre ligne directrice devrait avoir un domicile quelque part sur votre réseau interne auquel tous ceux qui en ont besoin y ont accès, et vous devez envoyer le lien vers cet emplacement à toute personne qui le demande. Un wiki ou un site Web interne ou une autre méthode peut répondre à ce besoin. Pour mon équipe actuelle, notre méthode de partage des normes est un site Web reposant sur un Drupal backend, car un tel système de gestion de contenu permet une mise à jour facile. Comme il s'agit d'un document d'entreprise qui pourrait contenir des informations sensibles concernant les projets futurs de votre entreprise, vous devez vous assurer que son domicile respecte les directives de sécurité de votre entreprise, ce qui empêche probablement tout ce qui se trouve dans le cloud public comme Google Drive ou Dropbox. donc sa page d'accueil devrait inclure des moyens de le trouver par des noms qui ne sont pas nécessairement celui que vous avez fini par lui donner ("UI guidelines", "UX guidelines", "website standards", ...); cela exclut également probablement son la maison étant dans le cloud public.
Beaucoup dépendra de la maturité de l'expérience utilisateur dans votre organisation. Considérer:
les directives d'interface humaine iOS sont bonnes. J'aime également les directives de l'expérience utilisateur de la BBC dans lesquelles elles montrent non seulement les contrôles d'interface utilisateur standard mais aussi la vue d'ensemble. Le document vend également l'idée derrière une bibliothèque de composants commune. http://www.bbc.co.uk/gel
Nike a nommé sa bibliothèque de composants "NikeOs". Vous pouvez en voir de petites parties sur ce site de portfolio: http://www.publichue.com/
Power Point pourrait fonctionner comme une livraison initiale mais considérez si l'approche du projet Twitter bootstrap n'est pas meilleure. Tout est expliqué avec du code frontal en direct. C'est une manière beaucoup plus convaincante que une livraison finale. Le client pourrait interagir avec les composants et avoir une bonne compréhension de la façon dont il se comportera et les programmeurs pourraient simplement saisir les pièces dont ils ont besoin. enregistrement sans avoir besoin de recréer le truc. http://Twitter.github.com/bootstrap/
Lorsque nous avons réalisé des manuels d'identité numérique, nous avons divisé le document en ces chapitres:
Pour en savoir plus sur l'utilisation d'un projet Web gigantesque, lisez le livre "Modular Web Design: Création de composants réutilisables pour la conception et la documentation de l'expérience utilisateur" par le talentueux Nathan Curtis. http://www.Amazon.com/Modular-Web-Design-Components-Documentation/dp/0321601351/ref=sr_1_1?ie=UTF8&qid=1358333546&sr=8-1&keywords=modular+web+design