Conception responsive : obtenir une validation sans maquettes
Par Matt Griffin
Si vous concevez des sites Web, il y a des chances pour que vous ayez déjà réfléchi à la question des différentes étapes d’un processus de conception adaptée aux différentes largeurs d’écrans — et vous en avez sûrement conclu qu’ajouter une maquette pour chaque point de rupture était une approche ni durable ni efficace.
Du moins, c’est ce qui s’est passé dans mon entreprise — Bearded — où pendant des années nous avons créé des sites Web à l’aide de Photoshop ou d’Illustrator, fait valider ces maquettes par nos clients, puis recréé ces designs à l’aide de CSS.
Ce temps est révolu. Il y a quelques mois, nous avons arrêté de fabriquer des maquettes constituées d’images statiques pour nous mettre à concevoir avec du code. L’idée n’est pas nouvelle — Andy Clarke préconisait déjà de concevoir directement dans le navigateur en 2008. Mais nouveauté ou pas, vous ne savez peut-être pas toujours par où commencer — ou bien vous vous sentez complètement perdus à l’idée d’abandonner l’approche sur laquelle vous vous êtes longtemps reposés.
Mais n’aie crainte, gentil lecteur, et jetons plutôt un œil à notre nouveau procédé de conception pour le Web sans maquette et voyons comme il est facile de se débarrasser de Photoshop et de prendre un nouveau départ avec notre vieil ami le navigateur Web.
Parlons processus
Avant d’aborder le design, nous travaillons avec nos clients pour définir et hiérarchiser de manière précise l’information qui figurera sur le site. Ma première question est simple : pourquoi avez-vous besoin d’un site Web ? Je demande ensuite : quels sont vos objectifs et que recherche votre public ? Les réponses à ce type de questions nous aident à définir les fonctionnalités et la hiérarchie de l’information du site.
Hiérarchie, hiérarchie, hiérarchie
Une fois que nous avons bien compris la finalité du site Web dans son ensemble, nous appliquons cet objectif à quelque chose de précis et de concret, comme la page d’accueil. Avant même de commencer à prototyper, nous pouvons déjà exprimer la hiérarchie de l’information de notre site de la manière la plus simple qui soit : sous forme d’une liste numérotée. Pour un client récent, l’Association américaine des soins à domicile (AAHomecare), nous sommes en gros arrivés à la liste suivante pour la page d’accueil :
- L’identité de la marque (brand statement) : elle évoque l’émotion primaire du design. Elle ne véhicule pas d’information détaillée, mais fait ressentir aux utilisateurs ce que représente AAHomecare et les aide à s’identifier à l’organisme.
- Une section à contenu variable : sélectionnée par les administrateurs du site, cette zone fera remonter des éléments tirés de l’ensemble du site comme des évènements, des pages, etc.
- La navigation du site : elle permet aux utilisateurs de trouver le contenu qu’ils recherchent.
- Devenir membre : un bref aperçu des avantages à être membre de l’association AAHomecare, ainsi qu’une invitation à s’enregistrer.
- L’agenda : un flux d’évènements à venir contenant des informations importantes et des liens vers le calendrier et le détail de ces évènements.
- Annonces : flux d’évènements récents issus de différentes sources comme le blog, Twitter ou des lettres d’informations, avec des liens vers les articles originaux le cas échéant.
- Le pied de page : il contient quelques liens pour accéder aux mentions légales, aux entreprises partenaires et aux pages sur les réseaux sociaux, ainsi que les coordonnées et les informations de copyright.
Nous avons créé une hiérarchie de l’information de premier niveau pertinente pour la page d’accueil, sans prendre encore la moindre décision concernant la présentation. Au-delà de la question de l’aspect final de la page d’accueil, nous savons au moins que si les informations sont bien présentées, ce sera bénéfique pour l’organisme et les utilisateurs du site.
Ne faites pas attention à cette maquette, l’autre est en HTML
Maintenant que nous avons compris quels seront le contenu et les priorités du site, notre première étape visuelle est de créer des maquettes. Mais comme vous l’avez peut-être déjà remarqué, manipuler du texte dans un fichier Photoshop peut être chronophage et frustrant.
Mais vous savez ce qui est vraiment génial pour mettre en forme du contenu tout en restant fidèle à sa hiérarchie ? Vous l’avez deviné : HTML et CSS ! Laissons donc Photoshop prendre un repos bien mérité, ouvrons notre éditeur de texte préféré et un navigateur moderne – comme Webkit – et commençons à enrichir notre contenu à l’aide de balises sémantiques en adoptant une approche mobile-first, c’est à dire en pensant d’abord aux mobiles.
Quand vous travaillez avec quelques centaines de pixels de largeur seulement, les priorités deviennent plus évidentes et vous êtes bien obligé de prendre des décisions difficiles. Vous allez souvent vous poser la question : « Ai-je vraiment besoin de mettre ça ici ? ». En vous focalisant en priorité sur le mobile, vous pouvez avoir ces discussions avec les clients en amont et de manière plus efficace. Et plus tôt vous pourrez vous débarrasser du surplus d’information, plus vos utilisateurs vous en seront reconnaissants plus tard.
Une fois notre hiérarchie pour le mobile clairement définie, il est alors temps d’élargir progressivement la fenêtre de notre navigateur et d’envisager les décisions relatives à une mise en page plus complexe. Chaque fois que les choses commencent à casser pour une certaine largeur, nous pouvons ajouter une nouvelle media query pour adapter la mise en page.
Chez Bearded, pour nous aider à concevoir des mises en page dans le navigateur, nous avons développé un système de grille réactive qui nous permet d’imbriquer rapidement des colonnes en CSS (ou plus exactement avec Sass et Compass). Avec de simples mixins mis à notre disposition, nous pouvons rapidement et facilement tester différentes mises en page qui s’adapteront aux différentes largeurs d’écran sans trop se creuser la tête.
À ce stade, nos maquettes en HTML/CSS présentent plutôt bien. Et puisque nous travaillons avec le même média (du code et un navigateur) tout au long du processus, nous allons bien entendu pouvoir faire évoluer nos maquettes en livrables finaux.
Petite maquette deviendra design de site
C’est à ce moment-là que nous mettons temporairement notre HTML de côté pour définir quelques styles significatifs (proches des planches tendances de Samantha Warren ou des prototypes de style de Sparkbox).
En général, il s’agit d’une petite planche Photoshop qui reprend la typographie utilisée dans les maquettes et où nous commençons à jouer avec la couleur, les textures et les images. Une fois ces éléments visuels définis, nous pouvons les utiliser pour enrichir notre maquette afin qu’elle commence à ressembler à un site Web.
Plus nous ajoutons d’éléments visuels, plus nous avons tendance à faire des allers-retours entre nos éditeurs de texte et Photoshop. Mais Photoshop n’est plus notre outil de conception de base, plutôt un carnet de croquis. Avons-nous besoin de modifier notre typographie jusqu’à la perfection ? Sûrement pas. Ne pouvons-nous pas simplement importer une capture d’écran du navigateur dans Photoshop pour travailler sur un nouvel arrière-plan pour le site ? Bien entendu ! Pas envie de montrer ce PSD brouillon et mal fichu à un client ? Pas de problème : rien ne vous y oblige.
Non seulement cette méthode participe à une approche de conception basée sur le contenu, mais elle nous permet d’élaborer quelque chose d’utile pour le produit final. Le HTML que vous avez créé pour votre maquette de conception indiquera aux développeurs le genre de code que devra produire le CMS. Et si tout le monde a bien fait son travail, la CSS que vous êtes sur le point d’écrire pourra être utilisée sur le site final avec des ajustements minimes.
Fini de perdre des après-midi entiers à triturer des pixels dans Photoshop pour faire quelque chose de parfait que vous finirez de toute façon par devoir jeter pour le réécrire en CSS. CSS est plus efficace pour certaines choses alors que pour d’autres, le rendu sera plus rapide dans Photoshop : choisissons donc les outils les mieux adaptés sur le moment.
Mais au final, tout cela finira dans un navigateur. C’est comme cela que nous le concevons et c’est comme ça que nos clients le voient.
La peur empêche de raisonner correctement
Je vous entends dire d’ici : « Mais au fait, et les clients ? Comment faire rentrer notre processus actuel de validation dans ce nouveau monde sans planches statiques ? ». Bonne question, je vous remercie de l’avoir posée.
Signez ici
Il s’avère qu’envoyer des prototypes conçus pour un navigateur aux clients est vraiment simple. Il suffit de leur envoyer une URL par e-mail. Les clients peuvent ouvrir les pages conçues dans différents navigateurs, sur différents appareils, les redimensionner, naviguer et cliquer sur les liens et tester les comportements au survol. Au lieu de demander à nos clients d’imaginer que l’image est un site Web, nous leur montrons… un site Web.
Nous affectons toujours une URL permanente au projet, à laquelle nous ajoutons le suffixe /v1, comme pour aafh-css.heroku.com/v1. A partir de là, la première version ne change plus, et les modifications ultérieures sont postées sur leur propre URL comme aafh-css.heroku.com/v2. Et ainsi de suite jusqu’à parvenir à une version validée.
Puisque chaque version a sa propre URL permanente (nous utilisons l’hébergement gratuit chez Heroku pour des environnements non destinés à la production comme ceux-ci), nous pouvons convenir d’un nombre de révisions dans nos contrats, de la même manière qu’avec les maquettes statiques. Si le projet a besoin de plus de modifications que prévu, il est toujours temps de discuter l’allocation d’heures supplémentaires au projet.
Cela permet aussi à tout le monde de facilement revenir sur chaque étape à tout moment. Une fois les révisions terminées, les clients reçoivent le même formulaire à signer qu’à l’accoutumée. Sauf qu’au lieu d’un nom de fichier, les designs finaux sont identifiés par leur URL permanente de version.
Bon, j’imagine que vous vous demandez si vos clients accepteront ce nouveau procédé. Chez Bearded, nous n’avons eu que des réactions positives jusqu’à présent. Notre interlocuteur chez AAHomecare en a même publié un tweet à ce propos. Je ne sais pas pour vous, mais c’est la première fois que j’ai vu un client dire sur Twitter qu’il aimait le procédé de validation du design. Donc voilà. On peut parfaitement valider sans maquettes graphiques statiques. C’est flippant, hein ?
Envoyez cette partie à votre chef de projet
« Oui mais et le budget ? vous dites-vous. Les modifications ne vont-elles pas prendre plus de temps ? Et si le client déteste et qu’il faut tout refaire ? »
Cela peut arriver. Mais cela peut également arriver avec une maquette Photoshop, non ? Et même si nous devions repartir de zéro pour le look and feel, cela voudrait dire qu’au moins le HTML et la mise en page sont bons. Et c’est vrai qu’avec CSS (et particulièrement avec Sass) , il arrive très souvent qu’éditer du code soit bien plus rapide que de modifier un fichier Photoshop. Prenons par exemple le changement de la couleur des liens du texte ou la sélection de polices de caractères pour l’ensemble du site. Plus rapide avec CSS ou avec Photoshop ? Yep. Tope-là CSS !
Par chance, ma première intuition s’est avérée exacte jusqu’ici. Avec AAHomecare, notre processus de conception a pris plus de temps que nous avions estimé – environ 35 % de plus. Pas si mal pour une méthode de travail toute neuve, je trouve. En revanche, nous avons passé deux fois moins de temps que prévu sur les CSS. Tous comptes faits, le projet s’est révélé plus efficace et plus rentable que prévu. Je sais que votre chef de projet va se réjouir à cette idée.
Concevoir c’est coder et coder c’est concevoir
Tous ces changements dans notre manière de travailler font que nos rôles sont moins clairement délimités. Si nos designers écrivent du CSS, où finit le design et où commence le développement front-end ?
Même si les rôles se mêlent davantage, rien ne remplace l’expertise. Les développeurs front-end peuvent collaborer avec les designers tout au long du processus. Ils passent tout en revue, remanient le code redondant ou trop complexe et suppriment les styles résiduels. Quand ils tombent sur des problèmes, nos développeurs tiennent un journal des bonnes pratiques que les designers consulteront plus tard, de manière à ce qu’ils progressent en développement et qu’ils évitent de reproduire les mêmes erreurs à l’avenir.
Nos designs de départ auront aussi des caractéristiques et des approches qu’il nous faudra raffiner, sans oublier l’amélioration des interactions que nous avons gardée pour plus tard. Donc non seulement notre procédé de conception a davantage recours au développement mais notre façon de développer devient plus liée au design. Comme nous travaillons davantage tous ensemble, nous apprenons les uns des autres sur nos domaines d’expertise respectifs et formons une équipe plus cohérente. De ce que j’en ai vu, cela se traduit par de meilleures productions pour Internet.
À ce niveau de collaboration, on a vite fait de se marcher sur les pieds, c’est pourquoi nous utilisons Git pour la gestion des versions. Git permet à plusieurs personnes de travailler ensemble sur un dépôt central de code, de résoudre des conflits et d’annuler des changements si nécessaire. Même si la technologie a du bon, souvent un simple « Eh attention, je suis en train de bosser sur la CSS du calendrier » est bien utile — surtout dans un environnement où la collaboration et la fluidité sont la norme.
À vos marques, prêt, implémentez !
Comment perdre moins de temps sur des produits jetables ? Comment rendre les heures que nous passons devant un ordinateur plus utiles et nos productions plus efficaces ? Tout cela fait partie d’une même problématique.
Le design réactif nous offre l’opportunité de repenser entièrement notre approche globale de la conception pour le Web. Nous pouvons arrêter de concevoir des « sites Web » et des « sites mobiles ». Nous pouvons créer des systèmes de contenu souples : des ensembles de règles qui définissent la manière dont notre contenu sera présenté selon le contexte.
C’est difficile de repenser sa manière de travailler et cela peut vous paraître ambitieux, voire intimidant. Mais au final un obstacle reste un obstacle. Il peut être franchi. Internet changera, que vous le vouliez ou non, et nous devons nous y adapter.
Et puis honnêtement, vous ne commenciez pas à vous ennuyer de toute façon ? Faisons quelque chose de mieux — pour nos processus de travail, pour nos utilisateurs et pour nos clients. Et faisons-le maintenant.
http://www.alistapart.com/articles/responsive-comping-obtaining-signoff-with-mockups/