Bill it : case study

Dans le cadre de l’atelier de travail Reboot-Factory, nous avons été amenés à créer de toute pièce une application mobile. L’enjeu principal étant de prendre conscience des différentes contraintes liées à ce support autour d’un travail collectif et de nous préparer à être capable de réagir face à l’arrivée d’un nouveau support. De ce travail est né Bill it, une application qui vous permet de diviser votre addition au restaurant comme bon vous semble.

1. La problématique

Pour être vraiment utile, une application mobile se doit de répondre à un besoin. Nous avons donc pris notre temps pour voir ensemble quelles étaient les situations dans lesquelles une application pourrait nous être secourable. Nous avons exploré plusieurs pistes qui nous semblaient cohérentes, nous en avons discutés longuement ensemble pour finalement faire notre choix à l’aide d’un zen-voting. Nous avons décidé de travailler à résoudre cet épineux problème qui peut se présenter lorsque vous êtes au restaurant avec vos amis et qu’arrive l’heure de l’addition. Un problème auquel nous nous sommes tous déjà confrontés.

2. Un besoin mobile

Une fois notre problématique établie, nous avons décidé de prendre à nouveau du temps pour y réfléchir et s’assurer que notre projet répondait bel et bien à un besoin mobile. Nous avons pour cela utilisé plusieurs astuces, entre autres les cinq W qui permettent de placer l’application dans son contexte (What, Who, Where, When, Why?). La création de persona nous a également été d’une grande aide pour établir la liste des fonctionnalités nécessaires au bon fonctionnement de notre application.

3. Un défi ergonomique

Mais le cœur du problème avec Bill it, c’était de proposer quelque chose de plus rapide et de plus facile que la calculatrice standard déjà présente sur nos smartphones. C’est donc au travers d’une série de sketchs rapides que le groupe a dégrossis ce qui nous semblait être la meilleure manière de gérer les différents éléments.

Il nous a vite semblé évident qu’il y avait deux grands cas de figure dans notre situation classique: les gens qui voulaient répartir leur addition équitablement (sauf exceptions quand quelqu’un décide d’offrir le vin par exemple) ou ceux qui voulaient répartir les coûts au détail et ne payer que leur part (parce que Jean-Michel il a quand même pris entrée-plat-dessert alors que Georgette elle a juste mangé une salade). Il nous a donc semblé plus facile de départager clairement ces deux cas d’entrée de jeu, pour pouvoir proposer à chacun d’entre eux un menu adapté à leur situation.

4. La microcopy

Une fois une première version de nos wireframe établie, nous avons procédé à tout une série de tests utilisateurs. Cela nous semblait vraiment essentiel avec un projet comme le nôtre. Il aurait été vite fait d’oublier notre propre connaissance du projet et de l’architecture que nous lui avions façonnée. Et ces tests ont en effet révélé un gros souci de copywriting. Des termes qui nous semblaient clairs ne l’étaient de toute évidence pas pour les non-initiés au projet.

Il nous a donc fallu nous pencher avec une grande attention sur la microcopy de notre application avant de la soumettre à nouveau à une série de tests utilisateurs. Après quelques-uns de ces ajustements, nous sommes parvenus à un résultat satisfaisant.

5. La réalisation

Une fois ces étapes derrière nous grâce à un effort collectif, il fut temps de nous répartir équitablement le reste du travail, chacun s’occupant du domaine qui lui plaisait le plus, ou bien celui où il se sentait le plus à l’aise. Sauf, bien sûr, certaines tâches trop colossales que pour être gérées par une seule personne dans un laps de temps aussi court. Mais malgré ça, il nous a semblé essentiel de ne pas couper les connexions entre nous et de continuer à collaborer ensemble à la construction du travail.