Benjamin Palmero

UX & Front-End Designer

ReTrello

Redesign

Voir le projet

Dans le cadre du cours d'ergonomie, l'exercice était de redesigner un service parmi Slack, Trello ou Google Drive, à la manière du redesign d'iTunes réalisé par les étudiants de la Fachhochschule Postdam.

Le principe était d'analyser le service pour repartir de zéro si nécessaire, repenser ses fonctionnalités et son interface.

Case-study

Tu veux redesigner quoi ?

Première étape, choix du service à redesigner. Slack nous paraît plutôt réussi, et, hormis quelques éléments, nous inspire peu, on a l'impression qu'il y aura trop peu à faire. Ca se joue entre Google Drive et Trello. J'utilise pas mal Google Drive mais mon équipière utilise assez peu les deux services. Après un rapide tour d'horizon des deux, il nous semble que Trello sera le plus intéressant, il peut être très utile, mais il permet trop de choses qui écartent les utilisateurs du but premier de l'application.

Trello it is.

Comment c'est maintenant et comment ça pourrait être

On commence par lister toutes les fonctionnalités de Trello et le moins qu'on puisse dire, c'est qu'il y en a beaucoup. On s'y perd un peu. Certains tableaux ne sont accessibles que si on rentre dans un sous menu, d'autres sont accessibles à 2 voire 3 endroits sur une même page, on peut activer des fonctionnalités supplémentaires, on peut rajouter 1001 choses (dont des stickers) à chaque notes, lier des notes entre elles, ...

Vu tout ce qui est possible, on désire recentrer le but de Trello, peut être enlever des fonctionnaités (peut être retirer les stickers, même si ça fait mal) pour y voir plus clair.

Pour nous, Trello, c'est vraiment utile pour gérer des deadlines et répartir des tâches. Le système actuel de cartes dans des cartes ne nous semble pas très clair ou évident. Comment trouver facilement des deadlines sous cette forme? On part alors sur l'idée de présenter un tableau Trello plutôt sous la forme d'un calendrier, chaque tâche serait un bloc, de manière à facilement visualiser ces tâches dans le temps.

Tri et wireframes

On décide d'aller droit au but et de garder l'essentiel. On garde donc le système de bloc par tâche, et les infos relatives à cette tâche (à savoir to do list, l'équipe qui travaille dessus). On part du principe que si les membres d'une équipe veulent communiquer au sujet d'une tâche, ils auront tendances à le faire via un autre service comme Slack, on veut éviter d'éparpiller des messages partout et de compliquer Trello.

Premier wireframe, présentant une interface sous forme de calendrier et des activités sous forme de blocs.
Trello sous forme de calendrier
Une carte présentant un projet
Une carte présentant un projet

Et visuellement ?

Sur base de ces wireframes, je commence donc des propositions de design visuel vraiment pas convaincantes

Des essais de designs visuels
Des essais de designs visuels

Après d'autres essais, j'en arrive à ces propositions qui demanderaient encore du travail, mais que je préfère largement et qui semblent plus claires.

L'écran principal, sous forme de calendrier
L'écran principal, sous forme de calendrier
La carte d'une activité liée à un projet avec une liste de tâche et les participants
La carte d'une activité liée à un projet avec une liste de tâche et les participants
La carte du projet avec de plus amples informations sur le projet ainsi que les responsables
La carte du projet avec de plus amples informations sur le projet ainsi que les responsables

Intégration

J'entreprends donc d'intégrer tout ça du mieux que je peux, en prenant en compte des remarques qu'on avait reçue lors d'un feedback collectif.

Vu le placement des différents éléments, j'ai décidé d'utiliser les flexbox. Ca faisait longtemps que j'avais envie de réaliser un projet en les essayant, puisqu'elles ont l'air vraiment pratiques et faciles d'utilisation. Et de fait, je ne suis pas déçu, elles sont vraiment intéressantes, même si je dois encore m'y habituer.

Au final

Lors du Reboot Factory (voir TipTime, l'application qu'on y a réalisée), on nous avait demandé de trouver un problème afin de le résoudre, et je m'étais fait la réflexion que ce n'était pas évident de trouver un problème et que j'aimerais bien tenter de résoudre un problème existant. Cet exercice de redesign était donc fort intéressant pour cet aspect là, de prendre un service existant et de le redesigner.

Comme dans beaucoup de projets, j'ai beaucoup apprécié la partie de définition du problème, d'inventaire du contenu, de définir les besoins etc. J'ai eu un peu de mal avec le design visuel et je pense qu'il pourrait encore être amélioré mais je n'en suis pas mécontent. Côté intégration, à part le fait que j'aurais aimé "générer" en js des cartes d'infos pour chaque tâche, je suis plutôt content de ce que j'ai réussi à faire tout seul et compte tenu des autres travaux à réaliser.

Voir le projet