Research for
cultural infrastructure
Before African Music Library existed as a website, it existed as a question at Josplay: how do you structure the world's most comprehensive knowledge base of African music so people can actually use it? As a side project, I took on the foundational research: the user stories, the entity model, the information architecture, and the critical flows. The platform you can visit today grew out of that groundwork.
The artifact that framed the whole exploration: one search field, ten kinds of knowledge behind it.
A library with no building yet
Structure a knowledge base for African music
First, the library.
African music is rich, and it is chronically misdocumented. Metadata is scattered, inconsistent, or missing entirely, which keeps African artists undercounted in the digital economy and keeps students and researchers working far harder than they should.
Josplay set out to close that gap with African Music Library: a knowledge base of African music built by musicologists, engineers, and literary experts, spanning artists, bands, genres, instruments, scholarship, and more.
This research came first. When I did this work, the platform did not exist yet. The library that is live today at africanmusiclibrary.org grew out of this structural groundwork, then was designed and built by the Josplay team.
Rich collections. No obvious front door.
A library is easy to fill and hard to enter. The more comprehensive the collection becomes, the harder the entry question gets. Straight from the wall:
A student cramming for an assignment, a musicologist tracing a genre, a curious listener, a developer calling an API. Different vocabularies, different definitions of "found it."
An artist belongs to a genre, plays an instrument, signs to a label, shows up in a journal. When every entity links to every other, where does navigation begin??
Subscriptions and API tiers fund the work. Put the gate one step too early and the library stops feeling like a library.
The question was never "what should the screens look like." It was: what is the shape of the knowledge, and how do different people walk through it?
Start with the people
I worked in four moves: write the user stories, name the entities, structure the architecture, then walk the critical journeys as flows. Screens came last, in low fidelity, because every earlier decision constrains them. The stories came first.
"As a busy undergraduate studying music, I want access to a library of African music resources so I can complete assignments, projects, and personal learning."
Enters through search. Success = a citable source in minutes.
"I'm tracing how highlife moved between countries and decades. I need the connections, not just the entries."
Enters through an entity, follows the links. Success = lineage they can verify.
"I'm building with African music data. I need clean, documented endpoints before I commit."
Enters through API docs. Success = a first successful call.
three visitors, three doors... one library
Name what the library holds
Before pages, an inventory. Everything in the library resolves to one of a small set of entities, and every later structure hangs off them. These names become the navigation, the filters, the search categories, and the API's nouns.
the ten categories in the search bar map straight onto these
Give the knowledge a structure
The architecture answers the entry question three ways at once: search for people who know what they want, browsable resource sections for people who don't yet, and dedicated paths for research, pricing, and the API. The same entities appear at every level, so wherever you enter, the vocabulary is familiar.
The information architecture, condensed from my board. Scroll sideways to walk the full width of the library.
Walk the critical journey
The flow that matters most is the student's: from opening the library to holding a usable source. The single hardest decision in it is where the subscription gate sits. I placed it after the first taste of value, at the moment of committing to a resource, never before search. Discovery stays open; depth sustains the library.
also mapped: account creation (phone or email verification → security checklist) and the forgotten PIN recovery path... no dead ends survive on paper
What the structure taught me
Four conclusions I still carry into work that has nothing to do with music.
Entities beat pages
People do not think in site sections. They think in artists, genres, and instruments. When the same entities become the navigation, the filters, and the API's nouns, every path through the library speaks one language.
Search is the front door
Whoever controls search controls whether a collection is usable. The richer the library, the more the front door matters.
Access has a shape
Where the paywall sits is an information architecture decision, not a business afterthought. Gate before search and the library feels closed. Gate at depth and it feels generous and sustainable at once.
An API is a user too
Developers arrive with their own mental model and their own definition of success. Treating the API as a first class audience, with examples and use cases in the architecture, changes what the product even is.
What held, and what grew past it
I did this research before the product existed. The Josplay team designed, built, and has spent the years since growing the library you can visit now. Coming back to it, this is what I can see of the structure inside the finished thing, and what the finished thing taught me that my research had not.
The entity model held
Artists, bands, genres and instruments are still the browse layer of the live library, and the same nouns run through search, the resource pages and the sitemap. Whatever else changed, the vocabulary stayed. That is the part of this work I am most confident about, because it is the part that had to survive contact with real data.
The top level got simpler and warmer
The live library organises itself as Data, Knowledge, Projects, Participate and About, and the homepage leads with writing: essays on highlife, on Dakar, on the origins of a dance. My architecture optimised for retrieval. The product also had to make people care, and a library about culture probably needs a story on the front page more than it needs a filter panel.
The access question resolved a better way than mine
I designed around a subscription gate placed after the first taste of value. AML now describes itself as a not-for-profit, so the question stopped being where to charge and became how to keep the library open while still funding the work. Data partnerships, metadata submitted to the DDEX standard, and collaboration with collecting societies now do the job I had given to a paywall.
I would write a fourth user story
My three visitors, the student, the researcher and the developer, were all people taking knowledge out. The live library devotes a whole section to people putting knowledge in: record labels and publishers submitting catalogues, writers joining the biography programme, academics contributing journals. For a library whose founding problem is missing metadata, the supply side may be the most important audience of all, and I did not write a story for them. It is the first thing I would add if I picked this up again.
The smallest project. The clearest window.
This project shows how I think when nothing exists yet. No inherited patterns, no live traffic, no screens to critique. Just a domain worth caring about and the discipline of structuring it before drawing it.
It began as side research for Josplay. The library it helped shape is live, it has grown well past what I mapped, and going back to compare the two is the most useful thing this project has given me.