Design web & mobile

TipTime

0 – Le pReboot

Un e-mail, une demande, une liste.

Nous avons, dans un premier temps, composé une équipe de trois. Trois personnes se connaissant, connaissant notre façon de travailler, ayant déjà travaillé ensemble, donc ensemble pour ce Workshop.

Mais trois n’égalent pas quatre. Hors quatre personnes sont nécessaire pour valider la liste.

Quelques jours plus tard…Une bouteille à la mer, un S.O.S, un appel à l’aide. Un DWM  en détresse ! Nous l’avons accueilli dans notre groupe, il fait maintenant partie de l’équipe des TipTimeurs. Que l’aventure commence !

 

0.1 – Le Reboot

Le Reboot, c’est le workshop de création d’application mobile de l’option DWM. On forme des groupes de 4 et on réalise une appli en partant de post-its et de cartons plumes au format monstrueux. Le principe est 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).

 

1 – Design Sprint

On commence la création en suivant la méthode de design sprint de Google.

 

1.1 – Une 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.

reboot-9

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.

1.2 Des 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 (voir photo).

reboot-6

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.

 

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

reboot-5

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 au propositions d’activité.

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

1.4 Wireframes, prototyping et design visuel

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.

reboot-1

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.

2 – Design visuel et anarchie

Grandis de cette décision de ne pas conserver de fonctions inutiles, nous nous sommes lancés dans des recherches de design plutôt laborieuses. Tour à tour trop simplet, trop plat, trop chicos… Nous avons finalement élaboré un design simple et efficace, avec un beau rouge dynamique qui domine notre palette de couleurs.

 

screens_reboot

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.

Et c’est là que l’anarchie débuta. Nous nous sommes pourtant répartis les tâches… Mais au final nous avons tous touché à tout, et en résulte des fichiers étranges. Un rouge qui varie de nuances d’un document à l’autre et des typos qui s’amusent à s’interchanger… Du coup, c’était le bordel dans les fichiers et dans nos têtes, amazing !

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.

 

3 – Du codage de luxe

Nous avons laissé notre petit nouveau DWM s’essayer au codage du site de présentation de l’application. Mais manquant d’expérience, c’est dans la sueur et le sang que les anciens ont repris la bataille afin de réaliser un codage digne de ce nom. Pendant que notre recrue bataillait de son côté pour trouver par quelle magie diabolique: est-il possible de prendre un screenshot d’un itinéraire google map entier…à la verticale ?

Pour l’application, après maintes tentatives parfois étranges, le système de liste d’activités fonctionne, et après des tentatives quasi désespérées, le système de filtre de temps est fonctionnel ! Le sentiment du devoir accompli.

 

4 – La fin.

C’est la fin, on termine les derniers petits (et les gros) détails.

Ce fut une expérience très enrichissante ! Nous avons découvert une méthode de travail très efficace pour créer une application à partir de rien qu’on pourra appliquer à de futurs travaux. En plus, on aura touché au « monde du mobile », et on aura pu se rendre compte que ça n’a rien à voir avec les « grands » écrans, qu’il faut tout revoir et que tout s’adapte.

 

     Projet au hasard