Dans cet article, Keith Robinson remet en question l’utilisation de maquettes schématiques (wireframes) dans le processus de création web.
Tout ceux qui ont déjà effectué l’exercice le savent: les wireframes sont un outil extrêmement utile mais aussi dangereux. Les clients ne comprennent pas toujours la différence entre un wireframe et une maquette graphique et s’attendent souvent à ce que le créatif ne fasse qu’ajouter de la couleur aux maquettes schématiques fournies par l’architecte de l’information.
Erreur… De mon côté, je demande aux créatifs avec qui je travaille d’interpréter les maquettes schématiques, de les “challenger” et d’y apporter quelquechose, pas de se contenter de rendre le tout joli.
Le processus alternatif proposé par M. Robinson s’appelle “Diagramme de description de page”. C’est une représentation en texte seulement des objectifs de communication d’une page web. (Exemple à télécharger, format pdf). Exercice intéressant mais je doute qu’il soit satisfaisant pour tous les clients.
Par contre, je pense que ce genre de diagramme pourrait effectivement faire partie de l’analyse de la problématique de communication du client et ainsi être inclus dans un cahier de charges de format léger.
Je crois aussi que ce genre de diagramme pourrait faire partie d’une proposition détaillée à un client, sans ainsi “brûler le punch” qui suivra dans le processus d’analyse et de création.
Au lieu de parler de la solution en long et en large, pourquoi ne pas axer la présentation du cahier de charge d’abord par une démonstration visuelle des objectifs de communication du site à venir?
Les maquettes schématiques doivent rester dans le processus itératif de création web mais je crois que ce nouvel outil pourrait très bien les précéder.
Je vais mettre le tout à l’essai dans mon propre processus, on y reviendra…
Since I got back from SXSW and our well received Design Eye for The Idea Guy panel I’ve received quite a few e-mails asking about my use of page description diagrams and how they fit into the design process.
Bon point!
Je pense en effet que produire des wireframes permet d’amorcer la création visuelle avec des bases solides, tout en permettant au client de visualiser son futur site.
Par contre, je trouve que les wireframes sont :
- pas assez descriptifs pour le fonctionnement des éléments. Ils laissent place à l’interprétation… Et les programmeurs ne veulent pas interpréter; ils veulent des énoncés clairs et bien analysés.
- trop dirigeant!? Certains designer regardent les wireframes et ne font “qu’habiller” les boîtes et le texte… Je pense que l’ergonomie et l’utilisabilité se jouent sur deux plans: l’architecture de l’information (but des wireframe, je pense) et le design graphique des éléments.
Conclusion:
Les wireframes devraient être un outils de communication avec les divers intervenants d’un projet (client et développeurs), mais ne devrait pas se limiter à placer des boites avec du texte. Ils devraient servir de base pour les designer, mais devraient être challengés par eux. Le designer à souvent de bonnes idées itout. Et pour les programmeurs, un petite couche de fonctionnel devraient être ajoutée… sans pour autant tomber dans le cahier de charge.
Jay
J’adore les commentaires de ce genre!
Deux petites remarques sur les deux points que tu soulèves à propos des wireframes:
Tu dis que les wireframes ne sont pas assez descriptifs au niveau des fonctionnalités. Je suis d’accord mais ce n’est pas leur rôle non plus. Il faut les inclure dans un cahier de charges qui sera plus détaillé et dont il ne seront qu’une composante. Je t’entend déjà dire “Oui mais Michael, tu n’aimes pas les cahier de charges, tu l’as déjà dit!”. En effet, je n’aime pas les cahiers de charges verbeux, longs et que personne ne lit. De là l’idée de se servir des wireframes comme pièce centrale d’un cahier de charges utile MAIS aussi de les utiliser au bon moment, une fois que le diagramme de description de page sera compris et accepté de l’équipe et du client.
Les wireframes sont quelquefois interprétés comme “trop directifs” par les créatifs. Je ne le pense pas puisque que comme tu le dis, un bon créatif doit interpréter le wireframe sans l’appliquer à la lettre. Par contre, un bon architecte informationnel doit savoir recevoir les suggestions des créatifs (et des programmeurs) pour adapter ses wireframes à leurs suggestions pertinentes pour arriver à un consensus client/équipe de production.
Il ne faut pas oublier que les wireframes, comme tout document relié à un projet web, sont généralement évolutifs et sont des outils et non une fin en soi.
Vraiment, la pertinence des wireframes est vraiment devenu le sujet de discussion par excellence depuis le départ des Nordiques! Pour ma part, je crois fermement qu’il est difficile de s’en passer, ne serait-ce que pour donner au client un “feeling” de ce que sera son site dès les premières étapes du projet. L’approche de Mr. Robinson est fort intéressante mais selon moi encore trop abstraite pour le client. En fait, dans un monde idéal, je fournirais de réels wireframes au client et une description textuelle au concepteur graphique pour éviter que ce dernier ne soit trop rongé par la tentation de simplement “peinturer” la maquette. Mais qui peut se permettre un tel investissement de temps?En passant, le but d’Alain Côté était bon.
À propos de l’investissement de temps, je pense qu’il est souvent nécessaire et qu’on ne réalise pas de bonnes choses en cherchant à épargner quelques dollars qui seront plus tard dépensés en corrections. Un diagramme de description de page pourrait être inclus dans un modèle de cahier de charges en remplacement de bien d’autres choses pour lesquelles un investissement de ressources est fait régulièrement sans réel bénéfice.
Je pense aussi que les diagrammes de description de pages sont un peu abstraits et je pense que leur utilisation à l’interne est indiquée. Plusieurs clients bénéficient effectivement des wireframes, d’où l’idée de les utiliser éventuellement APRÈS quelques diagrammes descriptifs.
Le rôle des diagrammes de description de page serait ainsi de confirmer la compréhension des objectifs de communication et de marketing du client, étape trop souvent négligée au détriment de détails techniques qui serviront à livrer une solution technique impeccable… qui ratera complètement la cible.
Une utilisation d’un “diagramme de description de site” serait probablement plus indiqué et prendrait moins de temps, remplaçant une partie de la rédaction du cahier de charges par une représentation plus visuelle et concise. Les pages principales pourraient aussi être décrites mais la majorité des pages devront continuer à être représentées par des wireframes.
C’est trop facile de mettre le manque de créativité, de sens pratique et de capacité à travailler avec des contraintes sur le dos des wireframes. Un bon concepteur visuel n’est pas censé être paralysé par un wireframe, ce n’est qu’un guide pour lui. C’est comme dire qu’un entrepreneur en construction ne veut pas travailler avec un plan parce que cela brime sa créativité.
C’est donc le travail de l’architecte informationnel que de laisser assez de liberté au concepteur mais c’est le rôle et la responsabilité de ce dernier d’interpréter les informations fournies et d’y amener de la valeur supplémentaire. Cela peut inclure de challenger certaines informations fournies, de les remettre en question pour de bonnes raisons, de modifier certains éléments…
Il ne faut pas oublier que les projets web sont généralement effectués en collégialité et que tous les membres de l’équipe doivent être encouragés à donner leur avis et non seulement d’appliquer aveuglément ce qui est écrit dans le cahier de charges ou sur les wireframes. Trop de projets échouent en raison de gens qui se servent de ce qui est écrit dans un document pour couvrir leurs arrières lorsque le gros bon sens dictait d’agir autrement.
Trop de choses changent en cours de projet pour que les participants se fient à un document statique qui origine du début du projet et qui n’évolue que très peu. Se dissimuler derrière le fait que les wireframes sont trop directifs, ou que le cahier de charges disait ceci ou cela, quand le bon sens est en jeu, est vraiment une excuse à l’incompétence et la paresse.
PS: Il ne faut JAMAIS oublier que le but refusé par Ron Hoggarth, y’était bon!