Design web & mobile

Shake’n Cook

Shake’n Cook

Le début d’une aventure

Un jour dans notre vie d’étudiant, on reçoit un mail, et un slack nous disant que la semaine sera dédiée à un atelier : le Reboot factory. On nous demande juste d’apporter un certain matériel  et de faire des groupes de 4.

L’atelier commence, on a tout le matériel mais nous ne sommes que 3, même après que les professeurs aient essayer de faire le plus de groupe de 4 possible.

L’atelier commence, on nous explique que le but sera de réaliser un app’ web sur mobile, simple.

 

La première étape est de réfléchir à des problèmes de la vie quotidienne, chacun les écrit sur un post it et le colle sur un carton, noté sur la liste de matériel à acheté pour l’atelier.

Une fois fini, on trie les idées, et on met à droite les idées pouvant être adaptée sur mobile.

La prochaine étape est un Zen voting, chacun met une gomette sur un ou plusieurs idées qui lui plait. A ce moment la, on accueille un retardataire qui deviendra notre 4 ème membre.

Il participe tout de suite en cherchant des nouvelles idées et choisissant avec nous, l’idée finale.

L’idée avec le plus de vote était une application calendrier qui aussi propose une synchronisation des briefing deadlines ect…

Un professeur nous fait clairement comprendre que cette idée était trop complexe pour cet atelier qui voulait nous faire développer quelque chose de simple.

On est ensuite parti sur une idée, trop simple, d’application qui, quand on secoue le smartphone, un “oui’ ou un “non” s’affiche à l’écran comme les boules noires qu’on agite. (boule 8 magique)(ex: Toys Story).

Cette idée trop simple nous pension ensuite partir sur une nouvelle idée, quand le professeur nous propose de garder cette idée de secouer, mais pour une autre idée.

Et c’est comme ça qu’est nait notre idée finale :

On secoue, une recette aléatoire apparaît.

IMG_4350

Une idée originale qui plait à tout le monde, parfait, nous pouvons continuer.

Tout de suite, chacun d’entre nous a une idée bien précise de l’applications, ses fonctionnalités et son arborescence. Et par un heureux hasard, on a tous les mêmes idées.

La naissance d’une app’

Ensuite on enchaîne une série d’exercice proposé par les professeurs pour nous aiguiller sur nos choix pour le contenus et les fonctionnalités de l’app’.

Ces étapes ont été très vite pour nous, comme tout le monde y voyais clair et qu’on avait les mêmes idées.

On dessine, on réfléchit, on discute, on créé des personnas…

IMG_4357

IMG_4356

 

Ensuite vient une autre partie de la conception de l’application :

Le Squelette de l’app.

D’abord chacun fait 8 variantes d’une page de l’app, puis 4 variations.

Et enfin chacun fait un beau wireframe.  Une fois tout ça fait, on répond aux 5W:

IMG_4410

Who : Qui va utiliser notre app’? : les gens qui veulent avoir des idées de recettes.

When: Quand est-ce que ces gens vont l’utiliser? : Le soir en revenant chez soi, ou avant midi.

Where: Où? Dans le train, en marchant, chez soi….

What : Pour quoi faire? Chercher une recette.

Why: Pourquoi? Parce que la personne n’a pas d’idée de recette.

 

Ces questions vite répondue, nous passons à la prochaine étape : Faire le 1er tweet de l’app.

Les buts? Trouver un slogant et le plus important, trouver un nom, pour nous c’est tout trouvé :

Shake’n Cook

Tu secoue et tu cuisine!

Shake’n Cook!

Prochaine étape, le prototyping, le but de cette étape est de faire tester l’application version papier à l’utilisateur.

IMG_4417

On prend nos wireframes fait plus tôt, on les découpes et on met tout en place pour faire tester l’app.

L’utilisateur n’est pas testé, c’est l’application qui est testée. Au mieux, il faut qu’il pense à voix haute, et enfin nous lui donnons un but : regarder les détails d’une recette.

Tout se passe bien, le 1er utilisateur effectue sa mission sans soucis.

Deuxième mission pour un autre utilisateur, ajouter une allergie.

Dernière mission pour une autre personne :  Ajouter un favoris.

La deuxième mission qui soulève des soucis mineur et quelques discussion. On change de suite ce qu’il ne va pas et nous commençons à réfléchir à une idée de logo ou chargement.

On pense vite à l’idée du fouet qui bats dans un bol vide pour le chargement, ensuite à une idée de dès pour le logo qui tombe assez vite à l’eau car l’idée est bonne, mais personne ne peut “l’exécuter” correctement.

Le temps nous rattrape.

 

Le temps tourne et on doit s’occuper du visuel de notre application.

Chacun de son côté fait le visuel d’une page au choix, comme fait plus tôt pour les wireframes. Et puis on se consulte, on regarde et on soulève les points positifs et négatifs de chaques designs.

Pour finalement choisir un design qui de détache des autres avec les points positifs des autres.

Un design simple, qui s’intègre parfaitement au design d’iOS la plateforme choisir dans notre groupe. 2 iOS VS une Androïd et une autre pas de Smartphone, la décision à été vite prise.

Home 1

Le design choisi, la personne l’ayant fait s’occupe de faire les changements, et les autres pages, tout en demandant l’avis des autres membres du groupe régulièrement.

Ambiance détente dans notre groupe, on avance bien , tout le monde à des remarques positives et constructives. D’autres membres du groupe s’occupent de chercher des recettes pendant ce temps la.

 

Le design fini, on se décide à demander l’avis de nos professeurs, étonné de nous voir avec nos design fini et en avance sur notre retro planning. Remarques positives dans l’ensembles , quelques détails à retravailler à gauche et à droite.

Mais une remarque importante à été faite : Nous avons trop de contenus, de catégories de recettes.

On a choisi à ce moment la de faire notre application uniquement pour les recettes rapide.

Moins de contenu, moins de travail.

S’ajouter trop de travail et n’est pas intelligent, le but ici est de développer une application simple, mais à fond.

On repense au logo, qui serai cette fois ci, le bol avec le fouet, mais qui resterai aussi pour le chargement. Du coup je l’ai retravaillé pour qu’il soit plus agréable, plus “réaliste”

 

Il est temps de s’occuper de coder l’application, la landing page et de commencer le case study. Chacun sa tâche tout le monde travaille.

Pour le Case study, je commence par écrire les étapes principales du processus.

Pour la landing page, on commence par écrire le contenu et faire les Wireframes.

Enfin pour le code, on repart des visuels pour essayer de s’en approcher le plus possible.

     Projet au hasard