Chez Troopers, nous utilisons Figma pour designer et prototyper nos interfaces. Figma annonce régulièrement de nouvelles fonctionnalités de plus en plus impressionnantes. Après la sortie des Figjam, l’outil de design propose désormais de [nouvelles fonctionnalités]((https://www.figma.com/blog/whats-new-in-figma-october-2021/)) dont les “**composants interactifs**”.

C’est une fonctionnalité qui va faire plaisir aux clients et économiser pas mal de temps. Les clients souhaitent souvent utiliser le prototype comme si c’était une vraie application. On ne peut pas leur en vouloir mais ça pose un problème de taille : designer chaque interaction de chaque bouton ou menu prendrait un temps infini.

Récemment, pour la refonte d’un tunnel, nous allions envoyer le prototype aux clients lorsque nous nous sommes rendus compte que le menu mobile ne se dépliait pas sur chaque écran.

## Les composants à la rescousse
Première réaction : il va falloir créer un écran pour chaque menu déplié et prototyper chaque menu pour qu’il s’ouvre au clic. 

Un composant dans Figma, c’est un élément de la maquette ou de mon wireframe que je peux réutiliser à l’infini. Par exemple, au lieu de dupliquer un bouton menu sur chaque écran, je crée un composant et le place sur chaque écran. Si je dois le modifier plus tard (par exemple à la demande du client), tous les boutons seront modifiés d’un coup.

Le souci des composants, avant la dernière mise à jour, est qu’ils permettaient la duplication du design mais pas celle des actions du prototype. C’est désormais possible car les composants sont devenus interactifs !
https://www.figma.com/blog/prototyping-updates-and-interactive-components/

Regardons en détail comment cela fonctionne.

Une fois le composant menu créé, je lui crée un état “déplié” avec la fonctionnalité variation et j’ajoute une animation au sein même de ce composant. Une fois le composant importé dans un écran, il a deux états et une animation : je peux donc l’importer sur tous les écrans sans avoir à me soucier de son fonctionnement ! Quand je le modifie, tout le prototype est modifié d’un seul coup.

Je crée d’abord un composant “Menu” (Ctrl+Alt+K) : 


## Les variantes pour décliner les états d’un composant

Je veux ensuite créer une variante pour définir l’état de mon menu “ouvert”.

Sur la barre de droite cliquez sur “+” à côté de “Variants” pour ajouter une variante et saisissez le nom de la variante. 

J’ai appelé la propriété “open” et les variants “On” et “Off”

Les [variantes](https://www.figma.com/blog/bridging-design-and-code-with-variants/ ) nous permettent de regrouper et d'organiser des composants similaires dans un seul conteneur (exemple : 1 seul composant Input aura 5 état : focus, hover, disabled, error).

Une fois le composant et ses variantes créées, je peux importer ce composant dans les écrans. Je retrouve mes composants dans “Assets”. Je choisis le composant que je viens de créer, je fais un glisser-déposer dans l’écran.

Une fois importé, je peux choisir quelle variante de mon composant je dois afficher, à droite dans la section qui porte le nom du composant : ici MENU.


## Comment activer les composants interactifs ?
Ce dont j’ai besoin à présent c’est de prototyper ce composant afin qu’au click il passe de l’état “Off” à l’état “On”. Puis quand je clique sur l'icône “close” il passe de l’état “On” à l’état “Off”.

Maintenant, à chaque fois que j’importe ce composant, l’action est importée avec lui ! Je n'ai plus qu’à importer ce composant sur tous les écrans et ne plus me soucier à ce que le menu puisse se déplier ou non.

Pour que cela fonctionne en lançant le prototype, il faut bien activer les composants interactifs dans l’onglet “Prototype” : 

Finalement, le client a un prototype encore plus interactif entre les mains et n’a pas à consulter un écran précis pour voir comment marche le menu. Cela ne m’a pas fait trop perdre de temps. L’exemple du menu est assez courant mais vous pouvez aussi utiliser les composants interactifs avec une checkbox par exemple pour passer de “checked” à “unchecked”.

Composants interactifs : Figma donne vie aux prototypes !

C’est une approche créative durant laquelle l’équipe va explorer, co-créer puis recueillir des avis sur la solution prototypée. 
Une méthode éprouvée que l’on adore pour **tester le marché rapidement** sans gaspiller des mois de conception et de développement.

À l’agence, cela fait maintenant 5 ans que nous avons adopté cette méthode pour adapter les solutions de nos client·e·s. aux réels besoins de leurs utilisateur·trice·s.

Jusqu’à présent, Coralie et moi (nous sommes les deux facilitatrices de l’agence) avons toujours pris beaucoup de plaisir à concevoir et à animer ces ateliers en présentiel. Alors lorsque le coronavirus s’est dangereusement manifesté, nous avons dû repenser le design thinking… à distance ! Et ça nous a, disons... donné quelques sueurs froides.

## J-10 : Nos appréhensions sur le design thinking en visio

Aussi confiantes que Jean-Claude Dusse pour conclure, Coralie et moi avons entamé l’organisation des ateliers de design thinking en listant nos craintes respectives liées à la visio-conférence :

- **la connexion internet** : le B-A-BA du télétravail ! À cela près que nous n’avions pas anticipé qu’une pandémie mondiale nous obligerait à travailler de chez soi et donc à s’équiper d’une connexion aux petits oignons.
Et, en attendant, les bugs de connexion pour une formation basée essentiellement sur les échanges, ça craint. N’EST-CE PAS ?! 

- **la fluidité des échanges** : en début d’atelier, on a l’habitude d’instaurer un petit geste manuel  🙆  pour indiquer aux participant.e.s lorsqu’ils doivent mettre en pause leur conversation et écouter les consignes. 
Mais en visio-conférence, on a beau agiter nos mains telle la reine d'Angleterre à l’écran : au mieux personne ne le remarque, au pire vous perdez toute street credibility. De quoi vous donner envie de chercher une autre astuce pour réguler la parole !

- **les outils** : avec Coralie on est plutôt team post it et paperboards pour afficher aux murs toutes les réflexions qui nous mènent à la solution. 
En visio, adieu nos post it chéris et bonjour aux outils en ligne adaptés à la collaboration.

- **la fatigue** : en plus de l’épuisement des écrans, le risque majeur des événements en ligne est lié à la tentation du web. Il est en effet très facile de décrocher à un moment de la journée, puis de consulter ses mails, ses réseaux sociaux,… Il faut donc continuellement **intéresser l’équipe**, la raccrocher au wagon si nécessaire et lui transmettre une montagne de motivation !

## J-5 : Plan de bataille pour aborder ces ateliers en toute sérénité !

À une poignée de jours de nos premiers ateliers de design thinking en ligne, Coralie et moi nous sommes inscrites à des workshop et meet up numériques. 

Et vous allez très vite comprendre son utilité ! L’objectif derrière ces inscriptions était pour nous d’endosser le rôle de participant.e.s, de ressentir les hausses et les baisses de motivation, de les identifier et de les comprendre pour y remédier dans nos rôles de facilitatrices.

Que ce soit pour le design thinking ou pour un tout autre sujet, je vous conseille vraiment d’**aller voir ce qui se fait ailleurs** en ciblant une problématique sur laquelle vous avez envie de travailler. Dans notre cas, nous avons étudié la facilitation en ligne et la prise de parole, et cela nous a été très utile pour :

- prendre du recul sur notre propre rôle de facilitateur·trice
- nous comparer et nous inspirer des orateur·trice·s rencontré.e.s
- noter les imperfections que l’on remarque chez les autres pour les gommer chez soi !

Voici une liste (non exhaustive) de ce que nous avons appris pour préparer au mieux des ateliers de co-création en ligne !

### Envoyer un mail collectif pour informer et rassurer les participant·e·s

Quelques jours avant le début des ateliers, on vous conseille d’envoyer un email aux participant.e.s pour permettre à chacun.e d’aborder le design thinking avec sérénité et enthousiasme. 

Dans ce mail, on rappelle :

- le jour, l’heure et le(s) lien(s) de visio conférence
- l’objectif des ateliers
- le matériel nécessaire à la journée et les outils / logiciels à télécharger au besoin. N’oubliez pas les feuilles et les feutres, ça peut s’avérer utile pour relancer la motivation !

Et on explique :

- comment prendre en main les outils de collaboration à travers un petit **tuto préparatoire** ! Cela vous évitera de perdre du temps le jour J et de décourager les équipes
- les règles du design thinking et les **bénéfices de la méthode** pour avoir des personnes motivées le jour J

Et bien sûr, comme vous avez hâte de travailler avec votre client, dites-lui ! L’enthousiasme est communicatif :-)

### Faire mémoriser les règles du design thinking

Une des forces du design thinking est de réunir des profils pluri-disciplinaires qui n’ont pas l’habitude de co-créer, pour les faire réfléchir et travailler ensemble sur le projet.
Mais quand on n’a pas l’habitude de collaborer avec des personnes, il y a des automatismes qui restent, entre autre, à cause du statut hiérarchique qui leur incombe ou des personnalités de chacun.e !

Par exemple, certain.e.s ont du mal à sortir de leur rôle de leader.euse tandis que d’autres ne valorisent pas suffisamment leurs propres idées, certains ont peur de prendre la parole ou encore d’autres ont des difficultés à ne pas être dans la contestation.

Un joli petit plat de spaghettis qu’il faut réussir à démêler **en transmettant et en expliquant en amont les règles** pour éviter de faire du sur place durant les ateliers !

Une des règles les plus difficiles auxquelles se prêter est d’accepter le fait que son idée soit jetable et remise en question ! De fait, il faut accepter les propositions des autres participant.e.s et imaginer des solutions à partir des idées des autres. C’est un exercice périlleux où notre égo revient parfois au galop ! :-)

Plus que des mots, je vous conseille d’illustrer ces règles à travers des petits exercices ludiques pour faciliter leur mémorisation ! 
Cela peut être :

- des ateliers où l’échange doit être construit uniquement à partir de l’idée de l’autre “Oui ET” ;

- des jeux de rôle pour illustrer la règle “Ne jugez pas les autres” où l’on apprend à formuler son avis avec respect et bienveillance ;

- des exercices où l’on dispose d’un temps très court pour dessiner un maximum d’idées pour faire comprendre aux participant.e.s qu’on ne cherche à favoriser ni la qualité ni les détails dans la première étape du programme mais simplement **l’émulsion d’idées, la quantité**.



**Et surtout, amusez-vous !**

### Vérifier que les outils soient suffisamment performants

Pour éviter des problèmes de compréhension et de rapidité, pensez à demander à chacun.e de vérifier la vitesse de sa connexion en amont des ateliers via l’outil https://www.speedtest.net/. 
En dessous de 1 Mbps dans les deux sens de la ligne passante, c’est franchement pas jojo ! Il vous faudra trouver un autre lieu pour participer aux ateliers à distance.

En amont, vous pouvez aussi organiser une rencontre en visio avec tous les participant.e.s : cela demande (un petit peu) plus de temps, mais vous assurera une bonne fluidité dans les échanges !

### Alléger les journées de design thinking à distance

Lorsqu’on organise des ateliers de design thinking ou des design sprint, les journées sont souvent très intenses et on ressort lessivé.e.s ! Pour ne pas mettre l’équipe sur les rotules avec la visio (qui est très énergivore), nous avons pris la décision d’alléger les journées et de ne fonctionner que sur des **matinées ou des après-midis d’ateliers**.

Cela nécessite de mobiliser son équipe sur plus longtemps, mais cela garantit la créativité et la motivation des participant.e.s !

## Jour J : Nos outils en ligne pour des ateliers réussis 

### Meet : notre outil de visio-conférence

Meet est un outil de visio-conférence professionnel et **gratuit** (à condition d’avoir un compte Google ou une adresse gmail). 

Nous l’avons choisi pour plusieurs raisons :

- les participant.e.s n’ont pas de logiciel à télécharger et peuvent s’y connecter en ligne
- l’interface est légère, rapide et intuitive
- il est possible d’intégrer le lien de la réunion à une invitation Google Agenda
- on peut facilement créer des salles de visio séparées lorsqu’on passe à des travaux en petits groupes puis revenir à la salle principale pour débriefer
- la mise en page est très simple lorsqu’on souhaite voir les participant.e.s sous forme de mosaïque, partager notre écran, etc.

Un outil pratique pour communiquer et travailler ensemble !

### Mural : notre outil chouchou pour collaborer à distance

Coralie et moi avions découvert Mural lorsque nous avons suivi la [formation design sprint au Laptop](https://v3.lelaptop.com/formation/cycle-design-sprint-5-jours/). À l’époque, on ne s’en servait que pour certains ateliers comme le benchmark en allant piocher des idées sur la toile et en les regroupant sur un grand tableau blanc collaboratif comme ici :

Dans les grandes lignes, on adore Mural pour :

- la facilité de **prise en main** de l’outil qui n’exclut pas les participant.e.s moins à l’aise avec le numérique ;

- les **possibilités de création** de l’outil : en partant d’une page blanche, c’est très simple de créer son atelier, d’ajouter des photos, des textes, des post it, des formes, des icônes ;

- l’outil est ludique et permet à tou.te.s d’être actif.ve sur le projet ! Combiné à des ateliers plus fun papier / crayons en visio et le dynamisme du groupe reste intact !

- le **mode “facilitateur”** pour fixer des éléments, ajouter du temps qui défile sur une planche de travail, distribuer des votes aux participants sous la forme de clics, ... et j’en passe ! Mural est très complet et suffisamment riche pour ne pas avoir à cumuler plusieurs outils en même temps.

- le **catalogue de frameworks** mis à votre disposition : vous pouvez utiliser Mural en partant d’une page blanche mais l’équipe a également prévu tout un tas de planche à réutiliser (Canvas, SWOT, roadmap, storyboard, carte d’empathie, matrices, méthodes agiles, …) ! 


L’outil est **payant** mais vous pouvez tester l’outil gratuitement pendant 30 jours avant de vous décider si Mural correspond bien à tous vos besoins.

## J+10 : Des client.e.s satisfait.e.s et une équipe rassurée !

Si je devais résumer, je dirais que la bonne recette pour des ateliers de design thinking à distance c’est : des outils numériques performants + de la pédagogie sur la prise en main des outils + des journées allégées + mais surtout de l’ENVIE aussi bien chez les facilitateurs.trices que chez les participant.e.s ! 

Je finis cet article avec le commentaire d’Aurélien Grocq, Responsable commercial de la société [LM Ingénierie Audiovisuel](https://www.lmi-av.com/fr) pour qui nous avons organisé et animé des ateliers de co-création :

> "Nous avons fait appel à Troopers pour une modernisation de notre site Web au premier trimestre 2020. Les ateliers de design-thinking étaient prévus fin mars/début avril, en présentiel… et nous les avions très vite mis en suspens, au moment du confinement. Nous avons finalement pris la décision avec l’équipe Troopers de tenter le distanciel, sur deux demi-journées en avril.
Une fois passé la prise en main des outils, et la déclinaison du fonctionnement en groupe/sous-groupe, le format a vraiment bien fonctionné, malgré le peu d’habitude, de notre côté, de ce fonctionnement. La bonne humeur et le partage avec les facilitateurs/trices y participe beaucoup, et ces ateliers nous ont permis, d’une part, de bien cadrer notre projet, mais aussi et surtout de « respirer », de concevoir « différemment » dans un contexte de travail à domicile forcé un peu routinier. Aucun regret !”

Merci à tou.te.s pour votre lecture et si jamais vous avez des astuces à nous partager, on est très preneurs.euses !



Merci à tou·te·s pour votre lecture et si jamais vous avez des astuces à nous partager, on est très preneur·euse·s !

Être un·e killer·euse du design thinking à distance !

Il y a quelques mois nous avons décidé de refondre le site Troopers (c’est pour bientôt…) afin qu’il représente mieux nos valeurs et une nouvelle direction dans notre stratégie de communication (#spoilerAlert).

Nous avons donc décidé d’enfermer 7 Troopers pendant 5 jours dans un appartement Nantais avec toit terrasse pour un [design sprint](https://troopers.agency/fr/boost-session) sur cette vaste thématique !
À l'issue des 5 jours je pensais repartir avec mes centaines de notes collantes et mes grilles de tests utilisateur·trices sous le bras pour designer tranquillement le nouveau site dans mon coin… Et là c’est le drame…

## Et si on faisait du pair-designing ?
Faisant admirablement écho à nos innombrables discussions sur **l’inclusion du design dans le process agile**, Johan, développeur Front de renom, à prononcé LA phrase :


***« et si on faisait du pair design ?! »…***


En tant que bonne designeuse old school, prise de court, j’ai aussitôt répondu « ah yes carrément ! »… pendant que mon cerveau était déjà occupé à déterrer les vieilles angoisses du créatif : le client derrière l’épaule, le gros index huileux sur l’écran… 

Bon en fait c’était trop cool et je dois dire que Johan n’a pas les doigts si huileux que ça… Bref, plus sérieusement !

L’origine de cette lumineuse idée c’est le “**pair programming**”, une **méthode de travail issue des pratiques agiles** et plus précisément de l'[extreme programming](https://fr.wikipedia.org/wiki/Extreme_programming) dans laquelle deux développeurs·peuses travaillent ensemble sur un même poste de travail. La personne qui rédige le code et l’autre observe. On part du postulat qu’un cerveau c’est bien mais deux c’est encore mieux ! L’observateur·trice assiste donc le·la “codeur·deuse” en décelant les imperfections, en vérifiant que le rendu est iso avec les maquettes et en proposant des alternatives de code. Les rôles peuvent bien sûr s’échanger.

Concrètement nous nous sommes installé·e·s l’un à côté de l’autre (masqué·e·s hein), moi avec mon ordi connecté à un grand écran et Johan avec son portable sur les genoux (oui il est comme ça Johan).
Nous avions sur le bureau tout un tas de **prototypes papier** des pages que nous avions **co-crées** les jours précédents et que nous devions donc maquetter. La navigation, la disposition grossière des contenus, les textes et principaux boutons étant présents sur ces prototypes papiers, cela nous a permis de nous concentrer et d’échanger sur la **charte graphique**, les principes d’**éco-conception**, et sur la **collaboration design/dev**.

En effet, pendant que je maquettais, si cela était nécessaire j’expliquais à haute voix sur quel **principe ergonomique** ou graphique je faisais tel ou tel choix etc. parfois Johan acquiesçait et parfois il en profitait pour regarder si une **solution technique non gourmande en ressources** pouvait correspondre. Si tel était le cas on passait à la suite, sinon on réfléchissait à une autre solution en essayant de creuser les raisons du besoin initial *« est-ce que l’utilisateur·trice à vraiment besoin de ça ?* » ou *« quelle va être la valeur ajoutée réelle de cette fonctionnalité ? »*
Si nous arrivions à trouver une bonne raison de conserver l’élément alors il était nécessaire de trouver une solution qui remplisse tous nos critères (graphiques, éco-conception, utilité…).

## Une fonctionnalité non implémentée au profit d’un site plus léger, éco-conçu

J’avais designé un formulaire de contact en panneau d’un tiers de la largeur de l’écran. Il s’ouvrait sur la droite, accessible depuis toutes les pages. C’était vraiment très joli. Et là Johan attire mon attention: *« il vaudrait mieux une page dédiée pour le formulaire de contact ça évitera le poids d’un script js qui se charge sur chaque page».*
De fait, c’était un comportement stylé graphiquement mais qui n’avait **pas vraiment de valeur ajoutée pour l’utilisateur·trice et qui était plus lourd**. Donc exit le formulaire “slider”, bonjour la page contact !

## Comment réhabiliter les polices système par une astuce graphique ?

Je militais depuis le début du design sprint pour que nous utilisions une **typo système** sur le futur site. Une typo qui s'affichera sur **tous les navigateurs** sans problème, **sans aucune dépendance** (au hasard Google font) et qui **ne pèserait rien**… Personne n’était vraiment convaincu que cela pourrait rendre un bon résultat graphiquement, et, en tant qu’agence web,  c’est compliqué de se lancer dans l’eco-conception trash métal (à l’instar de l’excellent [LOW←TECH MAGAZINE](https://solar.lowtechmagazine.com/) 💜). Les typos système c’est (en gros) Arial, Trebuchet, Verdana, Times, Courrier… je crois même qu’il y a la-typo-dont-on-ne-prononce-pas-le-nom.

Lorsque j’ai montré à Johan de l’arial Bold en corps 96 avec un interlettrage resserré à -5% (🙏🏻 pardon les typographes mais bon), j’ai vu l’admiration dans ses yeux… et ça vous voyez, j’aurai jamais cru le voir dans les yeux de Johan, il a fait un petit rictus d’approbation avec sa bouche et il a légèrement incliné le menton vers le bas, je ne l’oublierais jamais…
Bref. Je pense que vous avez compris.

## En conclusion, quels sont les grands avantages de la conception en paire ?  

Un·e designer avec un.e dev au-dessus de l’épaule, ça fait beaucoup moins le·la maligne, hein… 
Ici, tout s’est donc proprement goupillé dès le départ :

- Grille de construction des pages ✅
- Composants et leurs différents comportements renseignés dans le guide de style figma couplé avec storybook ✅
- Alignement des équipes design et dev sur l’esprit du site ✅
- un peu plus d’humanité dans ce monde de brutes ✅

Je pense que vous avez bien compris que la pratique du **pair designing** ou conception par paire, incluant les deux expertises à plus d’un avantage lorsqu’on veut **optimiser la collaboration entre design/dev et penser agile dès la phase de conception**.
La méthode permet à la fois au designer de mieux comprendre pourquoi intégrer les problématiques et contraintes de développement à sa logique de conception et au développeur d’adhérer aux choix graphiques et ergonomiques qu’il codera avec plaisir dans le respect du **pixel perfect** ! De plus cela permet d’éviter des incompréhensions sur la maquette, de penser “**éco-conception**” dès le départ, alors c’est tout bénef !

On a testé la refonte du site Troopers en pair design (ou conception à deux)

En tant que UX/UI Designer, je suis responsable des premières étapes de chaque nouveau projet ce qui fait que mes axes de réflexion et mes choix orientent les futurs développements. **Il est important d’avoir une vision globale du projet et de ses fonctionnalités** pour pouvoir déterminer, et fournir à l’équipe de développement (Back & Front), toutes les données nécessaires.

_Un des facteurs clés de succès d'un projet ? Fournir des livrables SMART : Spécifiques, Mesurables, Acceptables, Réalisables et Temporellement définis._

Dans cet article, je vais vous présenter un extrait de notre méthodologie afin d'**optimiser les relations techniques** (dont les échanges de fichiers) entre l'équipe de design et de développement. Notre méthodologie a continuellement évolué depuis les débuts de l'agence, et elle continuera encore, alors n’hésitez pas à nous aider à l’améliorer.

Il est important de noter que les développeurs doivent êtres impliqués dès les premières étapes créatives, pour permettre aux designers d’avoir leurs retours et avis, et ainsi définir les limites et contraintes techniques générales.

## 1/ L'arborescence

L’arborescence joue un rôle essentiel durant la première phase du projet. En effet, elle définit la première image du site aux yeux de tous et permet :

- Pour les développeurs : de visualiser les fonctionnalités, les liens de navigations et le fonctionnement général du site.
- Pour les clients : de déterminer plus rapidement les différentes étapes d’itération en établissant leurs priorités.




J’utilise [Sketch](https://www.sketchapp.com/) pour la réaliser, avec 4 niveaux pour construire toutes les connexions. Cet outil me permet d’avoir une liberté graphique et de réflexion a contrario de logiciels type [XMind](http://www.xmind.net/).


## 2/ Wireframes

Quand vous commencez à réaliser les wireframes, vous ne devez pas être interrompu ; ce n’est pas le bon moment pour débattre sur les solutions complexes et leurs alternatives techniques. L’objectif de cette étape est d’**explorer le champ des possibles pour trouver la meilleure réponse aux besoins de l’utilisateur final** et non de faciliter le travail du développeur.




_Tout est possible, c'est juste une question de temps._

Une sélection, basée sur la cohérence de la navigation tout au long du site, est effectuée parmi les meilleures wireframes réalisés. Elle est présentée aux parties prenantes (équipe presta & donneur d'ordre) pour valider les choix. Il est important d'intégrer des pistes alternatives pour nourrir le débat d’idées.

Le rendu sur Sketch est beaucoup plus proche du rendu web que via Photoshop, et ça change tout pour le développeur qui récupère le travail.

### Conseil

Soignez l’organisation de vos fichiers, pour vos collègues qui peuvent (et doivent) avoir accès à vos fichiers. Nommez, groupez et hiérarchisez vos calques de manière propre et claire.

[![organizing_your_sketch_files.webp](https://strapi.troopers.coop/uploads/organizing_your_sketch_files_111fe46f99.webp)](https://www.youtube.com/watch?v=n0Ii6MemIpg)

## 3/ Prototypage

Le prototypage est une simulation de navigation entre les différents wireframes réalisés. [InVision](https://www.invisionapp.com/) est une solution parfaite pour cela. Vous y importez vos maquettes, définissez les zones de clics, les cibles et le comportement sur chaque page, et vous obtenez votre prototype.

Il permet ensuite de communiquer avec l’équipe et le client pour avoir leurs retours et surtout avoir une première analyse in-situ sur votre travail.

Les développeurs Back pourront ainsi affiner leur compréhension des fonctionnalités alors que les Front pourront visualiser, adapter ou créer des interactions (animations, hovers, …), directement sur InVision.



## 4/ Maquettes + GUI

Bien évidemment, la présentation des maquettes est l’étape la plus attendue à la fois par le client qui va obtenir une vision très proche du résultat final, mais également par les développeurs qui prennent connaissance des éventuelles évolutions. Cette étape permet donc aux développeurs back d’adapter leur développement fonctionnel en conséquence, mais surtout aux front de bien vérifier la cohérence des composants web au travers du site.

Une fois les wireframes et le premier prototype réalisés, je duplique mon fichier sketch et le renomme en _mockups.sketch_. Les wireframes servent de modèles aux maquettes ce qui permet d'économiser beaucoup de temps car je n’ai pas besoin de recréer tous les éléments mais simplement de modifier le style des symboles en ajoutant de la couleur, des textures, des images - le tout dans Sketch.

Le G.U.I (Graphic User Interface) regroupe l'ensemble des symboles et les différents éléments de l'interface (boutons, typos, couleurs, cards, inputs ect...)

L'ultime étape concerne le développement du G.U.I sous la forme d'une interface dans laquelle les développeurs back vont pouvoir piocher les différentes briques pour construire les fonctionnalités. Cette étape est réalisé par un développeur front après validation des maquettes par le client.

## 5/ Inspect by invision

Pour l'intégration des maquettes nous utilisons [Inspect (InVision)](https://support.invisionapp.com/hc/en-us/articles/207950906-Introduction-to-Inspect) qui permet aux développeurs de connaître les espacements entre les différents blocs, de récupérer la découpe (images, icônes). il permet aussi d'obtenir quelques lignes de CSS. Bref c'est la fonctionnalité qui vient compléter le workflow de A à Z avec uniquement deux outils pour tout faire : Sketch + InVision."





## 6/ Conclusion
Cette méthodologie nous a permis d'optimiser la relation entre mon travail et les différents développeurs de l’agence. Elle permet d’offrir des livrables qualitatifs tout au long du process de création, ce qui permet de provoquer la confiance avec le client et le débat d’idées autour des fonctionnalités et de leurs actions attendues.

Nous sommes toujours en veille sur les nouveaux outils qui peuvent faire évoluer ce process, aussi si vous avez des suggestions à nous faire, ce sera avec plaisir que nous les étudierons. :)


Le blog de Troopers

Composants interactifs : Figma donne vie aux prototypes !

Être un·e killer·euse du design thinking à distance !

On a testé la refonte du site Troopers en pair design (ou conception à deux)

Optimiser son workflow design pour collaborer avec les développeurs