Aller au contenu principal

Prototypage HTML

Publié le 14 avril 2014

Ici, chez LunaWeb, nous sommes friands de prototypes. On en fait beaucoup. Pour ne rien vous cacher, on les fait systématiquement, en fait. C'est devenu un passage obligé pour assurer une intégration proprette et sans mauvaise surprise.

Parfois même, simplement pour tester une faisabilité, afin de ne pas trop s'avancer auprès du client et lui vendre du rêve inaccessible. Le prototypage web évite aussi les frustrations au sein de l'équipe, le web designer ne souffrira pas de voir ses idées rejetées parce que difficilement réalisables ; et l'intégrateur ne passera pas son temps à s'arracher les cheveux parce qu'une maquette n'est pas intégrable.

S'agit-il d'un rêve inaccessible ? Non, il faut juste se donner le temps de bien faire les choses et d'inclure cette étape dans son process de conception Web.

Nous avons défini trois types de protos (oui, le jeu de mot était gratuitement inutile), parfois tous présents au sein du même projet, en fonction des problématiques que l'on rencontre. Pour autant, tous permettent de mieux anticiper sur le produit final, tous peuvent faire l'objet de tests utilisateurs et tous font avancer un peu plus la pertinence de la conception.

Pour plus de classe, et pour pouvoir briller un peu en société, nous donnerons à ces 3 types un nom anglais.

Le prototype "Grey Box"

C'est le proto dans son plus simple appareil. Des boîtes grises, du lorem ipsum et des placekitten (emplacements d'images) partout.

L'essence même du prototype : pouvoir intégrer rapidement des éléments, afin de tester leur faisabilité.

Pour évaluer une mise en page audacieuse, ou dans le but de tester le rendu responsive d'une interface, le prototypage en boîte grise permet très rapidement de déterminer la faisabilité d'un placement / d'une interaction / d'une mise en page.

C'est, par exemple, ce que nous avons fait pour les Laboratoires Uriage, partant du "besoin" de découper la structure de page en plusieurs colonnes. Il fallait donc s'assurer qu'en terme d'intégration HTML, la structure responsive n'allait pas poser problème, et nous donner du fil à retordre au niveau de la maintenabilité du code.

Le prototype HTML responsive du futur site d'Uriage

Le prototype "Static"

Le prototype est dit "statique" quand il s'agit d'un site dont les données sont figées dans l'interface, c'est-à-dire pas dynamiquement alimentées par une base de données.

Nous y recourrons dans deux cas de figure :

  • cela suffit amplement pour jauger du rendu final, pas besoin de plus,
  • il faut voir comment l'utilisateur réagit à la nouvelle interface, besoin de vite mettre en ligne.

Dans le premier cas, certains sites sont en effet trop "légers" pour justifier de monter une application Rails, qu'il s'agisse de fonctionnalités ou de budget (parfait pour les sites statiques ou les sites qui sont mis à jour sporadiquement).

Dans le second, cela permet de déployer rapidement une première version du site pour pouvoir traiter les retours au sein d'une application dynamique ; et donc d'améliorer sensiblement l'expérience utilisateur. Le choix d'un prototype déployé en production peut alors s'avérer judicieux.

Plusieurs avantages à cela :

  • il est facile et rapide à intégrer,
  • il ne demande que très peu de maintenance,
  • la mise à jour ne nécessite pas d'interface d'administration en ligne.

C'est ainsi que nous avons déployé en ligne, sous cette forme, la première version d'Infos Securitas, par exemple. L'occasion d'analyser les parcours utilisateurs, remonter des stats de consultation multi-terminal, pour ensuite travailler la conception de certaines fonctionnalités avancées nécessitant un minimum de feedback utilisateur.

Consulter le site responsive Infos Securitas

Le prototype "Ready for App"

Pour ce dernier prototype, on devient un poil plus pointilleux puisqu'on va plus loin que le simple essai de fonctionnalités en boites grises.

L'idée, ici, est d'anticiper au maximum sur le produit fini, afin de pouvoir fournir le maximum d'éléments techniques favorisant plus tard l'intégration dans l'application dynamique. Derrière cela, l'enjeu est double :

  • éviter le travail doublé en phase de production,
  • s'assurer d'une expérience utilisateur identique à celle testée en prototype.

Ne resteront alors que les inévitables ajustements propres à l'environnement de développement.

L'intégrateur est content, le développeur est content. Bref, tout le monde est content.

C'est ainsi que le projet Les Bons Plans de Cerise, par exemple, est passé sans accroc des mains de l'intégrateur à celles du développeur. Tout comme Infos Securitas pendant le développement de la V2. Les éléments étant déjà tous intégrés, il n'y avait plus alors qu'à plonger tout ça dans le bouillon de l'appli dynamique, et le tour était joué !

L'interface du site responsive Groupama Les Bons Plans de Cerise

Et le contenu, dans tout ça ?

Pas de photo sans appareil ! Évidemment, il en va de même pour le prototypage. Concevoir un site Internet sans tenir compte des contenus finaux est strictement improductif ; raisons pour laquelle il convient d'inclure, dans toute la phase de conception, une réflexion autour de l'enchaînement et la nature des contenus.

Peu importe la forme du prototype, il permet dans tous les cas de mieux se projeter sur les besoins du site en contenus, en même temps qu'il renseigne sur le contexte de lecture et d'interactions de l'utilisateur final.

En plus de cela, et c'est très loin d'être accessoire, c'est de loin le meilleur moment pour inclure et partager les objectifs en matière d'optimisation du référencement naturel. Bref, puisque l'on vous dit que c'est bien !

Phase de conception des contenus web lors du prototypage chez lunaweb

C'était (pas) mieux avant

S'il y a encore quelques années on pouvait passer d'une maquette PSD en HTML/CSS sans bouger des oreilles, aujourd'hui le prototypage s'avère être une étape indispensable pour avancer sur un projet de manière sereine. Le responsive, les parallaxes, L'effet Wow, les off-canvas, les dispositifs de jeux e-learning ; sont autant de problématiques d'interface (UI) et d'anticipation des interactions utilisateurs (UX) qui nécessitent de se pencher un peu plus longuement sur leur faisabilité, leur pertinence, et dans le respect des contraintes du projet (rapidité de chargement, optimisation SEO, budget temps imparti...).

Rien de bien compliqué, si l'on prend le temps de bien faire les choses.

Et on aime ça !

Thumbs Up