De nombreux utilisateurs professionnels et clients pensent généralement que, lorsque l’ apparence est complète, elle est presque complète. Comme vous le savez probablement, c'est loin de la vérité. On peut l’avoir beau, mais sans back-end et certains utilisateurs pensent qu’il faut 80% du travail pour le rendre beau, pas 20% ( ou l’autre 80% ).
D'innombrables développeurs peuvent raconter des histoires horribles à ce sujet: faire une maquette des pages dans Microsoft Word à l'aide de captures d'écran d'un autre outil, et le client affirmant: "Alors, vous avez presque terminé?"
Vous devez ajuster le temps pour que toutes les parties soient terminées quand c'est fait. Essayer de faire tout le back-office en premier et ensuite tout le front-end amènera l'utilisateur final à penser que vous ne faites rien et à vous demander pourquoi vous êtes payé alors que rien ne prouve rien. D'un autre côté, front-end en premier, vous trouverez l'utilisateur final en train de faire des changements insidieux et de consommer tout notre temps.
Le pire des cas avec un «un d'abord et l'autre» est lorsque vous arrivez à l'autre partie, vous constatez que cela ne correspond pas du tout au design.
Ainsi, construisez les deux. Montrez les progrès dans le front-end, faites-le travailler avec ce que vous construisez. Dans de nombreux cas, c’est une bonne idée de fournir des versions incrémentielles et de vous assurer que vous réalisez ce que le client veut (cela entre dans Agile). Rester trop longtemps sans «progrès visibles» peut nuire à la relation client (il s'agit dans les deux cas de «tout semble être fait tôt» et de «rien ne se fait jusqu'à la fin» - il est difficile pour le client de voir le cadre en cours d'écriture ou l’unité des tests ou la désinfection des données en cours).
Joel a écrit à ce sujet dans The Iceberg Secret, Revealed :
Corollaire important deux. Si vous montrez à un non-programmeur un écran doté d'une interface utilisateur 100% belle, ils penseront que le programme est presque terminé.
Les personnes qui ne sont pas des programmeurs ne font que regarder l'écran et voir des pixels. Et si les pixels ressemblent à un programme qui fait quelque chose, ils se disent: "Oh, ça alors, est-ce que ça pourrait être plus difficile de le faire fonctionner?"
Le gros risque ici est que si vous commencez par simuler une interface utilisateur, probablement pour pouvoir engager des conversations avec le client, tout le monde va penser que vous avez presque fini. Et ensuite, quand vous passerez l'année prochaine à travailler «à couvert», pour ainsi dire, personne ne verra vraiment ce que vous faites et pensera que ce n'est rien.
Ceci est encore répété dans l'article de blog Ne donnez pas à la démo le look Done qui contient ce graphique utile:
Notez ici que les deux options reflètent généralement les options suivantes: "faites-le fini" (et attendez-vous à ce que vous le fassiez bientôt) et "faites le backend" (et le client craint que vous ne respectiez pas l'échéance).
Comment «fait» quelque chose ressemble devrait correspondre à comment «fait» quelque chose est.
Tous les développeurs de logiciels ont vécu cette expérience plusieurs fois dans leur carrière. Mais les outils de publication assistée par ordinateur entraînent les mêmes problèmes pour les rédacteurs techniques: si vous montrez un brouillon parfaitement typé et formaté, il le considère comme plus abouti que vous le souhaiteriez. Nous avons besoin d'une correspondance entre ce que nous sommes et ce que les autres perçoivent comme nous sommes.
Cet article soulève également un point important sur le type de commentaires que vous obtenez avec différents niveaux de cuisson de l'interface utilisateur. Si vous avez quelque chose qui semble complet, vous aurez plus de chances de recevoir des commentaires sur «pourriez-vous changer la police» que sur «cette disposition ne fonctionne pas - il y a trop d'onglets».
Pour ceux qui se battent avec cela dans le monde Java Swing, il existe une apparence appelée " serviette" qui permet à l'interface utilisateur de ne pas paraître complète (même si c'est le cas).
La clé ici est de faire en sorte que cela ne look fait. Avoir l'interface utilisateur complète est un signe pour de nombreux utilisateurs que l'application est complète (même si ce ne sont que quelques pages statiques sans aucune logique derrière ou quelque chose de construit dans un constructeur d'interface).
Lectures complémentaires (et liens de l'article):
