Qu'est-ce qui est le mieux pour partager les "Lignes directrices de conception d'applications d'entreprise et UX"? Une impression, un pdf sur ou un site Web?
Pour un projet à long terme, je travaille sur une partie des directives ux et de conception pour une application d'entreprise. Jusqu'à l'année dernière, ils utilisent un pdf "statique" sur un serveur de fichiers où il devient obsolète et que personne ne l'utilise, à cause de cela. Quelqu'un ici a-t-il de l'expérience avec les plateformes existantes (et qui ne prennent pas beaucoup de temps) pour publier des lignes directrices et les mettre à jour régulièrement? J'aime le format dans lequel Apple et MS y publient des directives, mais cela semble prendre beaucoup de temps.
Je ne pense pas que ce soit spécifique à l'UX. Il s'agit en fait de gestion des connaissances . Il y a tout un écosystème de personnes/produits/services pour ce genre de chose.
Des logiciels comme Wikis comme Confluence, SharePoint, MadCap Flare, Salesforce Sites, Google Docs sont tous des options viables. Cela dépend de vos exigences de sécurité (et autres).
Google: Knowledgeex stackexchange et vous obtenez des hits intéressants.
Je suis d'accord avec Aviva Rosenstein que vous devez concevoir vos livrables comme vous concevez vos projets , en posant des questions comme:
Quel est le public cible? Quels sont leurs besoins? Que faut-il communiquer? Quels sont leurs objectifs?
Pour moi, j'essaie de plus en plus d'influencer notre équipe de développeurs pour adopter les meilleures pratiques/standards d'entreprise. Les développeurs ont beaucoup à faire, beaucoup de contraintes et peu de temps. Donc je me suis concentré sur la livraison de code de travail comme lignes directrices. Cela signifie javascript fonctionnel dans les prototypes HTML qui montrent les modèles d'interaction souhaités. Cela signifie codifier les directives de look and feel dans le CSS.
Cela signifie également que vous pouvez développer des cas de tests unitaires UX basés sur un navigateur à l'aide d'outils tels que Selenium pour vous assurer que vos directives sont respectées. Si vous incluez ce type de test dans le processus de construction, ils sont vérifiés à chaque fois que la base de code change, et les développeurs (et vous) peuvent être avertis automatiquement et instantanément lorsque quelque chose n'est pas conforme aux spécifications.
Travailler sur un guide de style maintenant. C'est en HTML, fonctionnant sur un serveur local. Il y a plusieurs raisons pour le rendre sur le Web: 1. Il est très facile de partager, naviguer et rechercher. 2. Vous pouvez voir les interactions et les comportements tels qu'ils apparaîtront aux utilisateurs. 3. Extraits de code - un guide de style n'est pas très utile aux développeurs, sauf si vous fournissez les fichiers .css, .js et .htm dont ils ont besoin et démontrez leur utilisation. 4. Facilité de mise à jour. OK, la mise à jour d'un sitelet n'est pas aussi simple que de changer un fichier Word, mais l'utilitaire amélioré en vaut la peine.
Lorsque je travaillais au sein d'une équipe de développement chez Oracle, nous avions une politique selon laquelle tous les documents, y compris les directives UX, devaient être en html ... afin qu'ils puissent être facilement partagés et modifiés.
A bien fonctionné.
J'utilise habituellement Axure pour créer des documents liés à l'UX. Il vous permet de générer un site Web très facilement et vous pouvez également montrer l'interactivité de l'interface utilisateur pour démontrer un certain modèle d'interaction. Tout le monde peut facilement accéder au site Web et vous pouvez également fournir un lien vers une page spécifique du site si vous souhaitez communiquer un domaine spécifique. Avoir un guide interactif où vous pouvez essayer un exemple montrant une directive UX est également probablement plus amusant pour les lecteurs des guides.