La meilleure façon de fournir une "trousse d'outils de maquette" à l'équipe d'ingénierie?
J'ai récemment assumé la responsabilité de changer la culture du design dans une entreprise très axée sur la technologie et les fonctionnalités. (Notre "produit" est un portail Web que les clients utilisent pour gérer le cycle de vie des certificats numériques)
Actuellement, notre "équipe technique" (ingénieurs logiciels et propriétaires de produits) crée des maquettes de nouveaux flux de tâches dans Excel en prenant des captures d'écran de l'interface utilisateur existante et en dessinant des formes/en prenant des notes sur le dessus. Je pense que cette pratique informe le produit final et je voudrais m'en éloigner.
Je prévois d'embrasser les éléments Twitter Bootstrap UI dans une refonte à venir et je voudrais limiter le processus de maquette à ces seuls éléments (c'est-à-dire pour que l'équipe technique ne puisse que créer de nouvelles tâches) flux utilisant ce groupe de fonctionnalités d'interface utilisateur)
Mon plan vague est de fournir les actifs sous forme d'images bitmap (bien que je les ai également en tant que vecteurs) avec quelques modèles de grille de mise en page généraux, et de recommander un logiciel dans lequel tous devraient fonctionner (par souci de cohérence).
Mes questions sont donc:
Comment puis-je fournir au mieux cette boîte à outils de maquette?
Suis-je simplement anti-Excel, et dois-je simplement les laisser s'en tenir à ce qu'ils savent?
PowerPoint serait-il un meilleur outil dans ce cas (comme un exemple de logiciel pouvant être utilisé pour la mise en page et qu'ils ont déjà et utilisent déjà?
Vaut-il la peine de faire l'effort et d'essayer de les amener à modifier leur flux de travail et à utiliser un outil plus spécifique à la tâche, et qu'est-ce que cela pourrait être?
(Je dois souligner qu'ils sont tous des anglophones non natifs, c'est donc une considération)
J'ai rencontré des prototypes Excel dans le passé, donc je comprends pourquoi il peut être nécessaire de fournir une boîte à outils de maquette. Rahul a raison, vous devez réfléchir à la finalité des prototypes/maquettes, puis décider de l'outillage que vous utilisez.
L'idée de fournir un ensemble d'éléments peut améliorer les maquettes au début, car en ce moment, l'équipe d'ingénierie se déchaîne avec Excel. Bien que dans une perspective plus longue, je suggère de décider d'un certain processus de prototypage et de l'outil correspondant.
Généralement, des maquettes peuvent être faites dans n'importe quel outil. Il est important que les gens se nourrissent à l'aise avec cet outil. Sinon, cela limite leur créativité pour la tâche à accomplir. Excel est vraiment très utilisé, je suppose que c'est pourquoi les gens commencent à prototyper avec lui. Bien qu'il existe des outils vraiment faciles pour des maquettes simples disponibles. Ces outils n'exportent pas de motifs brillants plutôt qu'un aspect filaire. C'est idéal pour définir les fonctions et les interactions, décider des champs de boutons, lister dont vous avez besoin. Une fois que vous vous êtes mis d'accord, vous pouvez commencer par la conception visuelle.
Les maquettes ne sont pas des livrables, ce sont des documents destinés à faciliter la communication entre les membres de l'équipe. Je recommanderais donc d'aborder cela comme un problème de documentation plutôt que comme un problème de maquette.
Les propriétaires de produits voudront probablement continuer à décrire les fonctionnalités et les flux dans les outils qu'ils connaissent. Puisque vous utilisez simplement ces documents pour faciliter la communication, ce n'est pas grave s'ils utilisent Excel. Tout ce qui fonctionne pour eux qui les aide à communiquer leurs intentions et leurs attentes.
Cependant, les ingénieurs sont parfaitement capables d'utiliser HTML et CSS. Je recommanderais donc de les aider à voir les maquettes dans le cadre d'un processus de conception et de les amener à les mettre en œuvre en HTML dès que possible. Cela améliore également la communication car vous disposez alors d'un document (un prototype HTML) dont vous pouvez discuter avec les parties prenantes. Surtout dans le cas des flux de tâches, cela peut être très important. Vous devriez entrer dans cette phase rapidement plutôt que de languir dans le domaine des feuilles de calcul Excel et des images de choses.
Enfin, ne limitez pas l'équipe à utiliser uniquement des éléments d'interface utilisateur dans Bootstrap. Bootstrap est un point de départ, pas une destination. Il est destiné à vous aider bootstrap votre environnement afin que vous n'ayez pas à vous soucier de styliser visuellement quelque chose. Il est idéal pour les équipes d'ingénierie qui n'ont pas accès à un concepteur visuel et ne veulent pas quelque chose de peu attrayant. Il ne s'agit pas d'un ensemble d'éléments d'interface utilisateur normalisés qui dictent les restrictions d'un produit.
Au lieu de cela, votre responsabilité est de déterminer une bibliothèque de contrôles d'interface utilisateur pertinents et de créer une documentation qui décrit comment vous recommandez de les utiliser. Mais l'équipe devrait être libre de sortir de ces directives, sinon vous risquez de les forcer à abuser de certains contrôles pour répondre aux souhaits des propriétaires de produits qui ne correspondent pas.
Si vous cherchez des outils spécifiques, il y en a quelques-uns que je peux recommander, mais je ne pense pas que vous devriez chercher des outils au départ; vous devriez chercher à améliorer le processus de conception et de communication dans votre équipe. Les outils que vous utilisez sont secondaires.
Si vous recherchez une boîte à outils pour créer des prototypes ou des maquettes basées sur Twitter Bootstrap, je vous recommande d'utiliser les composants de l'interface utilisateur Keynotopia pour PowerPoint. Vous pouvez en télécharger gratuitement ici: http://keynotopia.com/bootstrap/