Bien commencer un projet UX

Que ce soit un projet, un brief ou résoudre une problématique, le plus dur c’est de trouver l’angle d’attaque. Cette ouverture qui guidera tout le long du projet jusqu’à sa réalisation. C’est pourquoi cette étape souvent appelée « brainstorming » est prise en considération et l’étape d’idéation est souvent plus longue que la production du sujet en lui-même. Il ne s’agit pas seulement de créativité ou d’imagination, c’est aussi du pragmatisme et du rationalisme. L’imagination dépend de l’émotion et de l’expérience d’une personne, tandis que les méthodes d’idéation se basent sur l’étude et l’adaptation du contexte.

Que ce soit un service, une fonctionnalité, un bouton, une réaction d’un utilisateur, il faut toujours se demander pourquoi il a lieu d’être ?

Pourquoi mettre un menu hamburger en haut à gauche ? Pourquoi ajouter cette fonctionnalité ? Pourquoi l’utilisateur a t-il refusé de recevoir la newsletter ? Autant de questions auxquelles il faut se forcer à répondre.

Normalement tous les produits ou services ont une fonction qui répond à un problème humain, donc par nature ils répondent à la question « pourquoi », ce qui justifie leur existence. La question « pourquoi » peut se poser de manière macro comme micro. On peut se demander pourquoi on a fait ce choix d’interface comme on peut se demander pourquoi on utiliserait ce produit plutôt qu’un autre ?

Cela évite qu’on se laisse emporter par l’enchaînement de nos réflexions, que l’on s’écarte du spectre et que l’on oublie pour qui on le fait. Il faut se demander pourquoi et le demander aux autres. Les différents avis pourront ouvrir de nouvelles opportunités.

Si lors de l’ajout d’une fonctionnalité, la réponse à la question « pourquoi » ne se rattache pas à la réponse de la problématique globale alors vous pouvez oublier cette fonctionnalité, il n’intéressera pas l’utilisateur.

Un problème a souvent plusieurs solutions, le fait de se demander « pourquoi »  vous guidera dans le choix de la solution la plus adaptée à votre contexte. Il faut pousser le vice jusqu’au bout en se reposant la question à la réponse du pourquoi jusqu’à avoir une raison tangible.

Une expérience digitale ne se restreint pas à l’utilisation de l’interface, mais aussi à l’environnement dans lequel elle est utilisée. Ainsi il faut absolument prendre en compte le contexte d’utilisation que va impliquer l’utilisateur.

Il faut imaginer la journée type de l’utilisateur cible, afin de cerner les différents points de contact et distinguer les contextes d’utilisation. Ce plan, appelé user journey facilite la compréhension du parcours utilisateur et permet de faire ressortir un grand nombre de contraintes.

De manière plus simple, on peut se concentrer sur avant et après l’utilisation du produit, le contexte technique comme humain, il faut se poser les bonnes questions pour cerner le plus de moments de friction.

Exemple de question qui définit le contexte avant l’utilisation :

– Que faisait-il juste avant d’utiliser le produit ?

– Que doit faire l’utilisateur pour commencer à utiliser le produit ?

– Quelle information vient-il juste de recevoir ?

– Est-ce que le contexte d’utilisation influence l’usage du produit ?

– Est-ce qu’il peut avoir des problèmes de connexion ?

– Quelle humeur l’utilisateur peut avoir et comment cela peut influencer l’utilisation ?

– Combien de temps a t-il à consacrer ?

– etc.

Exemple de question qui définit le contexte après l’utilisation :

– Est-ce qu’il a accomplie sa tâche ?

– Pour quelle raison a t-il quitté sa tâche ?

– Comment lui permettre de continuer son utilisation sur un autre support ?

– Comment le tenir informé de la suite si sa tâche n’est pas finie ?

– Est-ce que l’utilisateur a besoin d’un résumé de son activité ?

– En quoi le contexte a influencé le fait qu’il arrête d’utiliser le produit ?

Afin de mieux représenter ce parcours et de concrétiser ces questions, il est conseillé de sketcher rapidement les grandes étapes d’utilisation en légendant du contexte.

Il est important aussi d’avoir une vision globale de l’ensemble des fonctionnalités d’un projet, pour ce faire il est intéressant de lister toutes les technologies qu’utilise le produit, ainsi que les fonctions quelles engendrent. Aussi, on peut lister les objectifs du produit par rapport à l’utilisateur et vice versa. Grâce à ça, vous pourrez raccorder les besoins avec les fonctionnalités adéquates ainsi qu’évaluer l’envergure du projet (et donc de son coût).

On peut alors représenter les différentes fonctionnalités en fonction du parcours de l’utilisateur. Ainsi on établit ce que cela implique comme technologie et si elle est acceptable en fonction du contexte d’utilisation.

Essayez d’utiliser Siri en plein concert : impossible. Dans ce cas là le contexte ne permet pas l’utilisation, donc la technologie de reconnaissance vocale n’est pas adaptée. C’est pourquoi avoir une liste de toutes ces possibilités offre une vision d’ensemble et évite les écueils.

Il faut torturer votre projet en l’imaginant dans des situations improbables mais réalistes. Il faut penser à toutes les contraintes qui lient le contexte, l’homme et l’utilisation. Comme expliqué dans cet article, le contexte handicape parfois l’utilisateur et donc a une influence sur l’expérience avec votre produit. En rajoutant des contraintes ou en imaginant des nouveaux points de contact, on peut réussir à faire évoluer son concept. Imaginer que d’un coup votre produit ne peut être utilisé qu’avec une seule main, ou que la connexion est très lente ou encore que l’utilisateur ne va lire aucun texte de plus de 3 mots. Ces contraintes fortes vont pouvoir ouvrir de nouvelles portes et laisser place à de nouveaux usages.

Au moins, cela vous permettra de vérifier que votre expérience est ouverte au plus grand nombre d’utilisations.

Ajouter des nouvelles technologies ou imaginer que le support est totalement différent, cela permet encore une fois d’élargir votre vision sur la conception du projet. Pour finalement être certain d’avoir envisagé la meilleure des solutions.

 Crédit photo : Peter Deltondo

 Inspiration article : Benjamin Berger