Benjamin Palmero

UX & Front-End Designer

Tiptime

Webapp

Voir le projet

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.

Photo du panneau sur lequel sont collés les post-its sur lesquels sont indiqués des problèmes de la vie courante.
Affichage des problèmes

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.

Photo de nos personas, accrochés sur le tableau (leur portrait et les informations les concernants)
Les différents personas

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é.

Photo d'une étudiante procédant au tri à cartes.
Sonia, triant les cartes

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é.

Photos de plusieurs étudiants participant au tri à cartes.
D'autres tris à cartes

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.

Photo d'un étudiant essayant notre prototype papier.
Alexandre, essayant joyeusement notre prototype

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.

Photo de l'écran sur la page descriptive du parc de la plante, tenu dans une main à l'extérieur.
L'écran d'une activité

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.

Photo de Simon, sur son gsm, cherchant une activité
Simon utilisant glorieusement 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