Application Campus Car
Campus Car était un projet de groupe en deux parties, la première étant une phase de recherche (avec Ambre Geiss, Manon Jeanpierre et Mathilde Vauquieres) et la seconde une phase de conception (avec seulement Ambre Geiss).
L’idée était de proposer un service de covoiturage pour le personnel et les étudiants des pôles universitaires du Doubs, comme une sorte de BlaBlaLines local. Ce projet était lié au parking connecté disponible sur le pôle de Montbéliard, malgré un impact mineur sur les rendus finaux.
Recherche
Dans un premier temps, le travail a consisté à monter un dossier faisant la somme de nos recherches sur le sujet avant de s'attaquer à la conception. Que ce soit une analyse concurrentielle, une observation de la cible et la conception de cartes d’expériences mais également un bref listing de fonctionnalités et un Moodboard. Un ensemble qui devait nous servir de documentation pour les étapes suivantes et qui nous permettrait d’éviter les gros écueils que peut avoir un projet de ce genre : sans cibles définis, sans idée de l’état de la concurrence ou sans idée claire du service qu’il cherche à rendre.
Retrouvez le dossier complet
Conception
Dans un second temps, il nous a fallu élaborer un User Flow à partir du scénario utilisateur afin de transmettre schématiquement l’ensemble des actions possibles pour l'utilisateur ainsi que leurs imbrications les unes aux autres.
De ce User Flow, nous avons tiré un Wireframe de l’application, ici sous Adobe XD, afin de préciser le zoning et l'ergonomie générale de l’application. L’occasion également de venir préciser quelques usages.
Enfin, une fois le Wireframe finalisé, il était temps de passer à la Maquette. Nous avons repris la charte graphique de notre Moodboard et l’avons appliquée au Wireframe. L’ensemble des pages - et états de page - ont ensuite été reliés et prototypés pour répondre à un maximum de cas d’usage.
Des problèmes et des solutions
Le plus intéressant dans ce genre de projet est de trouver des réponses, que ce soit aux frustrations ou aux problèmes que pourrait rencontrer un utilisateur, mais également aux limites que pourrait avoir le projet lui-même.
Par exemple, en choisissant de ne se baser que sur les personnes travaillant ou étudiant sur les pôles universitaires, nous diminuions largement les utilisateurs potentiels comparé à une application classique du genre. L’idée fut alors de savoir comment résorber ce manque. Notre solution fut de générer automatiquement des trajets en fonction des disponibilités données par les conducteurs et de faire apparaître ces trajets comme suggestion aux autres utilisateurs. De cette façon nous limitions la recherche manuelle tout en nous assurant plus de conducteurs qu’avec une inscription manuelle, ceux-ci n’ayant qu’à accepter ou refuser les demandes des passagers.
Les problèmes de ce genre étaient nombreux, parce que même si le covoiturage domicile/travail n’est pas nouveau, le contexte de l’application nous obligeait à revoir certaines choses acquises. Pour donner un autre exemple, c’est également dans cette logique là que nous avons décidé de nous passer d’un système de notation pour partir sur un simple système de recommandation (qui jouerait dans l'algorithme de suggestions). Étant donné que les personnes auraient de très fortes chances de partager le même lieu de travail, le risque de “mauvais joueur” serait de toute façon limité, à contrario un système de notation entre personnes pouvant se côtoyer quotidiennement aurait pu créer certaines tensions dispensables. Un système de recommandation simplifie et lisse le côté "évaluation de l’autre” tout en conservant certains aspects positifs de la notation.
Certainement qu’il existe encore dans notre modèle de nombreuses questions irrésolues, mais cette suite de problèmes et de solutions à différentes échelles est ce qui rend ce genre de projet intéressant. Que ce soit sur des questions assez fondamentales comme celles traitées plus haut, mais aussi de choses plus anecdotiques qui comptent aussi dans l’expérience de l’utilisateur final, comme la hiérarchisation, l'expressivité des interactions… Bref, l’ensemble de la composition qu’est l’interface.