fbpx
Billetterie
Design

Un « joli » template ne rendra pas votre produit utilisable

Wednesday 24/10 14:00 → 15:00 Salon Prestige

Grâce à Bootstrap, material design et tous les templates et frameworks sur le marché, il est possible de rapidement lancer un produit dont le design semble visuellement agréable. Pourtant, sans réelle compréhension des besoins utilisateurs et design en amont, beaucoup de ces produits sont “jolis” mais restent inutilisables, voir inutiles.
Le but de ma conférence est de montrer qu’il est tout à fait possible d’utiliser des frameworks pour construire des produits, mais il faut pour ça impliquer l’humain, l’utilisateur dès le début du projet. Je vais donner des exemples d’échecs et réussites tirés de vrai projets pour étayer mon propos.

Sommaire

1. C’est l’histoire d’un projet qui finit mal à cause de mauvaise décisions techniques
Je commence par planter le décor en revenant sur un de mes projets qui s’est très mal fini. Un projet où les décisions techniques prises ont rendu l’interface inutilisable, où on a demandé au designer la rendre “jolie” mais au final, ça n’a bien évidemment pas suffit.

2. L’uniformisation des interfaces au détriment de l’humain : comment en sommes-nous arrivés là ?
Je souhaite dans une seconde partie analyser comment nous en sommes arrivés là.
2.1 Le “One Size Fits All”
J’ai travaillé pour une petite agence qui voulait “construire un slider HTML CSS pour le réutiliser sur tous les projets”. Le one size fits all à l’échelle du design, sans prendre en compte les besoins et spécificités de chaque projet. J’ai travaillé pour de grosses SII, même constat : les développeurs ont besoin d’une UI pour rapidement mettre les données dans leur base de données, à grand coup de “modale dans une modale”.  2018, les besoins de la base de données régissent toujours nos interfaces. Sommes-nous devenus à ce point des machines ?

2.2 Une évolution des métiers vers plus de JS
L’évolution des métiers semblent également jouer un certain rôle. Le rôle d’intégrateur, qui jadis convertissait des maquettes en fichiers HTML CSS JS disparaît sur les produits au profit de rôles “full stack”. Force est de constater que bien souvent ces full stack spécialisés en JavaScript sont perdus quand il s’agit de créer des composants CSS. Le Template devient là un choix de “facilité” puisqu’il propose des composants d’interface tout fait.

2.3 La boite à outils magiques
Et c’est ainsi que ces thèmes Bootstrap, Angular, React, Material design (rayer la mention inutile) se multiplient. Nous avons donné à nos développeurs des boîtes à outils magiques. L’évolution de notre industrie, des deadlines de plus en plus serrées sur les projets les forcent à se lancer dans l’utilisation de ces Template : les décisions de développement et choix techniques dictent désormais le (non)design. Le designer est appelé en bout de chaîne pour “colorier” le Template aux couleurs du client. Elle remonte des soucis d’utilisabilité, demande “pourquoi on demande toutes ces informations dans le formulaire ; est-ce qu’on a vraiment besoin du genre de l’utilisateur et de l’âge de sa grand-mère ??”. On lui répond que c’est trop tard, le client a validé. Hourra.

3. Remettre l’utilisateur au cœur du processus tout en utilisant un Template.
Les Template sont des outils, ni bons, ni mauvais. Le but de cette dernière partie est de montrer comment on peut concilier Template et besoins utilisateurs au travers d’exemple de projets sur lesquels j’ai travaillé. On en revient très souvent à la notion de travail en équipe designer / développeur. Le processus idéal serait le suivant : recherche utilisateur en amont, création du parcours utilisateur avec les développeurs et validation, choix du Template/Framework, analyse et wireframes, prototype, test utilisateur.

3.1 La compréhension de ses utilisateurs
La recherche utilisateur en amont est primordiale pour s’assurer qu’un produit sera utilisable et utilisé. Elle permet également d’avoir une vision globale du projet et de savoir vers où on se dirige. Je souhaite également rappeler ici le rôle éthique du designer. En créant de l’empathie avec les utilisateurs, la designer va également souvent remonter les inquiétudes de ces derniers quant à la vie privée, la gestion des données, etc. Les impacts sur le parcours utilisateur peuvent être très grands et faire la différence entre rejet et adoption d’un produit.
3.2 Le choix en commun du Framework/ Template, un travail d’équipe
Si un choix de Template ou Framework doit se faire, il vaut mieux le faire à ce stade là d’un commun accord entre designer et développeur. Impliquer le designer dans le choix du Framework et lui permettre de comprendre les composants permet non seulement de gagner du temps, mais aussi de s’assurer que l’interface réponde aux besoins des utilisateurs en choisissant le composant et parcours adéquat.
3.3 Designer en prenant en compte les limites d’un Template
Il est alors tout à fait possible de baser des wireframes et designs sur ce Template. De la contrainte peut naître la créativité. Pour cela il faudra souvent faire un inventaire d’interface des capacités du Framework. Le choix d’un composant ou d’un autre sera encore une décision collective qui prendra en compte besoins utilisateur, utilisabilité et temps de développement.

4. En conclusion : il est possible de créer des produits utilisables avec des Template, mais seulement en remettant l’humain au centre du processus dès les premières phases du projet et en collaborant directement entre équipes de design et de développement.

 

(Note de la Team Blend : la date et l’heure sont données à titre indicatifs, elles seront confirmées début septembre)

<