Les wireframes sont de moins en moins pertinents – et c’est une bonne chose

Selon l’Ux designer, Sean Dexter, avec le temps, il a commencé à trouver que les wireframes étaient de moins en moins utiles.
Étant donné que le terme est défini de façon assez vague, il est probablement important d’être précis.
Bien qu’il existe de nombreux types de prototypes qui examinent les niveaux de fidélité dans différentes dimensions, il s’agit plus de parler de la variante spécifique qui vient le plus immédiatement à l’esprit lorsque on entend le mot wireframe. Il ne s’agit pas d’une esquisse ou d’une maquette entièrement réalisée, mais plutôt des artefacts numériques typiques de l’état « moyen » laissés intentionnellement sans style et faits pour représenter le « squelette » d’une pleine page en noir et blanc. Le wireframe prototypique tente d’être une représentation précise de la mise en page et de l’architecture de l’information tout en évitant intentionnellement la haute fidélité visuelle et parfois aussi la haute fidélité du contenu.

Dans les discussions en ligne et la plupart du temps, on entend que les wireframes sont toujours considérés comme une étape essentielle dans le processus de conception. Cette attitude semble être en déclin, mais on entend encore tout le monde, des concepteurs en début de carrière aux agences leaders de l’industrie, insister sur la nécessité d’une « phase de wireframing ». L’argument ressemble généralement à ceci :

  • Les wireframes mettent l’accent sur la facilité d’utilisation plutôt que sur l’esthétique. Ils empêchent les parties prenantes de faire dérailler les réunions sur des détails non pertinents comme la couleur des boutons, et ils permettent aux tests utilisateurs de se concentrer sur les interactions plutôt que sur les visuels.
  • Les wireframes sont plus rapides à créer. Ils gardent les choses conceptuelles et évitent le risque de trop s’investir ou de s’attacher à une direction particulière.
  • Il y a aussi un argument quelque peu distinct (plus orienté entreprise) en faveur des wireframes comme outil de documentation détaillée des interactions sans le surcoût supplémentaire de la conception visuelle.
  • Enfin, il y a ce métier très branché et à la fois vague de Product Owner, responsable de la maximisation de la valeur du produit, qui n’existe que si la méthode de développement utilisée par l’équipe de conception est agile, qui peut dire qu’il ne lit rien d’autre que des wireframes ou des maquettes pour juger un produit…

Cela ne veut pas dire que tout le monde fait des wireframes mais si quelqu’un admet qu’il ne le fait pas, c’est souvent sur un ton discret. Ils aimeraient les inclure. C’est juste que les contraintes de leur organisation, de leurs parties prenantes ou de leur projet empêchent parfois. Mais l’état d’esprit selon lequel les wireframes sont essentiels et de nombreuses croyances sur leurs avantages peuvent être erronées. Bien que les wireframes sont toujours utiles, de nos jours, ils ne sont utiles que dans des circonstances limitées qui se rétrécissent de jour en jour. Un certain nombre de changements dans la façon de penser et les pratiques de l’industrie contribuent à ce changement et méritent d’être examinés.

L’évolution des méthodologies de développement de produits change la façon dont la conception est faite

Le développement de produits agiles encourage des processus moins linéaires. Au lieu de commencer par travailler sur les éléments fondamentaux de l’ensemble d’un produit et de construire ensuite des couches au-dessus de ces fondations, on se concentre sur la production plus petite et plus fréquente de tranches « verticales » pleinement réalisées.

Cela inclut également la conception entièrement réalisée, ce qui rend important la prise en compte simultanée de l’aspect visuel, de l’architecture de l’information et de l’interactivité. Dans une équipe agile, où votre prochaine itération se fera en quelques jours ou quelques semaines plutôt qu’en quelques mois ou quelques années, la phase de cartographie qui donne si souvent naissance à des wireframes est moins susceptible d’avoir sa place.

Le Lean UX est un changement de processus connexe qui semble également gagner du terrain. Dans le Lean, les artefacts de conception lourds sont minimisés ou totalement supprimés au profit d’une collaboration directe sur le produit lui-même chaque fois que c’est possible. Le Lean apporte également une réfutation à l’idée du wireframe en tant qu’outil de documentation. Il suggère que la disposition des écrans d’un produit réel peut leur servir de documentation. Les artefacts de design que vous créez peuvent plutôt devenir des objets plus temporaires – à mettre de côté dès que l’information qu’ils contiennent existe d’une manière accessible dans le produit réel. D’autres contextes pertinents peuvent encore être documentés, mais seulement au moment de la mise en œuvre ou après.

La convivialité de l’usage et l’architecture de l’information n’existent pas en vase clos.

Au risque d’énoncer l’évidence, la présentation visuelle des éléments d’une interface influe sur la façon dont ils sont perçus. Une liste déroulante qui ressemble à un champ de formulaire peut avoir sa fonction mal interprétée. Un en-tête de menu qui ne ressort pas d’un élément de menu peut être omis. La couleur et le contraste jouent un rôle énorme dans l’orientation de l’attention visuelle. Si vous effectuez des tests d’utilisabilité sur un wireframe, le test va perdre une grande partie de sa valeur lorsque vous finirez par changer l’apparence de l’ensemble. Vous devrez probablement aussi apporter d’autres modifications à la mise en page à ce moment-là pour mieux tenir compte des visuels. Les utilisateurs peuvent être obsédés par les éléments visuels, mais ils n’ont pas tort de le faire, et le fait de tout faire en niveaux de gris ne réduit pas nécessairement ce risque. Les problèmes de convivialité d’usage ou d’architecture de l’information sont mieux exposés par des questions de compréhension et des tests d’achèvement des tâches que par des commentaires verbaux de toute façon. Il est possible d’obtenir des commentaires sur un concept avec n’importe quel niveau de fidélité, à condition de bien définir les attentes et d’être attentif à la façon dont vous sollicitez les commentaires.

Les wireframes sont rarement efficaces pour les parties prenantes

Il peut être incroyablement frustrant de voir une partie prenante se fixer sur la couleur d’un bouton ou d’un texte lors d’une réunion. Mais en évitant intentionnellement les visuels haute fidélité et en mettant du lorem ipsum partout, résolvez-vous vraiment ce problème ? Ou est-ce que vous le reportez simplement à plus tard ? Aimez-vous la basse fidélité parce qu’elle permet aux gens de mieux comprendre les choses et de donner leur avis ? Ou est-ce que cela rend les choses plus difficiles à comprendre pour les autres et que nous aimons cela parce qu’il nous permet de dominer notre expertise sur les autres et d’éviter les critiques ? Si une partie prenante n’est pas intéressée à commenter l’architecture de l’information et se soucie davantage d’autres choses plus proches de son expertise, alors pourquoi essayez-vous de combattre cela ? Vous êtes l’expert en architecture de l’information, pas eux, et tout changement nécessaire à la mise en page devrait devenir clair grâce aux tests avec les utilisateurs.

Il est de plus en plus rapide et facile de se rapprocher des visuels haute fidélité.

Il y a des années, photoshop était le roi du design d’interface utilisateur et tout le monde était dans une course pour voir qui pouvait ajouter la texture la plus détaillée et photo-réaliste à une page donnée. À l’époque, il y avait un argument valable en faveur des avantages en termes de gain de temps des wireframes, mais aujourd’hui, nos outils sont spécialement conçus pour la conception d’interfaces utilisateur (Think Sketch, Adobe XD ou Figma) et rendent la gestion et la mise à jour des styles beaucoup plus rapides et faciles à l’échelle mondiale. Changer la mise en page « après », le style visuel est « fixé » ne devrait pas être plus difficile que de le changer plus tôt. Et pour ceux qui travaillent dans des organisations matures, la combinaison de systèmes de conception et de bibliothèques de composants supportant ces systèmes élimine pratiquement toute excuse. Même si vous n’êtes pas dans une organisation mature, vous avez probablement toujours accès à des kits d’interface utilisateur qui correspondent aux frameworks d’interface utilisateur disponibles pour vos développeurs. Le fait que même l’esthétique la plus complexe visuellement aujourd’hui soit encore relativement simple aide également. Si votre bouton est juste un rectangle bleu avec des coins arrondis, combien de temps gagnez-vous vraiment en le rendant gris intentionnellement ?

Est-ce que le wireframing a du sens ?

C’est possible, dans la bonne situation. Par exemple, vous pouvez créer des wireframes parce que :

⦁ Vous avez vraiment un produit qui sera visuellement complexe (comme un jeu mobile) et vous avez besoin de travailler l’interaction indépendamment d’un processus artistique inévitablement long. Même si c’est le cas, vous pouvez toujours faire de votre mieux pour vous rapprocher du style.

⦁ Vous les utilisez comme un exercice pour aider quelqu’un à se familiariser avec l’architecture de l’information de manière isolée (avec un peu de chance, il s’agit d’une partie ponctuelle plutôt que récurrente du développement de produits réels).

⦁ Vous souhaitez élaborer ou tester une architecture d’information, mais vous dépendez de quelqu’un d’autre pour la conception visuelle (ce qui n’est pas idéal !) ou vous êtes limité d’une manière ou d’une autre par les capacités visuelles des outils à votre disposition, ou par vos propres compétences.

⦁ Vous êtes dans un environnement de cascade ou d’agence désuet et vous n’avez pas encore beaucoup d’autonomie sur votre processus. Ce n’est pas génial, mais ce n’est peut-être pas de votre ressort. (c’est du vécu)

Je suis sûr qu’il y a beaucoup d’autres scénarios et exceptions possibles, mais je dirais qu’ils sont probablement peu fréquents pour la plupart des concepteurs actuels. Si vous considérez les wireframes traditionnels comme une tactique à employer uniquement lorsqu’ils sont vraiment adaptés au problème, alors vous constaterez probablement qu’ils peuvent souvent être évites – et c’est bien ainsi.

Medium

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.