Recherche utilisateur chez Saturn : Favoriser l'innovation grâce à l'empathie envers l'utilisateur
Par Joe Parry
•
8 juillet 2024
🛠 Construire pour résoudre un problème personnel
Saturn est né d'un besoin réel et d'un problème observé de première main par Dylan et d'autres camarades lors de leur fréquentation du lycée Staples. Cette circonstance représente la forme la plus pure de recherche utilisateur : résoudre ses propres problèmes. Pour construire un excellent produit qui apporte de la valeur aux gens, il est essentiel de se mettre à leur place et de voir le monde à travers leurs yeux. Lorsque cette personne, c'est vous-même et ceux qui vous entourent, l'échange d'informations de la recherche utilisateur à la construction du produit est immédiat, vous permettant d'aborder et de résoudre directement vos propres défis.
Au départ, l'expérience directe des étudiants de Staples a conduit le développement de Saturn. Une compréhension intime des besoins des étudiants dans un lycée unique avec un ensemble particulier de conditions signifiait que la recherche utilisateur était naturellement intégrée dans le processus de développement de produit. Au fil du temps et alors que le produit s'est développé et a évolué, la distance entre les problèmes des utilisateurs et le développement du produit a augmenté, incitant à un effort plus concentré pour comprendre comment les utilisateurs vivent le produit et répondre à leurs besoins. Un accent continu sur la recherche utilisateur assure qu'au fur et à mesure que le produit change, il continue de résonner avec les utilisateurs et de résoudre les bons problèmes. Maintenir cette connexion étroite avec notre public cible est devenu de plus en plus critique, surtout depuis que l'équipe n'est plus au lycée elle-même.
Alors que Saturn a grandi et s'est étendu dans des dizaines, puis des centaines, et maintenant des milliers de lycées à travers les États-Unis, ce qui a commencé comme des observations générales ou des conversations informelles avec des camarades sous forme de retours sur le produit a évolué vers la pratique de recherche utilisateur que nous employons à grande échelle aujourd'hui.
⚖️ Notre approche de la recherche utilisateur à grande échelle
Nous intégrons la recherche utilisateur dans trois phases principales du processus de développement de produit : idéation et brainstorming, prototypage de design et retour post-lancement.
🧠Idéation et brainstorming : Avant de concevoir une nouvelle fonctionnalité ou une nouvelle expérience utilisateur, nous allons réfléchir à divers problèmes que nous pourrions résoudre. Ceux-ci pourraient découler de nos propres pensées sur les choses que nous aimerions voir dans le produit, d'une direction principielle que nous voulons prendre en tant qu'entreprise, ou de retours que nous avons reçus d'utilisateurs dans le passé. Par exemple : nous avons longtemps entendu des utilisateurs exprimer le désir d'une fonctionnalité de groupes pour organiser des clubs et des équipes sur la plateforme ; nous avons récemment terminé le développement de cette fonctionnalité et commençons à la déployer.
Il est important de mener des recherches en amont pour s'assurer que nous nous concentrons sur les bons problèmes, et non sur un problème qui n’existe pas ; après tout, nous avons des ressources limitées et devons les allouer avec précaution ! À ce stade, nous distribuerons des enquêtes à nos utilisateurs pour solliciter des opinions, organiser des discussions en forum ouvert pour voir comment diverses idées résonnent, et évaluer les retours sur la façon dont les utilisateurs réagissent à la direction.
🎨Prototypage de design : Une fois que nous avons une direction plus ou moins claire sur le problème à résoudre, nous passons à la phase de conception, où nous explorons plusieurs options visuelles pour ce à quoi l'expérience pourrait ressembler. Typiquement, à ce stade, nous aurons plusieurs options viables de ce à quoi le produit final pourrait ressembler, et c'est un autre bon moment pour obtenir des réactions de nos utilisateurs sur leurs préférences, et pour vérifier les angles morts que nous aurions pu avoir pendant la phase de conception. Nous ferons généralement cela de manière informelle en montrant à notre communauté d'utilisateurs bêta divers prototypes dans Figma et en synthétisant les retours pour le design afin de les incorporer et d'itérer.
♻️Retour post-lancement : Après avoir déployé une fonctionnalité ou un changement, en plus d'examiner les données pour voir comment les utilisateurs interagissent avec le produit, nous continuons également à rassembler des retours qualitatifs d'un ensemble plus large d'utilisateurs en production. Cette recherche continue nous aide à comprendre comment les utilisateurs vivent le produit final et nous permet d'apporter les ajustements nécessaires en fonction de l'utilisation en situation réelle.
🤔 Contrôle des biais des utilisateurs
Un défi aigu auquel nous faisons face lors de la conduite de recherches utilisateurs est que nous pouvons recevoir des retours biaisés si nous ne sommes pas diligents pour les prendre en compte. Nous avons ici un problème de champagne — nos utilisateurs les plus engagés ADORENT le produit, et sont impatients de donner de leur temps et d'aider à enrichir l'expérience en participant à la recherche et aux retours sur le produit. En conséquence, si nous ne faisons pas attention à obtenir des insights d'un échantillon divers et représentatif d'utilisateurs, nous pouvons nous exposer à une chambre d'écho de retours à sens unique, pour découvrir que les données d'adoption plus générales ne sont pas là une fois que nous mettons en œuvre la recherche et construisons quelque chose.
Par exemple, notre communauté de bêta-testeurs très engagés, qui a tendance à se diriger vers des utilisateurs organisés et de type A (ce sont des utilisateurs puissants des calendriers, après tout), peut demander un ensemble de fonctionnalités hautement personnalisables parce qu'ils les utiliseraient réellement. Cela ne signifie pas que nous ne devrions pas nous adresser aux utilisateurs puissants et construire des fonctionnalités pour répondre à leurs préférences, mais nous devons faire attention à ne pas prendre cela comme une demande plus large de l'ensemble de notre base d'utilisateurs. Pour y remédier, nous essayons d'être intentionnels en reconnaissant quand un biais utilisateur est acceptable et quand il ne l'est pas. Par exemple, le biais utilisateur peut être moins critique lors de l'évaluation des réactions à l'utilisabilité d'un prototype de design que lors du brainstorming de nouvelles fonctionnalités potentielles. Pour contrôler le biais dans la pratique, nous recueillons des retours d'un sous-ensemble diversifié de nos utilisateurs sur diverses dimensions lorsque la distribution d'échantillon est un input pertinent.
L'équipe de Saturn lors d'un appel de recherche utilisateur
🏭 Notre processus : Tactiques que nous utilisons pour obtenir des insights utilisateurs
Passons maintenant aux détails. Chaque semaine, nous prenons une question qui est au cœur de nos préoccupations et menons une recherche « mission ». Cette mission peut correspondre à l'une des 3 phases du cycle de vie détaillées dans la section ci-dessus (idéation, conception, post-lancement), ce qui informe également les critères de l'audience que nous sélectionnons pour participer à la mission. Une fois que nous avons bien défini l'objectif de la mission et les critères de l'audience, nous menons la recherche par divers canaux :
📜Enquêtes opt-in intégrées dans le produit — Cette méthode est la meilleure lorsque nous voulons établir une base quantitative et obtenir un volume plus élevé de retours sur une question concrète et spécifique, comme « Combien de groupes êtes-vous membre dans votre école ? » Cette méthode nous permet également de cibler des utilisateurs à travers une grande variété d'attributs et de modèles d'utilisation différents pour ensuite segmenter les résultats et identifier des différences qui se démarquent entre différents types d'utilisateurs.
🖥️Interviews utilisateurs et groupes de discussion sur zoom — Cette méthode est la meilleure pour des discussions exploratoires plus ouvertes, où nous souhaitons discuter d'idées avec nos utilisateurs et évaluer les réactions dans un environnement plus flexible.
📳Discussions de groupe et sondages Instagram — Nous engageons une communauté proche de bêta-testeurs / volontaires par le biais d'une série de discussions de groupe et notre instagram. Ces canaux sont les meilleurs pour obtenir un signal rapide et peu contraignant sur une question à laquelle nous avons besoin de réponse, et où le biais utilisateur est moins préoccupant. Un exemple pourrait être « Votre bal de fin d'année inclut-il des sophomores ou seulement des juniors et des seniors ? »
🏫Visites scolaires et événements en personne — Nous organiserons périodiquement des événements sur ou à proximité des campus scolaires de notre réseau, et ceux-ci constituent une excellente occasion d'obtenir des retours de produit non filtrés ainsi que d'observer les utilisateurs interagir avec l'application en temps réel.
🗣️Outils d'enquête audio par IA — Plus récemment, nous avons expérimenté des outils d'enquête basés sur l'IA comme Alpharun, où nous posons des questions sous forme d'enquête mais l'utilisateur répond par audio ; les retours sont ensuite synthétisés dans un résumé généré par IA avec des thèmes et des conclusions communs. Cette méthode agit comme une sorte d'hybridation entre une enquête et un appel utilisateur en direct sur zoom, et fait gagner du temps aux deux parties.
Calendrier / Feuille de route de recherche utilisateur de Saturn
🚙Recherche en Action : Un exemple illustratif
Un exemple récent qui souligne l'importance de rester proche de nos utilisateurs s'est produit lors d'une visite scolaire. Nous avons organisé un événement de crème glacée dans une école voisine pour présenter et tester notre fonctionnalité d'événements publics sur le calendrier avec un public réel. Avant l'événement, nous avons placé l'événement public dans le calendrier de l'école, et pour que les étudiants puissent y entrer, nous leur avons demandé de montrer qu'ils avaient trouvé l'événement et s'étaient inscrits. Après avoir confirmé leur présence, un modal apparaissait pour inviter les utilisateurs à ajouter également l'événement à un calendrier externe (Apple cal ou Google cal).
Alors que nous observions les étudiants passer dans la file, nous avons commencé à remarquer quelque chose d'intéressant. Lorsque l'invite de calendrier externe apparaissait, de nombreux étudiants tapaient sur le bouton Ajouter au Gcal. Lorsque nous avons approfondi la question, nous avons découvert que la plupart d'entre eux n'utilisaient pas réellement Google Calendar, mais tapaient simplement sur l'option par confusion sur la façon de fermer le modal. De retour au siège, nous avions débattu de l'utilité de cette fonctionnalité d'intégration et de sa suppression possible pour rationaliser le produit, mais lorsque nous avons examiné les données, nous avons vu un nombre significatif d'utilisateurs ajoutant des événements à leur Gcal, et avons donc opté pour la conserver car les utilisateurs en tiraient de la valeur. Après avoir vu à plusieurs reprises les utilisateurs taper sur l'option comme moyen de le fermer, nous avons réalisé que les données que nous voyions étaient trompeuses, et que l'observation du comportement des utilisateurs était la confirmation dont nous avions besoin pour aller de l'avant.
L'équipe Saturn lors d'un événement sur le campus
