Design web & mobile – quelques pistes de réflexion issues de mon expérience freelance.

Dans le cadre de mes missions de designer de service, les chantiers de design d’interfaces et d’interactions occupent une part importante de mon temps. En effet, la perception de l’utilisabilité et de la désirabilité du service passe en grande partie par la manière dont il se matérialise sur le terminal de l’utilisateur même si bien sur d’autres facteurs importants entrent en jeu (d’ou l’intérêt de ce cadre méthodologique et postural qu’apporte le design de service et qui permet de dessiner une vue d’ensemble, un écosystème tenant compte de l’utilisateur, de son contexte et de ses buts).

Je suis ainsi amené à définir des personae, élaborer des maquettes d’interfaces web ou mobiles (wireframes, mockups), définir les principes de navigation et les storyboarder, travailler sur l’architecture de l’information des sites ou Apps, … en étant évidement garant de la pertinence et de l’adéquation de ces préconisations avec les besoins des services en cours de conception.

Ces 6 derniers mois, grâce à la liberté d’action qui m’a été donnée j’ai eu l’occasion d’explorer de nombreuses pistes pour répondre efficacement aux problématiques parfois complexes et peu courantes posées par les services sur lesquels je travaille. Sans toutefois vous dévoiler les détails du projet, j’ai décidé de partager avec vous ce retour d’expérience sur le design web & mobile inspiré par mes recherches, tâtonnements, expérimentations et réalisations !

L’approche retenue : App thinking design

A la question « quelle expérience proposer selon le device utilisé ? » la réponse qui s’est imposée naturellement a été : la plus riche possible, avec un niveau d’exigence identique ! Plutôt que de me lancer tête baissée dans les étapes de conception des fonctionnalités et des écrans, j’ai pris le temps d’étudier les approches existantes permettant d’atteindre cet objectif en les mettant en regard du contexte du projet.

Au final, l’approche retenue a été la suivante :

• Mobile First pour conduire les réflexions sur les usages
• Design for thumb pour conduire les réflexions sur les interfaces et les principes de navigation «comme une App»
• Adaptive web design pour l’articulation de l’ensemble

J’avais d’ailleurs très rapidement abordé cette approche dans mon billet sur les prévisions pour 2012 en la nommant Tablet First bien que le terme ne soit pas assez parlant. Aujourd’hui je préfère parler d’App thinking design, bien plus lisible et traduisant plus fidèlement cette approche. Le gros avantage de cette démarche est qu’elle apporte beaucoup de fluidité aux étapes de conception, qui plus est lorsqu’elle est couplée à une approche design de service. En effet, habituellement le rythme est hachuré du fait des gap entre l’écriture des fonctionnalités répondant au besoin, leur traduction visuelle et leur scénarisation, le tout nécessitant des allers / retours et arbitrages rarements productifs ni utiles.

L’App thinking design permet aux équipes métiers du client de se projeter sur l’usage de manière cohérente par rapport aux équipes de concepteurs, dès le début du projet et sans avoir eu besoin de voir la moindre interface (sketch, wireframes, webdesign). Pourquoi ? tout simplement parce qu’imaginer et se projeter sur ce qu’ils peuvent toucher du doigt donne de bons résultats avec les utilisateurs lambda (i.e qui ne gravitent pas dans le monde du web) car plus simple et concret que le même exercice portant sur un écran + une souris bien plus abstrait et aléatoire..

App thinking design : démarche de conception dans laquelle les usages sont pensés « sur un mobile » et les interfaces conçues « comme une App », même pour la partie web.

Bien sur, ça ne dispense pas d’accompagner, expliquer, former, … les acteurs projets pour initier et maintenir un climat bienveillant et constructif propice à l’émulation collective. Ça n’est pas nouveau, c’est même la base du management de projet, mais ça fait toujours du bien de le rappeler.

Concrètement, cette approche App thinking design s’est traduite par un certain nombres de choix que je vais essayer de décrire et d’expliciter tout au long du billet. Cependant, bien que cette démarche ai été parfaitement adaptée à ce projet, peut être qu’elle le sera moins sur le votre. L’expérience ma appris qu’une démarche n’est valable que par rapport à un contexte donné, et qu’il est illusoire de vouloir fixer un cadre rigide pour tous les projets (même si c’est ce que l’on rencontre dans certaines DSI…).

Web : design monopage

Si jusqu’à présent nous nous représentions un site web comme un ensemble de pages reliées entre elles par des liens, depuis plusieurs années cette vision n’est plus représentative. En effet, de nombreuses avancées techniques (ajax, jquery, …) ont permis une plus grande souplesse dans la définition de l’architecture de l’information et du design des sites grâce en particulier aux possibilités de mises à jour dynamiques de portions de pages, là ou toute la page devait être chargée auparavant.

Ces techniques et la liberté créative qu’elles permettent ont donné naissance à une approche web intéressante, le design monopage, dont le principe général est l’utilisation d’une seule et unique page pour naviguer au sein des contenus d’un site.

design monopage : ensemble de contenus web hyperliés entre eux, affichés et naviguables sur une seule et unique page, qui constitent un site web à part entière.

Cette approche a des avantages et des inconvénients, mais bien maitrisée elle permet de proposer une expérience utilisateur très intéressante et se prête très bien à l’App thinking design. Ce choix de design est souvent l’appanage des blogs et autre sites de présentation de contenu, la majorité des sites applicatifs ou ecommerce riches se contentant d’une landing (mono)page. C’est le choix fait par 37signals, l’éditeur du célèbre service de gestion de projet collaboratif Basecamp, qui a très bien su tirer parti des spécificités de ce type de design et qui signe un site applicatif riche des plus réussi et utilisable.

Vous vous en doutez, c’est ce type de design novateur que j’ai préconisé sur mon projet actuel (sans savoir que 37signals prenait cette direction pour Basecamp). Et si construire une architecture de l’information lisible, claire et intuitive n’a pas été sans difficultés, je suis très content du résultat et ne regrette en rien ce choix ! D’ailleurs vous constaterez lorsque le projet sortira que nous sommes allé encore un peu plus loin dans le design monopage car la page n’est pas scrollable, seuls certains blocs de contenus en son sein le sont.

Mobile : one design to delight them all !

Responsive web design VS version mobile

Depuis 2 ans le responsive design fait beaucoup parler de lui, souvent présenté comme le messie permettant de concevoir pour l’ensemble des terminaux du marché de et proposer une expérience unifiée aux utilisateurs web, mobiles et tablettes. Son principe est de définir différentes règles de mises en page de l’écran via les feuilles de style CSS qui seront utilisées en fonction de la résolution du terminal accédant à la page.

Si le principe général est séduisant, deux écueils font que le responsive design ne peut être retenue comme LA stratégie centrale dans beaucoup de projets^[2].

D’abord, les résolutions écrans ne sont plus un critère segmentant suffisant comme le rappelle très bien le tableau de le tableau de Raphaël Yharrassarry, et ça ne va pas s’arranger (les résolutions des smartphones vont bientôt dépasser le 1024×768 et je ne vous parle même pas de l’arrivée du nouvel iPad…). Ensuite, cette technique est extrêmement complexe à mettre en oeuvre pour les sites de type applicatifs ou ecommerce dont l’architecture de l’information riche et profonde se prête difficilement à cet exercice. En revanche le responsive web design convient très bien aux blogs et sites essentiellement basés sur de la consultation de contenu (même s’il faut parfois bien se creuser les méninges pour la mise en oeuvre).

Ainsi, si au départ cette approche était celle que j’avais proposé et pensais mettre en oeuvre, il s’est avéré très rapidement après prototypage des zonings que conserver sur la version mobile la même qualité d’expérience que sur la version web allait demander un travail bien plus important et complexe que la gestion d’une version mobile distincte, mais également que proposer une version iPad par ce biais était bien trop complexe. Le choix a donc été fait de concevoir une version web ET une version mobile, moyen le plus efficace de proposer une expérience de qualité sur l’ensemble des terminaux utilisés, mais aussi de faire en sorte grâce à l’App thinking design que la navigation sur le site web soit parfaite avec l’iPad.

Concevoir pour une version web mobile VS webApp VS App native VS App hybride

Être sur un projet mouvant dont le contexte et les objectifs évoluent en cours de route oblige à prendre un recul certain par rapport aux impacts sur le design des choix de plateforme. Les enseignements de cette expérience sont néanmoins applicables à tous types de projets y compris les stables.

C’est certes une évidence pour beaucoup mais il est indispensable de proposer une expérience mobile à vos visiteurs, tout simplement parce que le traffic web mobile explose et représente déjà 5% de traffic web en Europe !

Durant le mois de janvier 2012, 89,8% des mobinautes ont au moins visité un site via leur mobile (source)

Nous avons déjà abordé précédemment l’approche responsive qui, si le contexte est favorable et si vous n’avez pas prévu de proposer d’expérience mobile, peut permettre de donner un accès aux contenus les plus importants des pages tout en minimisant les interventions au niveau du code. Cependant, une version mobile spécifique a un rapport travail / liberté de conception / qualité d’expérience mobile très intéressant, plus qu’une version responsive. Cette version mobile peut d’ailleurs être parfaitement suffisante dans certains cas, mais sera tout de même limitée par rapport aux webApp et aux Apps natives.

Malgré tout, une webApp ne remplacera jamais une version web mobile, simplement parce qu’elle ne permettra de couvrir qu’une partie des terminaux disponibles sur le marché (attention, bien qu’illustrant déjà le propos ce tableau n’est pas complet, la réalité est donc pire…). En effet, tout le monde n’est pas équipé d’un smartphone dernier cri ni n’a installé la dernière mise à jour de l’OS..

Choisir entre une App native, une webApp ou une App hybride est secondaire en début de projet. Non seulement cela génère des contraintes sur le design, mais en plus beaucoup des raisons guidant ce choix apparaissent en cours de conception. La question revient pourtant souvent et le travail de pédagogie pour expliquer en quoi ce n’est pas un problème d’un point de vue design tout en oeuvrant pour mettre le focus sur la définition de l’expérience mobile est fondamental.

Il est donc préférable d’adopter une approche de design globale, sachant qu’elle nécessite de bien connaitre les spécificités et guidelines de chaque plateforme pour ne surtout pas en tenir compte et proposer des expériences mobiles indépendantes de la plateforme utilisée (il sera toujours temps, une fois les choix de plateforme faits, d’apporter les petites touches de spécificités utiles).

design once, code once, run everywhere !

Il est d’ailleurs intéressant de constater que l’approche design once est très prisée en ce moment et je suis prêt à parier qu’elle deviendra un standard sous peu. A titre d’exemple je vous invite à jeter un oeil sur les Apps Facebook et Readability qui l’illustrent très bien.

Cette approche design once, que je préconise^[4], permet de ne pas s’encombrer de contraintes inutiles lors des étapes de design et de se concentrer sur l’essentiel : l’expérience utilisateur. Quand on sait que la majorité des utilisateurs ne font pas la différence entre une webApp et une App native, cela fait sens vous ne trouvez pas ?

Par ailleurs, un autre intérêt de l’approche design once est qu’elle peut être reprise d’un point de vue technique grâce à des outils comme Phonegap qui permettent à partir d’une version HTML5 globale de la convertir en version native Android, iPhone, … avec éventuellement si besoin au passage l’intégration de fonctionnalités spécifiques avancées pour chacune des plateformes (n’est ce pas Jérémie) !

Ayez toutefois à l’esprit dans votre démarche design once que les terminaux des différentes plateformes ont une grande variété de tailles d’écrans pouvant aller de 240×320 à 800×1280 en format 4/3 jusqu’à 16/10 sans parler de la densité de pixels… Je préconise de définir des catégories de terminaux aux résolutions proches (ex : SD pour 240×320, …. Et HD pour 720×960, ….) puis de voir s’il est possible de les gérer par un seul design qui sera décliné en version SD & HD par le graphiste, la plupart du temps c’est le cas. La gestion des largeurs d’écrans différentes au sein des catégories se fera ensuite à l’aide d’un design fluide, le principe étant que les zones affichées à l’écran son élastiques (i.e. définies par des % de taille). Veillez donc à ce que l’ensemble des éléments de votre design se prête bien à ce fonctionnement.

Gestuelles naturelles

Une autre tendance qui sera la norme d’ici peu est l’utilisation de gestuelles tactiles naturelles en remplacement ou complément des classiques boutons (natural touch gestures).

Si plusieurs Apps utilisent depuis longtemps ces gestuelles, je pense en particulier à MobileRSS ou Reeder, ces derniers temps les initiatives se sont multipliées avec dans le lot de très belles réussites qui pour moi font figure de référence (je pense surtout à Flipboard pour iPhone qui utilise à merveille les gestuelles tactiles naturelles ainsi qu’à Readability qui en plus ajoute l’approche design once. J’en suis fan vous l’aurez compris).

  

Je préconise donc l’utilisation de ces gestuelles pour fluidifier l’expérience de navigation et apporter un confort supplémentaire qui permet d’effacer l’interface au profit du contenu. Attention, le but n’est pas de se faire plaisir mais bien d’apporter de la valeur à l’utilisateur en exploitant au maximum les possibilités d’aujourd’hui. Ces gestuelles devront ainsi respecter le rythme de parcours et de navigation mais également être cohérentes avec les visuels et les animations utilisées pour les passages d’un écran à l’autre. Décrire ces gestuelles et leurs effets tout en précisant les attendus en terme d’animation n’est pas compliqué et peut tenir sur un simple schéma comme celui que j’ai réalisé ci-dessous (la qualité est volontairement mauvaise pour ne pas divulguer d’informations stratégiques.

Je pense qu’aujourd’hui la majeure partie des consommateurs sont cognitivements réceptifs à ces principes de navigation tactile qui, par ailleurs, du fait de leur fort pouvoir intuitif rendent l’interface encore plus invisible et réduisent la distance entre l’utilisateur et le contenu manipulé !

En conclusion, gardez à l’esprit que chaque projet est unique et que seul compte son contexte lorsqu’il s’agit de faire des choix de design, de l’approche à la réalisation. Inspirez vous des réflexions et recommandations glanées sur le web ainsi que de celles qui jalonnent ce billet mais ne les prenez pas pour argent comptant et challengez les au maximum. Enfin n’hésitez pas à intervenir dans les commentaire pour apporter un regard différent sur les sujets abordés dans ce billet, même s’il est contradictoire (surtout s’il l’est en fait !).

^[1] : d’expérience aborder les questions d’ordre technique à l’étape de définition de la démarche, au début du projet, est une perte de temps car ces questions seront élucidées au fur et à mesure du projet de manière naturelle et partagée pour peu que l’approche ai été bien pensée. Étonnamment, c’est plutôt l’inverse que l’on constate en entreprise. Les questions techniques (contraintes) sont énoncées dès le début du projet et le structurent fortement… D’ailleurs si vous pensez que ça doit être le cas, demandez vous donc pourquoi le Cloud attire tant les directions métiers lorsqu’ils s’y déplacent sans le concours de leur DSI lorsque cette dernière ne peut leur fournir autant d’agilité…

^[2] : attention, je parle ici de responsive web design selon la définition précise qu’en fait Ethan Marcotte, c’est à dire la stricte utilisation du CSS et des mediaqueries, sans employer de javascript ou détecter le user-agent. Le terme semble s’éloigner de plus en plus de cette définition et signifier simplement design s’adaptant au terminal, quelques soient les moyens techniques mis en oeuvre.

^[3] : se passer d’une version mobile ou responsive d’un site est un choix assez rare mais qui peut faire sens. Petite astuce : si l’absence de site web mobile ne vous semble pas être un des critère stratégique de réussite du service… => c’est que vous en aurez besoin d’un.

^[4] : A noter cependant que si vous comptez cibler les windows phone la question se posera sous un angle différent du fait de la très forte identité graphiques de cet OS mobile et vous devrez probablement mettre en oeuvre une stratégie design spécifique… Pour l’instant traiter cette cible avec une webApp commune reste acceptable, mais au vu du bon accueil des utilisateurs, il y a des chances que cet OS pèse de plus en plus dans la balance.