{"id":7124,"date":"2018-12-18T22:00:32","date_gmt":"2018-12-18T21:00:32","guid":{"rendered":"https:\/\/stephaniewalter.design\/fr\/?p=7124"},"modified":"2018-12-23T11:00:05","modified_gmt":"2018-12-23T10:00:05","slug":"experience-utilisateur-et-templates-frameworks-ui-partie-1-le-constat","status":"publish","type":"post","link":"https:\/\/stephaniewalter.design\/fr\/blog\/experience-utilisateur-et-templates-frameworks-ui-partie-1-le-constat\/","title":{"rendered":"Exp\u00e9rience utilisateur Templates \/ Frameworks UI \u2013 partie 1, le constat."},"content":{"rendered":"
Gr\u00e2ce \u00e0 Bootstrap, Material Design et tous les templates et frameworks sur le march\u00e9, il est possible de lancer rapidement un produit dont le design \u201csemble\u201d visuellement agr\u00e9able. Pourtant, sans r\u00e9elle compr\u00e9hension des besoins utilisateurs en amont, beaucoup de ces produits qui semblent jolis de prime abord n\u2019en restent pas moins inutilisables, voire inutiles.<\/p>\n
Le design, c\u2019est cependant bien plus que des jolis boutons<\/strong>. Travailler avec des templates est possible, mais pas sans une r\u00e9flexion sur les besoins, les parcours et une architecture d\u2019information solide en amont. Je pense qu\u2019il est tout \u00e0 fait possible d\u2019utiliser des frameworks pour construire des produits, mais il faut pour \u00e7a impliquer l\u2019humain, les utilisatrices et utilisateurs d\u00e8s le d\u00e9but du projet. <\/strong><\/p>\n Le sujet \u00e9tant long \u00e0 traiter, l\u2019article est d\u00e9coup\u00e9 en deux parties. Dans cette premi\u00e8re partie<\/a>, je dresse un constat \u00e0 travers l\u2019exemple d\u2019un projet, de mon questionnaire en ligne sur les Framework UI sur l\u2019\u00e9tat du march\u00e9 des frameworks en 2018 et l\u2019implication des \u00e9quipes de design sur des projets utilisant des Framework UI.<\/em><\/p>\n Dans la seconde partie<\/a>, je vous explique mon processus de travail au quotidien pour remettre les utilisatrices au centre de nos processus de conception<\/em>.<\/p>\n Pour que l\u2019on parle de la m\u00eame chose, je vais commencer par quelques d\u00e9finitions. Quand je parle de \u201cFramework UI\u201d j\u2019entends par l\u00e0 un outil qui propose un ensemble de composants permettant de construire une interface. Le plus connu c\u2019est bien s\u00fbre Bootstrap<\/a>. Un Template quant \u00e0 lui d\u00e9signe un th\u00e8me graphique appliqu\u00e9 \u00e0 un site web ind\u00e9pendamment de son contenu. Les templates sont souvent cr\u00e9\u00e9s \u00e0 partir de composants du framework UI, mais aussi parfois \u00e0 partir de z\u00e9ros. Bootstrap par exemple propose un bon nombre de templates pour des dashboard et d\u2019autres syst\u00e8mes<\/a>. Dans les deux cas, ils permettraient en th\u00e9orie de construire des sites et interfaces web.<\/strong><\/p>\n <\/p>\n Pour mieux comprendre l\u2019impacts que peuvent avoir ces frameworks et templates, je vais vous raconter une histoire, l\u2019histoire de mauvaises d\u00e9cisions et d\u2019\u00e9v\u00e8nements f\u00e2cheux qui ont men\u00e9 un de mes projet droit \u00e0 sa perte. Je vous le dis de suite, ceci n\u2019est pas un conte de f\u00e9e, il n\u2019y aura pas de fin heureuse.<\/em><\/p>\n Toute bonne histoire doit avoir un protagoniste. Appelons le n\u00f4tre \u201cMonsieur client\u201d. Monsieur Client avait une jolie id\u00e9e, Monsieur Client voulait construire un produit pour aider les enfants \u00e0 apprendre la musique.<\/p>\n Le produit \u00e9tait compos\u00e9 de deux parties\u00a0:<\/p>\n Pour donner vie \u00e0 son projet, Monsieur Client fit appel \u00e0 des investisseurs et \u00e0 une \u00e9quipe de braves aventuriers du web, mon agence, compos\u00e9e :<\/p>\n Il fit \u00e9galement appel \u00e0 une agence en charge du d\u00e9veloppement de l\u2019application iPad. Mon \u00e9quipe travaillerait sur la plateforme web (code et design) et le prestataire externe sur l\u2019application iPad.<\/p>\n Vous vous doutez bien que, comme dans toute qu\u00eate \u00e9pique avec autant de protagonistes, il allait forc\u00e9ment y avoir des soucis.<\/p>\n L\u2019\u00e9quipe de d\u00e9veloppement chez nous rencontra l\u2019\u00e9quipe iOS pour se mettre d\u2019accord sur le format de l\u2019APIs. Jusque-l\u00e0 tout se passait bien.<\/p>\n Durant un de ces meetings, j\u2019ai eu l\u2019id\u00e9e \u00e9trange de poser la question qui f\u00e2che \u00ab\u00a0Mais au fait, qui va se charger du design de l\u2019application iPad ?\u00a0\u00bb<\/strong><\/p>\n La discussion ressemblait \u00e0 peu pr\u00e8s \u00e0 \u00e7a :<\/p>\n L\u2019\u00e9quipe de la soci\u00e9t\u00e9 mobile ne semblait pas super ravie de la d\u00e9cision, mais Monsieur Client approuva l\u2019id\u00e9e.<\/p>\n En g\u00e9n\u00e9ral c\u2019est le moment o\u00f9 on se dit que tout le monde est sur la m\u00eame longueur d\u2019ondes, que tout est d\u00e9fini, tout va bien se passer ? Ce n\u2019\u00e9tait bien \u00e9videmment pas le cas.<\/p>\n Pour l\u2019\u00e9quipe de design, pour moi, \u00ab\u00a0faire le design<\/strong>\u00a0\u00bb signifiait \u00ab\u00a0Nous allons les aider avec l\u2019architecture d\u2019information, les parcours, les wireframes et le design de l\u2019interface<\/strong><\/em>\u00a0\u00bb. Pour l\u2019\u00e9quipe iOS, \u00e7a voulait dire \u00ab\u00a0Nous allons construire le produit avec notre frameworks et l\u2019\u00e9quipe design mettra un coup de peinture<\/strong><\/em>\u00a0<\/strong>\u00bb<\/p>\n Bien s\u00fbr, personne n\u2019a \u00e7a dit \u00e0 haute voix \u00e7a durant le meeting. Et voil\u00e0 comment commence un encha\u00eenement de d\u00e9cisions f\u00e2cheuses qui vont mener le projet \u00e0 sa perte.<\/p>\n L\u2019\u00e9quipe de design ne fut jamais consult\u00e9e ; ni pour l\u2019architecture, les parcours utilisateur, ni m\u00eame sur l\u2019ergonomie de l\u2019application iPad. Au bout de quelques semaines, nous recevons re\u00e7u un premier prototype pour tester l\u2019application.<\/p>\n <\/p>\n La navigation se faisait avec des onglets. Les utilisatrices et utilisateurs devaient faire des allers retours entre diff\u00e9rents onglets et plus de 15 actions \u00e9taient n\u00e9cessaires pour accomplir la t\u00e2che<\/strong>. J\u2019\u00e9tais \u00e0 la fois quelque peu \u00e9tonn\u00e9e et inqui\u00e8te. Avec espoir, je leur demande \u00ab\u00a0hum, dites, c\u2019est juste un premier prototype rassure moi<\/strong>, est ce que je peux proposer des am\u00e9liorations sur les parcours et l\u2019utilisation ?\u00a0\u00bb<\/p>\n On me r\u00e9pond gentiment\u00a0: \u00ab\u00a0Des am\u00e9liorations ? Bien s\u00fbr (ceci est un pi\u00e8ge), tant que les modifications entrent dans le cadre des composants de notre framework\u00a0\u00bb C\u2019est \u00e0 ce moment-l\u00e0 qu\u2019on m\u2019a donn\u00e9 tout le contexte : pour des raisons de budget et de deadline, l\u2019\u00e9quipe iOS avait d\u00e9velopp\u00e9 l\u2019application en utilisant son framework \u00ab\u00a0maison\u00a0\u00bb, avec ses propres composants et limitations<\/strong>.<\/p>\n Bon, dans une logique startup, pour une mise sur le march\u00e9 rapide, c\u2019est coh\u00e9rent. Le souci, c\u2019est qu\u2019ils n\u2019ont jamais consult\u00e9 l\u2019\u00e9quipe de design sur les composants ou les parcours de l\u2019application, et l\u00e0 franchement c\u2019\u00e9tait carr\u00e9ment inutilisable<\/strong>.<\/p>\n Nous \u00e9tions au milieu du printemps et le produit devait \u00eatre lanc\u00e9 en Septembre. Une grosse partie des am\u00e9liorations propos\u00e9es furent rejet\u00e9es. Elles demandaient de red\u00e9velopper des composants, chose impossible pour des raisons de budget.<\/p>\n On demanda \u00e0 l\u2019\u00e9quipe de design de mettre un coup de peinture pour rendre les pages de l\u2019application iPad plus \u00ab\u00a0jolies et sympas\u00a0<\/strong>\u00bb. Et la mort dans l\u2019\u00e2me c\u2019est ce que nous avons fait.<\/p>\n L\u2019application \u00e9tait le nec plus ultra de l\u2019\u00e9poque, flat, avec les jolies couleurs \u00e0 la mode du moment, shiny, trendy. Le client \u00e9tait tr\u00e8s content de son application, c\u2019\u00e9tait objectivement un joli objet.<\/strong> Un peu comme ce presse citron, joli, mais pas franchement stable et facile \u00e0 utiliser.<\/p>\n <\/p>\n Monsieur Client \u00e9tait tellement content sa jolie application qu\u2019il d\u00e9cida d\u2019ENFIN impliquer les utilisatrices et utilisateurs.<\/strong> H\u00e9las, les utilisatrices et utilisateurs \u00e9taient incapable de comprendre sans aide ext\u00e9rieur comment l\u2019application devrait fonctionner. Pire, m\u00eame avec de l\u2019aide, ielles n\u2019y arrivaient pas forc\u00e9ment.<\/p>\n C\u2019est \u00e0 ce moment que vous vous dites que tout est perdu. Vous avez sans doute raison. Mais la vie est cruelle, et toute bonne trag\u00e9die doit avoir une pointe d\u2019espoir \u00e0 un moment donn\u00e9, ne serait-ce que pour pouvoir tomber d\u2019encore plus haut. La voici.<\/em><\/p>\n Monsieur Client \u00e9tait inquiet. Il s\u2019\u00e9tait rendu compte que lancer l\u2019application dans cet \u00e9tat en septembre allait pas forc\u00e9ment \u00eatre un gros succ\u00e8s. L\u2019\u00e9quipe de design saisit l\u2019opportunit\u00e9. Le budget \u00e9tait serr\u00e9, mais nous avons propos\u00e9 de retravailler le parcours utilisateurs pour rendre l\u2019application utilisable<\/strong>. Monsieur Client accepta, l\u2019\u00e9quipe de design se mit au travail.<\/p>\n En utilisant un tableau blanc et des post-its, nous avons enfin pu ENFIN faire ce que nous aurions d\u00fb faire au d\u00e9but : un parcours utilisateur coh\u00e9rent. <\/strong>Nous avons tout reprise de z\u00e9ros et proposer un parcours lin\u00e9aire guidant les utilisateurs et utilisatrices de l\u2019application et leur permet d\u2019accomplir la t\u00e2che en 8 \u00e9tapes (au lieu de 15).<\/p>\n <\/p>\n Ce nouveau parcours fut pr\u00e9sent\u00e9 \u00e0 Monsieur Client et l\u2019\u00e9quipe iOS durant un meeting, directement en post-its (en raison du manque de temps). Monsieur Client \u00e9tait content.<\/p>\n L\u2019\u00e9quipe iOS semblait dire que ce qui \u00e9tait propos\u00e9 dans le prototype en post-it \u00e9tait faisable. Nous avons donc commenc\u00e9 \u00e0 planifier la cr\u00e9ation d\u2019un prototype interactif et des tests utilisateur<\/strong> avec le nouveau parcours.<\/p>\n Vous vous dites que c\u2019est un de petits miracles au milieu de l\u2019histoire et que tout va s\u2019arranger. C\u2019est ce que nous pensions aussi. Mais je vous ai dit au d\u00e9but qu\u2019il n\u2019y aurait pas de fin heureuse.<\/em><\/p>\n La r\u00e9alit\u00e9 des deadlines et du budget rattrapa h\u00e9las le client <\/strong>tr\u00e8s vite. Une heure apr\u00e8s notre r\u00e9union avec Monsieur client, l\u2019\u00e9quipe de d\u00e9veloppement est revenue vers lui pour lui dire qu\u2019il ne serait finalement pas possible de modifier l\u2019application avec les composants actuels du framework. Ce que nous avions propos\u00e9 comme parcours lin\u00e9aire n\u2019\u00e9tait apparemment pas possible avec leur composants (pourtant ils nous avaient dit que \u00e7a l\u2019\u00e9tait durant la r\u00e9union\u2026). Il faudrait pour modifier leurs composants pr\u00e9voir des d\u00e9veloppements suppl\u00e9mentaires qui prendraient un peu de temps et ne seront pas compris dans le budget initial. Si Monsieur Client souhaitait vraiment modifier l\u2019application \u00e0 ce stade de d\u00e9veloppement, la deadline de Septembre ne serait pas tenue et il fallait allonger sur le budget.<\/p>\n Vous vous d\u00eetes qu\u2019il vaudrait peut-\u00eatre mieux retarder le lancement plut\u00f4t que de lancer un produit inutilisable ? <\/em>Certes, mais parfois, on n\u2019a pas le choix, surtout en startup quand il faut aller rapidement sur le march\u00e9. Les investisseurs de Monsieur Client refusent de retarder le lancement. L\u2019application Jolie mais pas utilisable fera tr\u00e8s bien l\u2019affaire.<\/p>\n Bien s\u00fbr, la deadline de septembre ne fut jamais respect\u00e9e, m\u00eame avec la version \u201cframework\u201d de l\u2019application iPad.<\/p>\n Au final, d\u2019autres malheurs sont arriv\u00e9s \u00e0 ce projet, mais \u00e7a c\u2019est un autre histoire\u2026<\/p>\n Des histoires comme celles-ci, j\u2019en ai des tonnes, les miennes, celles d\u2019autres designers, d\u2019autres projets, en startup, en agence, chez le client, en SII, en web et en mobile.<\/p>\n Le point commun entre toutes : un manque cruel de consid\u00e9rations pour les besoins utilisateur et une interface dict\u00e9e par les besoins du framework de d\u00e9veloppement<\/strong>.<\/p>\n Pourtant, les frameworks UI et templates sont utilis\u00e9s au quotidien par notre industrie, sur des projets \u00e0 succ\u00e8s. Je souhaitais donc comprendre comment et pourquoi on en arrivait l\u00e0 sur certains projets comme le mien.<\/p>\n J\u2019ai d\u00e9cid\u00e9 de demander \u00e0 la communaut\u00e9 et ai publi\u00e9 un petit sondage en ligne. J\u2019ai eu plus de 120 participants. D\u2019ailleurs merci aux personnes ayant particip\u00e9. J\u2019ai \u00e9galement interview\u00e9 plusieurs membres de la communaut\u00e9, designers, d\u00e9veloppeurs pour tenter d\u2019apporter la r\u00e9ponse la moins biais\u00e9e \u00e0 la question.<\/p>\n J\u2019ai commenc\u00e9 par demander aux r\u00e9pondants et r\u00e9pondantes quel framework \u00e9tait utilis\u00e9<\/strong>. C\u2019\u00e9tait une question \u00e0 plusieurs r\u00e9ponses possibles. Sans grande surprise, Bootstrap arrive en t\u00eate de liste.<\/p>\n <\/p>\n Ma micro \u00e9tude a remont\u00e9 surtout des frameworks HTML CSS et JS. Mais il faut bien comprendre que nous aussi designeuses et designers utilisent \u00e9galement des frameworks UI.<\/p>\n Quand je design une application Android, j\u2019utilise le Framework material design de Google. Quand je veux designer pour iOS ou Apple TV et que j\u2019essaie de suivre les guidelines Apple, j\u2019utilise aussi en quelque sorte le framework d\u2019Apple. Il serait hypocrite de ma part de vous dire que les frameworks sont quelque chose de mal. Bien au contraire. Je souhaite simplement comprendre comment les utiliser au mieux et pouvoir r\u00e9concilier m\u00e9thodes de design centr\u00e9 utilisateur et frameworks.<\/p>\n La premi\u00e8re chose que je me demandais \u00e9tait \u00ab\u00a0Pourquoi utilise-t-on des frameworks UI et des templates ?\u00a0\u00bb.<\/p>\n <\/p>\n Une grande partie des r\u00e9ponses se concentrent sur le gain temps<\/strong> (pour la moiti\u00e9 des r\u00e9pondants) et le budget<\/strong> (pour 1\/3). Pour 1\/3 des r\u00e9pondants, le framework \u00e9tait d\u00e9j\u00e0 utilis\u00e9 sur le projet<\/strong>. Encore une fois, si vous \u00eates une startup, un gain de temps et de d\u00e9veloppement, signifie un acc\u00e8s rapide au march\u00e9, avantage non n\u00e9gligeable, effectivement.<\/p>\n Dans les r\u00e9ponses libres, certaines expliquent que ce n\u2019est parfois pas leur choix mais celui de l\u2019entreprise voir du client. Pour 1\/4 des r\u00e9pondants, le manque de comp\u00e9tences de design est \u00e9galement une raison invoqu\u00e9e.<\/p>\n Les r\u00e9ponses ouvertes et les interviews ont \u00e9galement donn\u00e9 plus de pistes. Certains \u00e9voquent les frameworks comme outils d\u2019uniformisation et de maintenabilit\u00e9, comme base et structure commune.<\/p>\n <\/p>\n D\u2019autres rappellent leur caract\u00e8re \u00e9ph\u00e9m\u00e8re et utilisent les frameworks comme outils pour des prototypes (ou des proof of concepts)<\/p>\n <\/p>\n Au final les Framework remplissent un r\u00f4le tr\u00e8s important voir essentiel dans notre paysage et \u00e9cosyst\u00e8me. Je me suis du coup int\u00e9ress\u00e9e au moment du choix du framework et \u00e0 l\u2019implication des \u00e9quipes de design dans des processus de conception utilisant des frameworks.<\/p>\n J\u2019ai pos\u00e9 la question de \u00ab\u00a0qui choisit le framework\u00a0\u00bb. Au final, le choix se fait souvent par les \u00e9quipes de d\u00e9veloppement.<\/p>\n <\/p>\n Quand on demande quand le framework est choisi<\/strong>, la r\u00e9ponse qui ressort le plus sur une timeline de projet est \u00ab\u00a0au d\u00e9but du projet\u00a0\u00bb<\/strong>. C\u2019est donc en g\u00e9n\u00e9ral, avant m\u00eame la phase d\u2019analyse, de wireframes, de design que le choix du framework se fait. Pour moi, \u00e7a veut surtout dire qu\u2019ils sont choisis avant m\u00eame de conna\u00eetre r\u00e9ellement les besoins utilisateurs et les besoins du projet en mati\u00e8re d\u2019architecture d\u2019information et de composants<\/strong>. Ce qui implique que h\u00e9las, comme pour le projet du client, les limites du framework vont imposer des composants au d\u00e9triment souvent de\u00a0l\u2019exp\u00e9rience utilisateur.<\/strong><\/p>\n <\/p>\n D\u2019exp\u00e9rience personnelle, j\u2019ai pu constater que lorsque le framework est choisi en d\u00e9but de projet, sans la moindre phase d\u2019analyse, on choisit souvent le framework le plus large possible. Car on a justement aucune id\u00e9e de ce dont on va avoir vraiment besoin, mais bon, pour \u00eatre s\u00fbre, on en choisit un BIIIIEN complet. Et bien souvent, lorsque le projet avance, les \u00e9quipes se rendent compte qu\u2019elles n\u2019utilisent m\u00eame pas 10% des composants du framework.<\/strong><\/p>\n J\u2019ai un peu l\u2019impression que les frameworks sont devenues ces sortes de bo\u00eetes \u00e0 outils magiques<\/strong>. On y pioche des composants sans trop avoir le temps de se poser la question de leur utilisabilit\u00e9 ou utilisation. La faute \u00e0 l\u2019\u00e9volution de notre industrie aux deadlines de plus en plus serr\u00e9es ? A une pression d\u2019aller de plus en plus vite sur le march\u00e9 ? Il y a sans doute pleins d\u2019explications possibles.<\/p>\n Les d\u00e9cisions de d\u00e9veloppement et choix techniques m\u00e8nent la danse. Le design est (encore trop souvent) rel\u00e9gu\u00e9 \u00e0 rang de \u00ab\u00a0coup de peinture en fin de projet\u00a0\u00bb<\/strong>.<\/p>\n Mais piocher dans la bo\u00eete \u00e0 outils magique ne fonctionne pas toujours. Voil\u00e0 ce qui arrive quand on essaie de forcer un composant UI pas pr\u00e9vu pour, niveau utilisateur.<\/p>\n <\/p>\n Ici on a un immeuble de 5 \u00e9tages et un composant ascenseur de 9 \u00e9tages. Le composant a \u00e9t\u00e9 utilis\u00e9 malgr\u00e9 le fait qu\u2019il ne correspondait clairement pas au besoin. Les \u00e9tages ont \u00e9t\u00e9 redirig\u00e9s et dupliqu\u00e9s, il faut faire le 5 ou le 6 pour acc\u00e9der au 2 e \u00e9tage, le 10 pour le 5e. \u00e7a n\u2019a plus aucun sens. Bonne chance au passage pour les utilisatrices aveugles. Le plus dr\u00f4le dans cette histoire\u00a0? On m\u2019a fait remarquer qu\u2019il s\u2019agit de l\u2019ascenseur des Gobelins, \u00e9cole de design\u2026<\/p>\n On peut rire de cet ascenseur, mais on fait exactement pareil sur le web. Nous cr\u00e9ons des interfaces \u00e0 gros coups de copier-coller de composant UI<\/strong>, et y ajoutons des wizards et des petites pastilles d\u2019onboarding pour expliquer \u00e0 nos gentilles utilisatrices comment \u00e7a fonctionne.\u00a0Parce que contrairement \u00e0 Monsieur Client, on ne peut pas tous \u00eatre l\u00e0 pour expliquer l\u2019interface \u00e0 chaque utilisatrice.<\/p>\n <\/p>\n Il y a quelques mois, une coll\u00e8gue est venue me trouver avec un \u00ab\u00a0probl\u00e8me de design\u00a0\u00bb.<\/p>\n Elle avait un tableau. Quand on clique sur le tableau, il ouvre une modale. Dans cette modale il y a des onglets. Dans les onglets, un autre tableau. Vous me suivez toujours ? Ok, bon. Dans ce second tableau (dans la modale dans l\u2019onglet) il y a un bouton d\u2019ajout pour ajouter une ligne \u00e0 ce second tableau (celui qui est dans la modale qui est dans l\u2019onglet)<\/p>\n Ma coll\u00e8gue vient me demander de l\u2019aide, parce qu\u2019elle ne savait pas trop o\u00f9 mettre le formulaire d’ajout de ligne et qu\u2019une modale dans une modale c\u2019est peut-\u00eatre un peu \u00ab\u00a0trop\u00a0\u00bb. Parce que bon jusque-l\u00e0 le tableau dans l\u2019onglet dans la modale qui s\u2019ouvre en cliquant sur une ligne de tableau, ce n\u2019\u00e9tait pas d\u00e9j\u00e0 trop\u00a0?\u00a0:D Je charrie un peu sur cet exemple (pourtant tir\u00e9 d\u2019une discussion r\u00e9elle), mais je ne veux surtout pas bl\u00e2mer ma coll\u00e8gue car elle n\u2019y est pour rien.<\/p>\n La question qu\u2019il faut se poser est \u00ab\u00a0pourquoi en sommes-nous arriv\u00e9s \u00e0 ce niveau d\u2019inception ?\u00a0\u00bb C\u2019est quelque chose que j\u2019appelle la dette d\u2019interface<\/strong>.<\/p>\n On construit une page,\u00a0l\u2019\u00e9quipe choisit un composant dans son joli framework, le composant fonctionne. Et puis, la page grandi, grandi, grandi, on y ajoute des d\u2019informations et de nouveaux contenus, apr\u00e8s quelques temps, on ne sait plus trop o\u00f9 ajouter les contenus dans le composant. Pourtant personne ne s\u2019est demand\u00e9 si le composant de base \u00e9tait toujours le bon apr\u00e8s tout ce temps (et ajout de contenus). Et nous avons l\u00e0 une dette d\u2019interface, et un composant qui n\u2019est plus le bon compar\u00e9 au contenu qui a \u00e9volu\u00e9.<\/strong><\/p>\n Comme toute dette, il faut \u00e0 un moment donn\u00e9 en prendre conscience<\/strong>, l\u2019\u00e9valuer<\/strong>, et faire quelque chose pour am\u00e9liorer la situation<\/strong>.<\/p>\n M\u00eame si de base elle \u00e9tait venue me voir pour me demander quel composant elle pourrait utiliser qui soit pas une modale), dans le cas de ma coll\u00e8gue, la solution n\u2019\u00e9tait pas de trouver un nouveau composant pour y mettre toutes ses informations. La solution ici est de revoir la structure de la page dans son ensemble pour \u00e9liminer cette dette d\u2019interface<\/strong>. Une modale fonctionnait sans doute au d\u00e9but avec moins de fonctionnalit\u00e9s. Mais quand vous en arrivez \u00e0 avoir une modale avec \u00e0 l\u2019int\u00e9rieur un tableau et des onglets, ce n\u2019est pas d\u2019une modale dont vous avez besoin ici, mais d\u2019une nouvelle page dans votre architecture sur une logique \u00ab\u00a0vue ma\u00eetre \/ vue d\u00e9tails\u00a0\u00bb.<\/p>\n Ma coll\u00e8gue est venue me trouver tr\u00e8s t\u00f4t. Mais h\u00e9las on vient encore trop souvent trouver les \u00e9quipes design en fin de projet. Et on nous demande de \u00ab\u00a0juste mettre un coup de peinture\u00a0\u00bb sur l\u2019interface\u00a0\u00bb d\u00e9j\u00e0 construite dans le navigateur. Ou un truc similaire. Je vous ai fait un petit best off de ce que j\u2019ai et des amies designeuses ont pu entendre, de rendre le framework sexy, joli, au \u00ab\u00a0il faut que \u00e7a claque, que \u00e7a en jette\u00a0\u00bb \u00ab\u00a0We want to Wow the user\u00a0\u00bb et j\u2019en passe et des meilleurs.<\/p>\n <\/p>\n Aujourd\u2019hui encore, la confusion design \/ dessiner existe. Je ne compte plus les blagues et remarques \u00ab\u00a0voil\u00e0 le bureau de l\u2019\u00e9quipe design, ils font de jolis petits dessins\u00a0\u00bb (true story) et autres \u00ab\u00a0non mais j\u2019ai pas tes talents artistiques\u00a0\u00bb. Mais on ne dessine pas une interface<\/strong>, on la con\u00e7oit<\/strong>. Dessiner est rarement une activit\u00e9 collaborative d\u2019ailleurs (bon, ok, sauf dans ces ateliers de co-conception o\u00f9 on transforme le dessin en activit\u00e9 collaborative). Alors que concevoir, si. La collaboration est le c\u0153ur de notre travail, et le c\u0153ur de la conception d\u2019un produit. Et on con\u00e7oit en \u00e9quipe !<\/p>\n <\/p>\n Du coup, n\u2019en d\u00e9plaise aux Jean Michels Dipl\u00f4me-en-art-plastiques, je vous le dis, encore une fois, et j\u2019esp\u00e8re que vous allez faire passer le message : le design d\u2019interface, le web design ce n\u2019est pas du dessin, ce n\u2019est PAS de l\u2019art. <\/strong>Et non, je ne mettrai pas un coup de peinture sur votre Bootstrap pour sauver votre projet <\/strong>parce que client a dit qu\u2019il \u00e9tait moche. Point.<\/p>\n Les m\u00e9thodes de conception d\u2019interface et d\u2019UX design sont issues du domaine de la science<\/strong> (neuroscience, psychologie cognitive, et du marketing) et non de l\u2019art.<\/p>\n Cette premi\u00e8re partie faisait le constat quelque peu d\u00e9faitiste, certes. Dans la seconde partie, je vous expliquerais comment je proc\u00e8de pour remettre l\u2019humain au c\u0153ur de nos processus de conception, tout en continuant d\u2019utiliser templates et frameworks UI.<\/p>\n Je n’ai pas de solution miracle, mais je vous propose ma m\u00e9thode pour tenter de mener \u00e0 bien des projets qui utilisent des frameworks \/ templates UI tout en ayant une d\u00e9marche centr\u00e9e utilisateur dans la suite :<\/p>\nQuelques d\u00e9finitions.<\/h2>\n
C’est l\u2019histoire d\u2019un projet\u2026<\/h2>\n
Au d\u00e9but tout commen\u00e7ait bien<\/h3>\n
\n
\n
Mais au fait, qui va se charger du design de l\u2019application iPad ?<\/h3>\n
\n
C\u2019est juste un prototype, on peut proposer des am\u00e9liorations\u00a0?<\/h3>\n
Les coups de peinture qui ne suffiront pas \u00e0 rendre l\u2019application utilisable.<\/h3>\n
Architecture d\u2019information, un nouvel espoir<\/h3>\n
R\u00e9alit\u00e9s et deadlines fatidiques<\/h3>\n
Une histoire parmi tant d\u2019autres\u2026<\/h3>\n
La place des frameworks dans notre industrie<\/h2>\n
L\u2019utilisation des frameworks ne se limite pas aux \u00e9quipes de d\u00e9veloppement<\/h3>\n
Pourquoi utiliser vous des frameworks UI ou templates ?<\/h3>\n
La place du design dans un projet qui utilise un framework<\/h2>\n
Le choix du framework avant la moindre analyse business ou utilisateur\u2026<\/h3>\n
Le framework, une bo\u00eete \u00e0 outils magiques de composants<\/h3>\n
La \u00ab\u00a0dette d\u2019interface\u00a0\u00bb<\/h3>\n
Le design, ce petit coup de peinture sur le framework en fin de projet<\/h3>\n
Mais du coup, on fait quoi ?<\/h2>\n