À quel moment le wireframing interactif devient-il superflu?
À quel moment le wireframing interactif devient-il superflu? Quelle partie du site devez-vous vraiment créer (à l'aide d'outils tels qu'Axure), avant de pouvoir l'appeler un prototype fonctionnel?
Travailler sur un très grand site, dans des délais serrés, et je commence à considérer que l'exigence de créer un prototype filaire complet pourrait entraîner un retard inutile dans le projet.
Une fois les modèles d'interaction et les normes définis, et les pages/flux clés terminés, est-il nécessaire de fournir chaque page?
C'est une bonne question que je me pose avant chaque session de prototypage.
Quelques réflexions:
- N'essayez pas d'inclure chaque page mais incluez tous les modèle.
- Bien que la plupart des outils de prototypage aient la capacité de démontrer des interactions riches si vous pouvez annoter un outil statique avec un lien vers un exemple, vous vous épargnerez des heures.
- Utilisez/adaptez les bibliothèques de widgets lorsque cela est possible - il existe de nombreuses bibliothèques pour Axure par exemple.
- Laissez les histoires d'utilisateurs clés conduire le niveau de détail - si une histoire clé nécessite l'utilisation d'un outil spécial, il pourrait être utile d'ajouter plus d'interactions.
- Faites rédiger les pages statiques et annotées avant de travailler sur les interactions - cela réduit le risque d'arriver à la date limite avec des omissions majeures.
En fin de compte, le wireframing interactif devient redondant si l'équipe en aval n'a pas/n'a pas besoin d'interagir.
Quelques-uns ont déjà suggéré que les types de page/modèles/mises en page uniques devraient être le principal objectif. Dans mon travail, j'ai récemment essayé de changer notre attitude envers les maquettes. Auparavant, la conception signifiait un ou deux exemples d'écrans, mais cela laissait toujours aux développeurs le soin de prendre des décisions de conception.
Pour moi, c'est le moteur de la distance que vous devez parcourir avec les wireframes (interactifs ou autres). Lorsque le développement commence, les développeurs ne devraient pas prendre de décisions de conception - ils devraient avoir tous les artefacts dont ils ont besoin pour construire les écrans en fonction des résultats de la phase de conception. Si vous réalisez des wireframes et/ou des prototypes, vous n'avez pas couvert tous les composants potentiels nécessaires à votre site ou système, le processus est incomplet.
Cela dit, les moteurs commerciaux du montant que les clients sont disposés à payer et à attendre l'emportent généralement sur tout scénario du "monde idéal", ayant suffisamment de temps et de flexibilité pour faire la conception au niveau que nous voulons vraiment.
Il y a une ligne fine où la documentation passe d'une base solide à un fardeau pour le projet. L'endroit où cette ligne tend à varier dépend des spécificités du projet et des membres de l'équipe. À mon humble avis, le plus souvent, il vaut mieux se tromper pour obtenir des éléments dans le code de travail plus tôt que pour s'assurer que chaque élément est entièrement documenté sous une forme de filaire.
Pour répondre à la question posée - les wireframes "interactifs" sont redondants dès que vous commencez à les faire. Dès que vous créez vos artefacts de conception (wireframes, maquettes, tout autre chose comme ça), vous perdez du temps sur quelque chose que vous devrez reconstruire lorsque le système réel sera construit.
La seule exception que je vois à cela est si vous allez faire des tests utilisateur réels avec les wireframes (et pas seulement montrer les wireframes aux gens d'affaires). Et même en faisant cela, il n'est pas nécessaire de fournir des wireframes pour CHAQUE page du système. Le plus souvent, vous découvrirez que votre site ne possède vraiment qu'un petit nombre de TYPES de pages uniques, et ce sont tout ce dont vous avez vraiment besoin pour filaire.
Les grands avantages du wireframing sont de permettre aux clients/utilisateurs de comprendre plus facilement comment le site fonctionnera (plus facile que de lire la documentation écrite de toute façon) et de réduire les risques en résolvant comment les zones grises de l'application fonctionneront aussi rapidement et à moindre coût que possible ( plus rapide et moins cher que de le construire pour de vrai, puis de faire des tests d'utilisabilité à la fin).
Cela dit, vous pouvez essayer de réduire le gaspillage en filaire directement en HTML/JS afin que vos filaires deviennent vos fichiers HTML finaux une fois que vous ajoutez les derniers éléments de conception visuelle. Le wireframing est un peu plus lent de cette façon, mais c'est quelque chose qui devient plus rapide/plus facile avec la pratique.