Le design dans le navigateur est une méthode de conception de plus en plus utilisée pour produire des sites web proches des besoins des utilisateurs. Pour ses détracteurs, cette méthode se limite à ne plus utiliser Photoshop au profit de HTML, CSS3 et Javascript. Le titre de l’article est volontairement provocateur car dans les faits, le design dans le navigateur n’interdit pas d’utiliser Photoshop ou Illustrator pour concevoir les pages. Il faut juste garder à l’esprit que ces logiciels pourraient — dans la plupart des cas — être délaissés au profit d’un simple crayon à papier pour faire un croquis qui sera directement transformé en page web sans passer par la case Photoshop. La suite de l’article est une traduction libre de Throw away Photoshop and be true to your medium de James Weiner (@jamesweiner) paru sur Government Digital Service (GDS).
A GDS, nos équipes sont centrées sur le produit plutôt que sur l’expertise. Faire du Web Design implique de savoir concevoir l’apparence d’un site et de réaliser l’intégration HTML & CSS. Au fil du temps, j’ai trouvé que le design dans le navigateur, — c’est-à-dire coder le design à partir de « rien » — était la meilleure approche. Avec mes collègues, nous avons introduit cette méthode de travail dans les procédés de GOV.UK pour faire face à l’accélération des cycles de développement. Ce rythme de travail impose d’avoir un flux de production aussi fluide que possible entre tous les intervenants.
Quand le design est vraiment orienté vers l’utilisateur, rien n’est jamais terminé. A GDS nous sommes en permanence axés sur la prochaine itération du produit. Ceci nous permet d’être toujours en phase avec les besoins de l’utilisateur. Notre objectif est de sortir une première version utilisable pour tester les hypothèses le plus rapidement possible. Ce qui fonctionne reste en place et ce qui ne fonctionne pas est supprimé, puis nous recommençons un nouveau cycle. Le design dans le navigateur permet cette réactivité.
A GDS, nos projets débutent avec l’analyse d’un besoin suivi d’un crayonné ou d’une maquette plus aboutie dans Illustrator ou Photoshop. Lorsque nous sommes convaincus par une piste, nous attaquons directement la phase de prototypage.
C’est un peu comme lors de la conception d’un nouveau téléphone mobile. On peut dégrossir le travail avec un crayon et du papier pour faire un premier jet en 2D qui pourra être facilement revu et corrigé. Lorsqu’une version plus aboutie émerge on peut attaquer la maquette en volume. Toutefois, il est fort probable que l’on ait besoin de travailler avec du métal ou du plastique dès que possible afin d’exploiter les potentialités des matériaux retenus, en terme de finition, de solidité ou d’apparence. Pouvoir tenir quelque chose de tangible dans ses mains permet de se rendre compte de l’adéquation entre les idées et la réalité du produit.
Sur le web, c’est encore plus simple : on peut tester les hypothèses directement sur le médium. Nous pouvons ainsi tester et faire tester le produit par tous et sur tous les périphériques de sortie disponibles. Tout ce que cela coûte, c’est du temps et des ressources humaines.
Traditionnellement, les équipes qui travaillent dans le digital ont une équipe spécialisée dans le design qui utilise généralement Photoshop, Illustrator ou InDesign et une autre équipe chargée de transmuter ce design en page web avec HTML et CSS. J’ai travaillé ainsi pendant des années, et je me suis aperçu que le manque de porosité entre les équipes avait des effets de bord non négligeables. Si un développeur ne comprend pas la réflexion qui se trouve derrière certains choix de design, il peut passer à côté d’une solution élégante qui préserve l’expérience utilisateur en se laissant guider uniquement par les contraintes techniques.
Chez GDS nous mettons le design, les prototypage et l’intégration dans le même sac grâce à l’utilisation des outils HTML, CSS, Javascript, Ruby On Rails et du support final (le web, via le navigateur). Le design dans le navigateur permet également de faire face très rapidement aux différences de rendu des pages web selon les modèles et les versions. Les échecs arrivent plus rapidement et peuvent être réglés tout aussi rapidement. Par ailleurs, les composants mis en place dans les projets précédents peuvent être réutilisés presque tels quels, ce qui est plus difficile à faire si l’on utilise Photoshop ou illustrator.
Le design dans le navigateur n’est pas forcément la bonne réponse pour tous, mais je pense que c’est une bonne idée de se forcer un peu et d’essayer pour ne pas passer à côté d’une méthode de conception agile.
Traduction libre de l’article Throw away Photoshop and be true to your medium de James Weiner (@jamesweiner) paru sur Government Digital Service.
→ Lire 10 principes de design pour les sites du gouvernement anglais pour aller plus loin.
Joli article, c’est la méthode que j’ai adopté depuis un bon moment déjà.
1) Moodboard, étude des besoins du client.
2) Croquis papier ou via un logiciel de mockup (exemple : Pencil)
3) Ouverture de Scout App (pour Sass & Compass), uWamp pour le serveur puis enfin Notepad++
4) C’est tout 🙂
Je pense même qu’on l’on peut encore alléger :
1) Moodboard,
2) Mockup, Wireframe avec HTML & CSS
3) Conception graphique (soit directement dans le navigateur ou à intégrer par la suite dans le marquage finalisé au point n°2)
Pas faux, mais là c’est vraiment du chipotage 🙂
C’est peut-être bête mais en ce moment je me rapproche de mon bloc notes papier, de plus en plus pour les croquis les mockup en html ou via des logiciels ne sont pas aussi… « intuitives ».
C’est une étape supplémentaire certes mais pour moi c’est essentiel de bien tout planifier sur papier avant même si le projet doit changer en cours de route.
Merci pour cet article et la traduction !
Merci également à Identitools, car je ne connaissais pas Sass & Compass.
Je vais tester ça prochainement, c’est dans ma todo list.
Je reste encore mitigé sur l’utilisation de Sass pour tous les projets. Pour le maintien de grosses applis pourquoi pas hein c’est top.
Si on part sur une base en OOCSS voir SMACSS bien rédigée, je trouve l’utilisation de Sass avec compilation via Fire.app par exemple assez lente. Qu’en pensez vous ?