Dans le cadre du workshop Reboot Factory, l'objectif était l'élaboration d'une webapp au départ d'un problème de la vie courante et de s'intéresser à la conception pour petits écrans, aux affordances, à l'utilisabilité et au contexte d'utilisation tout en répondant à des critères comme les 5W (why, when/where, who, what).
Réalisé avec Julie Huygens, France Herry et Jérémy Gilles.
Case-study
Problématique
La première étape est de définir une problématique à laquelle l'application répondra. Chacun note sur des post-its des problèmes de la vie courante, quels qu'ils soient, pendant un temps défini (là, on découvre qu'on a des points communs et des problèmes de la vie courante parfois fort spécifiques). On les affiche ensuite sur un panneau, et on définit ceux qui peuvent être résolus par une application.
Ensuite, on utilise la méthode de zen voting pour définir notre idée préférée. On zen vote à l'aide de petites gommettes (plutôt stylées dans notre groupe) qu'on place sur les post-its. Au final, une problématique sort du lot : «Je ne sais pas quoi faire quand j'ai un trou dans mon horaire et que je ne peux pas rentrer chez moi».
On teste l'idée en se posant 5x la question pourquoi ? Et on en définit l'application en répondant aux fameux 5W :
L'application permet aux utilisateurs qui ont un temps limité à passer hors de chez eux entre 2 activités de trouver où aller/que faire pour occuper leur temps de manière intéressante/productive.
Personas
On créé des personas, des utilisateurs fictifs qui vont nous aider à définir les besoins et contextes d’utilisation de notre application. C’est là que naissent Sébastien Grattoir, 34ans, gestionnaire de projet qui aime la culture et n’aime pas perdre son temps qui est parfois amené à avoir 1h de temps libre entre deux réunions loin de son domicile ; Alan Thys, 20ans, étudiant en droit, qui est curieux et aime découvrir des nouvelles choses et dont les profs annoncent souvent leur absence au dernier moment ou encore Célestine et Cristal.
Grâce à ces personas, on prend conscience qu’on doit pouvoir toucher plusieurs publics au niveau des propositions et que les quantités de temps libre sont variables.
Architecture d'information
Il est temps de préciser le contenu de l’application, les différentes fonctionnalités et pages qu’elle contiendra. On liste donc les différents types de contenu dont on aura besoin (photo du lieu - image; nom du lieu - texte; filtres - fonctionnalité; etc.) et on les regroupe en différentes pages. S’en suit le tri à cartes: on fait faire le même exercice à des personnes qui ne connaissent pas notre application, en leur expliquant brièvement le concept, pour peut être dégager des fonctionnalités/contenus auxquels on a pas du tout pensé.
A d’autre personnes, on propose nos cartes, avec nos éléments, et on leur demande des les organiser, pour tester notre architecture.
De ces tests, on a retenu que certaines personnes souhaitaient lier l’application à la leur réseaux sociaux ou voulaient d’abord régler les différents paramètres (temps, catégories) pour ensuite accéder aux propositions d’activité.
Avec toutes ces données, on établit une liste de besoins, d’envies et de désirs. Le besoin est clairement obtenir des propositions d’activités selon notre temps libre. On décide de placer la possibilité de filtrer les résultats dans les envies et le lien avec les réseaux sociaux dans les désirs. C’est un plus intéressants, mais ce n’est pas le centre de l’application.
Wireframes & prototyping
Il est temps de concevoir des wireframes qu’on testera par la suite. Sur ceux ci, on demande en premier le temps que l’utilisateur a devant lui, puis on lui présente la sélection d’activités, avec la possibilité d’en ajouter à une liste de favoris ainsi que la possibilité d’activer ou désactiver des filtres.
Durant les tests, on se rend compte que les filtres on tendance à rendre l’expérience plus confuse, et que les utilisateurs ne retrouvent pas leurs favoris. Les filtres et les favoris sont plus sources d’ennui qu’ils sont utiles, et on ne parvient pas à les placer sur un design visuel sans faire perdre du sens à la page. On doit repenser nos écrans.
On recommence alors, on se focalise sur la proposition de lieux selon le temps disponible, faisons une chose et faisons la bien. On propose de nouveaux écrans et on vote à nouveau.
Des images et du code
Grandis de cette décision de ne pas conserver de fonctions inutiles, nous nous sommes lancés dans des recherches de design visuel plutôt laborieuses. Tour à tour trop simple, trop plat, trop élaboré… Nous avons finalement élaboré un design simple et efficace, avec un rouge qui domine notre palette de couleurs.
L’application se présente sous forme de pages superposées, la première étant la page de définition du temps au dessus de laquelle viennent se positionner les cartes d’activités. Notre principal objectif étant de créer une application rapide d’utilisation et de permettre à nos utilisateurs d’optimiser leur temps libre de façon constructive et intelligente.
Concernant les propositions d’activités, nous nous sommes limités à quelques possibilités dans les environs de l’école, de différents types, pour simuler une liste de propositions qui serait générée par rapport à notre position lors de la présentation.
Présentation & futur potentiel
J'ai choisi de réaliser cette présentation sous forme d'une mise en situation. Nous avons donc suivi Simon dans sa matinée, dans son train, où il apprend que son premier cours est annulé et qu'il aura donc du temps libre. Mais n'ayez crainte. Il avait Tiptime.
Pour le potentiel futur de l'appli, nous avions retenu des tests utilisateurs la possibilité de se connecter aux réseaux sociaux, un système de filtres/catégories d'activité (sport, nature, nourriture, zen, ...) et un système de favoris/à regarder plus tard.
Dans l'ensemble, j'ai beaucoup aimé cet atelier. J'ai eu l'occasion de toucher à tout et de pouvoir expérimenter un design sprint sur un cas concret, et c'est probablement cette partie que j'ai préférée.
Voir le projet