Okidou

Application mobile

Aider les capitaines de hockey à trouver des remplaçants. En évitant les messages texte ennuyeux et répétitifs et en créant leur liste personnelle de joueurs sympas avec lesquels jouer.

Contexte

Présentement, Okidou est à sa deuxième version de prototype (low fidelity).

Projet

Comment pouvons-nous aider les capitaines avec les remplacements?

Équipe

1 product designer - Chantal
1 développeur - Yann

The begining

Trouver des remplaçants au hockey semble être une problématique, mais pourquoi? Y a-t-il des circonstances précises? Quelles sont les répercutions avant, pendant et après?

C'est la problématique que Yann et moi avons choisie. Nous adopterons l'approche Lean Startup et avec l'accord de Yann, je documenterais notre évolution ici même en live.

Users interview

Avant d'émettre des idées de solutions, nous souhaitions valider le problème et mieux le comprendre. Deux capitaines d’équipe ainsi qu’une organisatrice de matchs récréatifs ont accepté de me parler de leur expérience. Voici quelques exemples de questions ouvertes utilisées :

  • J'aimerais que tu me parles de ce que tu trouvais le plus difficile, dans la gestion de l'équipe?
  • Peux-tu m'aider à comprendre, comment tu gérais les absences de dernières minutes?
  • Avais-tu trouvé des solutions pour rendre te faciliter la tâche?

Avec les enregistrements audio, j'ai pu noter les informations en 5 catégories; Pain, Gain, Job, Solution et info. Les 3 premières sont tirées du livre Value Design Proposition. Nous aurions pu émettre des hypothèses sur ces points. Mais donner la parole aux capitaines, c'est se baser sur des informations plus près de la réalité. De plus, il y a plusieurs insights que nous aurions pu imaginer. C'est intéressant de constater qu'il y a des similarités, mais aussi des différences. Ce qui nous rappelle qu'une bonne solution offre une certaine flexibilité.

Connaitre les solutions utilisées nous aidera à penser le produit. On souhaite qu’il puisse cohabiter avec les différentes solutions existantes, il peut même les appuyer ou facilité. Voici quelques exemples de solutions :

  1. Quand le capitaine sait une semaine d'avance qu'il y aura des absents, il demande en personne aux remplaçants présente à la game d'avant de revenir la semaine prochaine.
  2. Quand il a épuisé sa liste de contacts, il demande à certains joueurs réguliers de lui référer ou de contacter directement des remplaçants.
  3. Chaque année, les capitaines ont généralement 2 joueurs fiables et disponibles à qui ils demandent en premier.

Les interviews on confirmé la problématique donc on continue.

Value
proposition

Répondre à un seul problème très précis et extrêmement bien.

PAIN
Concentrons-nous sur ce qui fait le plus mal à nos capitaines et ce qu'ils tentent d'accomplir. En hiérarchisant les informations, nous précisons que les remplacements sont principalement "douloureux" lorsque les absences sont annoncées à la dernière minute et que les remplaçants réguliers ne sont pas disponibles. Ce qui arrive surtout en fin de saison. Nos capitaines se lancent alors dans une série de messages répétitifs et ennuyeux.

GAIN
Ce qui motive les capitaines à bâtir une équipe, c'est de pouvoir choisir avec qui ils jouent; leurs amis. Le calibre est aussi un enjeu dans la mesure où c'est le fun d'avoir une équipe compétitive! Cette même logique revient lors de la recherche de remplaçants.

JOB
Les capitaines sont des leaders bien organisés, ils souhaitent que tout se passe bien. Ils se sentent responsables de leur équipe. Jouer à -1 ça va, la défensive peut jouer avec un seul changement. Mais à -2 c'est plus difficile, les trios d'avant sont alors défaits. Dans les matchs amicaux, un manque de plusieurs joueurs affecte le niveau de jeux. Les joueurs ont généralement moins de plaisir et peuvent décider de ne plus revenir.

Nous avons décidé d'utiliser la formule suivante pour résumer la proposition de valeur de notre solution. Elle sera notre ligne directrice que nous tenterons de valider.

Our application
helps hockey captains
who want to find replacements
by avoiding boring and repetitive text messages
and by creating their personal list of cool players to play with.

Est-ce bon, est-ce que ça fonctionnera? On ne sait pas! La seule façon de le savoir c'est de vérifier avec les capitaines le plus tôt et le plus concrètement possible.

Wire frame &
prototype 1

Le coeur du prototype 1: automatiser les messages.
Le challenge : que les capitaines prennent le temps de bâtir leur liste.
Souvenons-nous que ce qui fait vraiment mal ce sont les absences dernière minute. Cet effet de rush pourrait-il écarter notre solution? De plus, Old habits die hard. Notre approche du challenge se résume à : Pouvons-nous faire de l'app un outil de gestion des spares pour toutes les absences, pas seulement celles dernières minutes? Ainsi permettre aux capitaines de bâtir graduellement leur liste et de créer une habitude d'utilisation.

Passons à l'action, notre premier objectif est simple : valider si notre approche (automatisation des messages) génère de la valeur aux yeux des capitaines. Nous avons donc décidé de bâtir le plus rapidement possible une façade qui a pour but de voir l'intérêt, la réaction des capitaines. C'est toujours un peu insécurisant de montrer un truc laid à moitié fonctionnel... Mais passer du temps à rendre une mauvaise idée belle est malheureux. Nous avons donc débuté par un wireframe présentant le flow possible entre le téléchargement de l'app et une demande de remplaçant.

J'apprécie particulièrement cette étape. Nous l'avons fait Yann et moi en travaillant seul côte à côte, ensuite nous avons partagé nos wires frames puis les avons modifié. En travaillant seul en premier, nous arrivons à ce concentrer et aller plus en profondeur (contrairement au brainstorm). Bonus, quand tu as un programmeur expérimenté, il beaucoup d'insights de faisabilité du coup on sauve du temps!

Combien de capitaines d'équipe de hockey savent ce que c'est un wireframe? Très peu, ce qui rend la chose difficile à présenter... Mais combien de capitaines savent ce que c'est une app? C'est le temps de prototyper, avec le wireframe sous la main c'est assez rapide.

Rappelons notre challenge : que les capitaines prennent le temps de bâtir leur liste même si le problème est principalement de dernière minute. Notre approche : faire de l'app un système pour gérer les spares en tout temps afin d'être prêt lors des cancellations dernière minute. Pour ce faire, nous pensons qu’il est important de s'inspirer et de s'intégrer aux solutions existantes.

  1. Vous souvenez-vous l'interview : souvent, le capitaine demande aux remplaçants présents de remplacer la semaine suivante. Dans ce premier prototype on permet de retirer des joueurs avant de commencer les messages.
  2. Durant l'importation des joueurs, le capitaine a aussi la possibilité de demander des références à ses joueurs. Comme il le fait dans la "vraie vie".

Users test 1

Même si le prototype n'était pas complet, j'avais l'opportunité de le mettre dans les mains d’une organisatrice de match amical. J’ai observé qu’il y avait de l’hésitation avant de cliquer sur les boutons. Es-ce le style low fidelity prototype? C’est peut-être aussi le flow "obligé" nous n’avions pas pensé d'inclure une navigation, elle manquait donc peut-être de de vision d’ensemble. De plus, comme je souhaitais principalement valider l'idée et pas l'usabilité, j'ai omis de donner une directive claire (Exemple : tente d'ajouter un spare et de faire une demande de remplaçant). L'hésitation provenait peut-être du manque de directive clair.

Lorsqu’elle a compris que les sms se feraient tout seuls, elle a dit : "ça serait carrément super comme app". Nous devrions tenter de faire comprendre ça dès le début.

Nous avions donné le nom de "Assistant Capitaine" et je parle de capitaine depuis le début. Mais elle m'a mentionné que même si elle organisait les matchs, elle n'était pas capitaine.

Finalement nous avons abordé un sujet difficile à évaluer ; est ce qu'elle paierait pour ce genre de solution? Je vais m'abstenir de donner les détails puis que je crois que la réponse viendra seulement avec un vrai paiement. Il y a souvent un gap entre ce que les gens disent et font.

Low fidelity
prototype 2

Pour ce prototype l'objectif est de faire comprendre rapidement que les messages textes se gèrent tout seuls, c'est cette idée que l'on souhaite valider après tout! Pour ce faire, j'ai ajouté du texte. Mais avant de nommer la solution, j'ai décidé de mentionner le problème de façon précise: Cancellation dernière minute? Jusqu'à maintenant j'ai parlé à 5 responsables d'équipes et ils sont tout bien organisé avec un bon réseau et s'exprimant bien. La majorité du temps, trouvé un spare n'est pas un problème et heureusement! Notre solution vise les exceptions, les cas de dernières minutes. C'est pour cette raison que je mentionne le problème en premier.

Suite aux feedback du premier prototype, j'ai aussi décidé de changer le nom de l'app. Pour fitter avec tous les organisateurs, capitaines et gestionnaires. Le nom et l'icône sont inspirés de ce que l'on souhaite; un joueur qui dit Oui, OK (hockey) ou Okidou. Bref je crois que vous avez compris! J'ai aussi validé la disponibilité du nom au registraire des entreprises du qc, aux marques de commerce canada et la disponibilité d'un nom de domaine avec une extension décente comme .app.

Finalement, j'ai ajouté un menu, pour briser le flow forcé et encourager à cliquer pour découvrir l'app.

Landing page
& add

Nous souhaitons vérifier si la solution est intéressante, et ce avant même d'avoir touché une ligne de code. C'est important de se rappeler de ne pas être en amour avec notre solution avant que les clients ne tombent en amour avec celle-ci. À ce stade nous sommes encore prêts à tout mettre à la poubelle et pivotés vers une autre solution.

Voici ce que nous tenterons d'apprendre avec une landing page et un peu de publicité:

  1. Le % de clique sur la pub nous afin de valider la traction de l'idée et de tester des audiences.
  2. Ceux qui cliquent seront dirigés vers la landing page qui servira à présenter l'idée. Nous installerons hotjar pour tenter d'en apprendre plus sur les points qui les intéressent.
  3. Le nombre de cliques sur Download nous donnera une idée de l'acquisition possible.
  4. Comme l'app n'est pas encore disponible, le lien de download dirigera vers une page expliquant la situation et proposant de laisser leur courriel pour être informé de la mise en ligne de l'app.

VISUEL
Le but est de rendre le tout crédible. Avec mon background de graphisme c'est quand même un petit plaisir de donner le look sympa et relax que Yann et moi envisageons. Le logo et les textes et images ainsi que la programmation (webflow) auront pris moins de 24h à produire. https://okidou.webflow.io/

Pricing

Nous croyons qu'il est important de penser dès le début à la monétisation de l'app. Comment pouvons-nous définir un prix. Quelle valeur la solution présente-t-elle pour les capitaines et gestionnaires d'équipes? Il faut un prix suffisamment bas pour que l'app soit utilisé de façon régulière, mais suffisamment élevé pour développer, scaler, maintenir et améliorer l'app.

Voici les étapes que nous avons décidé de suivre :

  • Faire un sondage pour connaitre les quantités et fréquences de communication.
  • Faire un test A/B avec la landing page. L'option A inclus une tarification, mais pas l'option B.
  • Une version Beta. Nous avons décidé de clairement mentionner que la version était en test. Afin de nous permettre de faire des ajustements de tarification si nécessaire.

Market research

Je met cette étape à la toute fin, même si elle à débuté en même temps que le projet. Notre analyse du positionnement des compétiteurs continue de grandir.

Nous croyons qu'il faut suivre notre voie. Se baser sur nos propres recherches et aucunement sur ce que les autres proposent. Par contre nous croyons aussi qu'il faut êtres différent. Radicalement différent. À suivre!

Covid -19

Le prototype #2 était près le 11 mars 2020... Le 13 mars, toutes les installations sportives gérées par la ville de Montréal sont fermées. Le 15 tous les arénas sont fermés et les rassemblements de 10 personnes et plus fortement déconseillés.

Le 16 mars, nous demandions aux capitaines et gestionnaires de répondre au sondage. Le taux de participation était de 50%. Deux jours plus tard moins de 10%.

Comment pouvons-nous connaitre l'intérêt pour notre solution lorsque plus personne ne joue au hockey?