Toshokan.

01 //

Contexte

Toshokan est née de mon expérience des communautés manga et anime. Je fréquentais ces espaces, mais retrouver d’autres fans d’une œuvre précise et suivre les discussions pertinentes restait parfois compliqué.

J’ai voulu vérifier si cette frustration était partagée avant de concevoir une application. Deux questionnaires réunissant [nombre de réponses] réponses et [nombre d’entretiens] entretiens m’ont permis de confronter mon intuition à des profils et des habitudes différents.

J’ai construit le projet avec un cofondateur chargé du développement. J’ai pris en charge la recherche, la conception et l’acquisition. Ensemble, nous avons défini les priorités et les arbitrages techniques.

02 //

Le problème

Les personnes interrogées ont décrit des échanges dispersés entre réseaux sociaux, forums et serveurs communautaires. Trouver un espace actif autour d’une œuvre moins connue demandait souvent de multiplier les recherches.

Les retours ont également fait ressortir des problèmes de modération et des interfaces jugées vieillissantes ou difficiles à utiliser.

Le besoin était de faciliter la rencontre entre des fans partageant un intérêt précis et de leur donner un accès direct aux contenus et aux discussions qui les intéressaient.

Pour un nouveau produit communautaire, un second enjeu est apparu dès le lancement. Il fallait rendre l’activité visible alors que le nombre de membres et de publications était encore limité.

03 //

La solution

J’ai conçu Toshokan autour de communautés dédiées à chaque œuvre. L’utilisateur rejoint celles qui correspondent à ses centres d’intérêt et y retrouve des publications, des discussions et d’autres fans.

Cette organisation donne un point d’entrée concret dans l’application. Le parcours commence par une œuvre connue, puis ouvre sur les contenus et les échanges associés.

Après le lancement, nous avons complété cette logique avec un fil global regroupant les publications. Il permet de découvrir l’activité disponible dans l’application et de créer davantage d’occasions d’interagir pendant la croissance des communautés.

04 //

Mon intervention

Recherche et cadrage du produit

J’ai préparé les questionnaires, conduit les entretiens et étudié les espaces concurrents. J’ai ensuite traduit les besoins récurrents en parcours et en fonctionnalités, avec un premier périmètre centré sur la découverte des communautés et les échanges autour des œuvres.

Conception des parcours et de l’interface

J’ai réalisé l’architecture de l’application, les parcours utilisateurs, les wireframes et les interfaces dans Figma. J’ai également construit les composants et le design system pour conserver une cohérence entre les écrans et accompagner les évolutions.

J’ai notamment travaillé l’entrée dans une communauté, la consultation du fil, les publications, les discussions et la navigation.

Coordination avec mon cofondateur

J’ai formalisé les besoins et les propositions d’évolution, puis défini les priorités avec mon cofondateur en tenant compte de leurs implications techniques.

Après le lancement, nous avons arbitré les évolutions selon la fréquence des retours, l’importance du problème, l’effort de réalisation et la cohérence avec la direction du produit.

Acquisition et lancement

J’ai travaillé l’acquisition à travers TikTok, les contenus organiques, les partenariats avec des communautés existantes, une liste d’attente et des actions sur des salons. J’ai complété ces canaux avec des campagnes publicitaires à petite échelle.

La bêta a réuni [nombre de testeurs] testeurs. Leurs retours ont contribué à identifier les incompréhensions, les problèmes d’interface et les attentes avant et autour de l’ouverture publique.

Analyse des usages et suivi des évolutions

J’ai croisé les retours qualitatifs avec les utilisateurs actifs quotidiens, hebdomadaires et mensuels, les publications par utilisateur et l’activité des communautés.

J’ai regroupé les retours dans [outil ou méthode de centralisation], puis discuté des priorités avec mon cofondateur. Nous avons relié l’observation des usages à la conception d’une réponse, à sa mise en développement et au suivi après publication.

05 //

Décisions clés

Faire de chaque œuvre un point d’entrée communautaire

La recherche a fait ressortir une difficulté à retrouver d’autres fans autour de titres précis, particulièrement les moins connus. J’ai donc organisé les communautés à l’échelle des œuvres.

Ce choix relie directement l’architecture du produit à un besoin observé. Une personne qui suit un manga dispose d’un espace identifiable pour retrouver du contenu et engager une discussion avec des lecteurs qui partagent cet intérêt.

Repenser une fonctionnalité conçue trop tôt

J’ai d’abord conçu une fonctionnalité pour trier et retrouver différents contenus, notamment des théories, des œuvres et des chapitres. Après le lancement, j’ai constaté qu’elle était peu utilisée.

Nous avons retenu l’hypothèse qu’elle répondait à un besoin de classement avant que l’application dispose d’un volume suffisant de contenus. Nous l’avons transformée en un espace donnant un accès plus direct aux discussions des communautés suivies et aux actualités des œuvres favorites.

Cette évolution a reçu de meilleurs retours utilisateurs. Elle a surtout permis de recentrer la fonctionnalité sur un besoin adapté au stade réel du produit.

Rendre l’activité visible avec un fil global

Au démarrage, la répartition des publications entre plusieurs communautés pouvait donner une impression de faible activité.

Nous avons ajouté un fil global pour réunir les publications dans un même espace. Les communautés restent le lieu des échanges autour des œuvres, tandis que ce fil facilite la découverte de contenus et les occasions d’interagir.

Ce choix vise à accompagner la croissance du produit avec une expérience adaptée à son volume réel de contributions.

06 //

Résultats mesurés

[X] % de rétention à J7

[X] % des nouveaux utilisateurs reviennent sur Toshokan sept jours après leur première utilisation. La mesure porte sur [population mesurée, bêta ou lancement public] et sur les premières utilisations comprises entre [date de début] et [date de fin], d’après [source de mesure].

[nombre] téléchargements en [durée]

Nous avons publié l’application sur iOS et Android. Entre [date de début] et [date de fin], elle a enregistré [nombre de téléchargements] téléchargements.

J’ai consacré [budget publicitaire] € à la publicité sur cette période. L’acquisition a également reposé sur les contenus organiques, la liste d’attente, les partenariats communautaires et les actions sur le terrain.

[taux] % d’activation sur [période]

L’activation correspond ici à [action précise réalisée dans un délai donné]. Sur [nombre de nouveaux utilisateurs] nouveaux utilisateurs, [nombre d’utilisateurs activés] ont réalisé cette action, d’après [source de mesure].

Une fonctionnalité mieux accueillie après sa transformation

Le nouvel espace consacré aux discussions suivies et aux actualités a reçu de meilleurs retours que la fonctionnalité de tri initiale.

[Retour utilisateur représentatif ou mesure d’usage avant et après la transformation à compléter.]

07 //

Enseignements

Adapter les fonctionnalités à la maturité du produit

Ce projet m’a appris à examiner le moment auquel une fonctionnalité devient utile. Un outil de classement peut être pertinent lorsque les contenus sont nombreux, tout en apportant peu de valeur au démarrage.

Depuis cette expérience, je prête davantage attention aux conditions nécessaires pour qu’une fonctionnalité soit utilisée. Le volume de contenus, le nombre de membres et leurs habitudes font partie du problème à résoudre.

Évaluer les contenus marketing à partir de leur effet

Certaines publications simples ont mieux fonctionné que des contenus ayant demandé beaucoup plus de production.

J’en ai retenu l’intérêt de tester plusieurs angles et formats avant d’investir davantage dans leur réalisation. Le temps passé à produire un contenu ne prédit pas son efficacité. Les réactions de l’audience et les résultats observés permettent d’orienter les efforts.