Un « joli » template ne rendra pas votre produit utilisable

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 UI ou templates pour construire des produits, mais il faut pour ça impliquer l’humain, les utilisatrices et utilisateurs dès le début du projet. Je donne des exemples d’échecs et réussites tirés de vrai projets pour étayer mon propos.

Transcript

1. Un joli template ne rendra pas votre produit utilisable Stéphanie Walter - UX & UI Designer – Octobre 2018
2. Un framework UI est 
 un outil qui propose un ensemble de composants permettant de construire une interface Définition
3. Un template désigne 
 un thème graphique appliqué à un site web indépendamment 
 de son contenu Définition
4. C’est l’histoire d’un projet…
5. Monsieur Client avait 
 une jolie idée.
6. La dream team Équipe de développement Équipe de design Agence de développement iOS
7. « Mais au fait, qui va se charger du design de l’application iPad ? » La question qui fâche
8. « Nous allons 
 les aider avec les parcours, l’architecture d’information, les wireframes et le design d’interface » « Nous allons construire le produit avec 
 notre framework 
 et l’équipe design mettra un coup 
 de peinture » VS Nous Eux
9. Plus de 15 actions et des allers retours entre 
 différents onglets pour accomplir la tâche. 1 2 3 1 2 3 1 2 3
10. « Des améliorations ? Bien sûr, tant que ça rentre dans les composants de notre framework » Quand les composants du framework dictent l’expérience utilisateur
11. Des coups de peinture 
 pour rendre le produit 
 « joli et sympa » #makeitsexy #makeitshiny
12. Un bel objet, shiny, sexy, flat 2.0, trendy… MAIS, ça ne suffira pas. #makeitsexy #makeitshiny
13. Un nouvel espoir…
14. 1 matinée, 2 designeuses, 1 nouveau parcours
15. Enfin, des tests utilisateur… une fin heureuse ? #newhope
16. « L’application est jolie et fera l’affaire. On implémentera vos propositions ergonomiques dans la prochaine version » #deadline #budget
17. Des choix d’interface dictés par les contraintes des frameworks, au détriment des besoins utilisateurs, pourquoi ?
18. Quel framework utilisez-vous ? (Plus d’un choix par réponse) Bootstrap Pure CSS Bulma Material UI dashboard template UIKit Foundation 3% 4% 7% 12% 12% 16% 70%
19. Pssst, les designeuses et designers utilisent des frameworks 
 (mais chut) C’est aussi un framework
20. Pourquoi utilise-t-on des frameworks UI et des templates ?
21. Pourquoi utiliser vous des frameworks UI ou templates ? (Plus d’un choix par réponse) 12% 13% 24% 30% 35% 49% Pas de temps pour construire des composants spécifiques Pas de budget pour construire des composants spécifiques Un choix imposé par le client Le framework était déjà utilisé sur le projet Pas de compétence HTML CSS pour construire de zéros Pas de compétences de design pour designer les composants
22. Uniformisation 
 et base commune pour les équipes “It provides a good and flexible structure for every projets we are working on. (…) Every team member share the same code and knowledge.”
23. Un outil de prototype “To give a temporary visual touch to a wireframe, this helps some client to project themselves in the wireframe”
24. Choix du framework UI et implications des équipes design
25. Qui choisi le Framework (Plus d’un choix par réponse) L’équipe de développement L’équipe de design Le client Les chefs de projet 12% 23% 30% 72%
26. Quand est choisi le framework (Plus d’un choix par réponse) Avant le début du projet En début de projet Phase d’analyse Après les wireframe Après le design Avant le code 4% 52% 8% 10% 2% 18%
27. Une boite à outils magiques dans laquelle on pioche hâtivement des composants pour faire avancer le projet ?
28. Mais si tu vas voir ce composant il fonctionne TRÈS bien… Ou pas … Crédit photo Jérémie Cohen
30. L’inception de composants
31. Attention à votre dette d’interface ! Et si on revoyait l’architecture d’information ?
32. Je veux que ça en jette Ajoute de jolies couleurs sur le Bootstrap et on est bons Tu peux me le rendre un peu plus sexy ? Il faut que ça claque Plus gros le logo !! We need to Wow the user Il nous faut quelque chose de plus fun ! Non mais j’ai pas tes talents artistiques moi On est pas chiants on veut juste un truc moins moche Grille disponible en PDF
33. To design … Dessiner ? Concevoir !!!
34. Le design d’interface 
 n’est PAS de l’ART 
 C’est la slide qu’il faut prendre en photo
35. Comment est-ce que je remets l’humain au coeur de mon processus de conception tout en continuant d’utiliser des thèmes et des frameworks UI ?
36. Faire ses devoirs, faire ses recherches. 01
37. Mais… on a pas de UX designeuse Mais… on a pas le temps Mais… on a pas le budget Mais…
38. Mais… on a pas de UX designeuse Mais… on a pas le temps Mais… on a pas le budget Mais… L’expérience utilisateur est une compétence pluridisciplinaire (pas juste un joli titre sur un CV)
39. Le support et les ventes en première ligne La boite mail du support, un endroit où dénicher des données et retours
40. Forums, réseaux sociauxet avis en ligne (stores) Arrêtez de suivre les concurrents, devancez les grâce aux retours
41. Mais… on a pas de UX designeuse Mais… on a pas le temps Mais… on a pas le budget Mais… Mais… ça va vous coûter bien plus cher plus tard, si vous ne 
 le faites pas.
42. Outils d’analytics
43. Les questionnaires en ligne, des données quantitatives à moindre coût
44. Observation et “Street Guerilla” Une après midi de recherche pour s’assurer d’avoir les bonnes fonctionnalités
45. Entretiens à distance ou par mail Asynchrone et à moindre coût !
46. Construire un plan et une vision globale : 
 parcours et navigation 02
47. Définition du parcours en amont Un joli template ne vous sauvera pas de boucles infinies et d’impasses
48. Le parcours aide au choix des gabarits et interactions
49. Architecture d’information solide grâce au tri de carte Crédit photo Université de Luxembourg
50. s Un choix avisé des gabarits du thème et de la navigation Naviginception, aie aie aie !
51. Composants, wireframes 
 et prototypes à tester 03
52. Inventaire des contenus / d’interface
53. Crazy 8 - générer des idées de composants de manière collaborative
54. Réutilisabilité et choix (à plusieurs) du framework Crédit photo Julie Muller
55. Sur quels critères ? (Plus d’un choix par réponse) Le support et la communauté Le langage supporté La qualité visuelle des composants La diversité des composants 52% L’accessibilité 30% 52% 54% 58%
56. “Make the developers aware of the designers constraints, and vice et versa“ Compréhension des contraintes
57. Prise en main du design du framework
58. Wireframe et prototype - entre composants existants et ajouts Favoriser la réutilisabilité des composants
59. Documenter les composants utilisés
60. Test utilisateur - valider le choix final du composant Pensez aux pré-tests
61. L’expérience utilisateur est la responsabilité de toute l’équipe.
62. Design d’interface, styleguides et documentation 04
63. Limiter les dégâts en cas d’absence d’équipe de design
64. Garder le framework comme il est / utiliser un thème
65. colorhunt.co Attention à l’accessibilité
66. fontawesome.com Un label explicite vaut mieux qu’une icône mal comprise
67. fontpair.co Une seule police avec plusieurs graisses suffit souvent
68. Documenter les décisions de design
69. Styleguides et design modulaire
70. Les composants de formulaires à différents états
71. Outils d’inspection pour favoriser la collaboration Invision, Zeplin, etc.
72. Spécifications design
73. Take the time to document the choices of the designer (from the framework to each specific component) to make sure the decisions are understood and the components correctly applied without having to discuss it every time a new person enters the team. Documenter les décisions de design (pas juste le code)
74. vmware.github.io/clarity Documentation design pour chaque composant
75. ant.design Les conseils d’ergonomie et de design font partie de la doc’
76. Intégration et évolutions (oui, avec un S) 05
77. Intégration à partir des composants designés
78. Documenter les composants “custom” ajoutés dans le code Ce composant n’était pas dans Ant
79. Recette, contrôle qualité et tests Test utilisateur du produit final avant la mise en production
80. UX Design UI Design Developpement Une évolution continue tout en conservant homogénéité et 
 réutilisabilité du code et des composants
81. En conclusion …
82. Il est grand temps de remettre l’humain au centre de nos processus de conception
83. Et ça commence par plus de communication et de collaboration entre les équipes de design et de développement.
84. “ … Afin qu’ils (équipes de design et de développement) comprennent qu'ils ne doivent pas être ennemis et qu'ils peuvent tout à fait travailler ensemble !”
85. Le design d’interface 
 N’EST PAS de l’ART 
 Je ne colorierai pas ton Bootstrap, bisou.
86. UX & UI Designer Mobile expert. Pixel & CSS Lover. Google Dev Expert Product Design stephaniewalter.design @WalterStephanie Attribution-NonCommercial-NoDerivs 3.0 France (CC BY-NC-ND 3.0 FR)