Story 1, the research journey
Making African music easier to explore
Josplay was building the African Music Library, a knowledge base of African music. My part was the user research and information architecture: who comes to the library, what it holds, and the paths people take through it. Ibkay designed the web UI from that research, and I supported some of the responsive mobile UI.
Over 3 months my work covered a review of comparable libraries, mental models and user stories, an entity model, a sitemap, task flows, low-fidelity screens and testing with 7 people. This page walks through that work.
User research and information architecture3 monthsWeb and mobile web
Client: Josplay. Web UI: Ibkay. I supported some of the responsive mobile UI.
The brief
What the library needed to answer
Josplay wanted a library of African music: artists, recordings, genres, instruments, and writing and scholarship about the music. I did not have access to their data, so I worked out from the brief and my own research what the library needed to hold and how one entry relates to another. Before drawing anything, I wrote down the questions the structure had to answer.
Other libraries
How other music libraries connect what they hold
During the project I looked at how established music databases and archives organise their collections, and how they get a visitor from one entry to the next. Each observation comes with what it meant for AML.
The content
What the library holds, and where names get difficult
The library holds very different kinds of things: people, recordings, written work, scores, and ideas such as genres. I built the inventory from the brief and my own modelling: each kind of entry, the details it carries and the other entries it points to. That inventory became the entity model.
Where names get difficult
Several problems in the content are about words. The same music can have several names, and the same word can mean different kinds of thing.
People
How people think about finding music
Visitors arrive with different ideas of what finding something means. I mapped 4 mental models, drawing on desk research, the Josplay brief, my own knowledge, and conversations with students and 1 musicologist. Then I wrote them into user stories that the flows and screens could be checked against.
User story 1
As a busy undergraduate studying music, I want access to a library of African music resources, so I can easily complete assignments, projects and personal learning.
Mapped as the research journey below.
User story 2
As someone exploring an African music genre, I want to understand its history and style and see the artists and instruments linked to it, so I can follow the connections that interest me.
Written from the scenario “use the AML search feature”.
Structure
An entity model first, then the sitemap
I modelled the library as entries and the links between them. The sitemap came from that model: the main kinds of entry got a place in the menu, and every link became a way to move from one page to the next.
Read the model as a list
- Genre → place of origin, related genres, instruments, artists
- Artist → instruments, albums and singles, labels, associated artists
- Album → songs, with writers and producers
- Instrument → artists known for it, country
- Label → current and former artists, releases
- Musical score → composer, recordings
- Publication → author, publisher, citation
2 ways in
The home page offers search for people who know what they want, and a menu for people who want to browse. The menu groups the entities under AML Resources and the writing under Research, with separate branches for pricing, the API, the team and sign-up.
The sitemap on my FigJam board. Select it to see it in full.
Journeys
2 journeys, and where access decisions sit
I walked each user story through the sitemap as a task flow. The student starts from the Research menu and narrows a search. The genre explorer starts from the search bar and follows links from highlife to its instruments.
Story 2, the genre journey
Access, recovery and membership
My research pointed to paid membership, so both flows had to show where an account or a subscription comes in, and what happens when something goes wrong.
Search is always openMy research pointed to paid membership. In that flow people could search and browse first, and the account and subscription check came when someone opened a result.
Sign-up with verificationA new visitor fills in a short form and verifies by phone or email.
Recovery without a dead endA forgotten PIN leads to a reset by email, with a way to resend it.
Subscription returns you to your resultChoosing a plan and paying leads back into the research the visitor started. Leaving is mapped too.
A visitor who is not a member can preview the item and join with an email address.
Screens
Low-fidelity screens to test the structure on a page
I drew low-fidelity screens at desktop and mobile widths to see whether the model held up once it had to fit a layout. Search results, with filters and sorting, show how different kinds of entry sit together. The creator, genre and academic paper pages carry the links between them.
Search results mix every kind of entry. Filters narrow by kind, subject, access, author, language and year.
A genre page links to its instruments and artists.
Creators filter by role, country, genre, language and year, and can be sorted.
Mobile search results
close-ups
The genre fact box carries the model: other names, origins, and genres that grew from it.
Filters by kind of source: book chapters, journals, reports, albums, songs.
Suggestions say what kind of entry each match is.
Testing
Testing the structure with 7 people
I tested the structure with 7 people: 1 music student, 4 listeners who explore African music and 2 developers. The testing checked the 2 things the structure depends on: people finding an entry by the name they know, and people following links once they arrive.
Research questions
Participants
Tasks
Discussion guide
Synthesis
What the sessions pointed to
Search was the first route to a genreMost people typed the name they knew. The menu mattered more for people who were browsing.
Menu labels needed to name what they held“AML Resources” was not read as artists, genres and instruments by everyone.
Links from a genre page needed to be easy to seeInstruments were found quickly. The artist list further down was easier to miss.
Nobody expected to sign in before searchingResearchers expected to pay, if at all, for downloads or full articles. That matched where the flows placed the account check.
Handover
From structure to UI design
I handed the sitemap, flows and low-fidelity screens to Ibkay, who designed the web UI and made the prototype from this research. I supported some of the responsive mobile UI.
Genre list, web UI by Ibkay
Details page for a visitor who is not a member, web UI by Ibkay
Next case study
Afriex
3 years turning a cross-border transfer app into a product system
Making African music easier to explore
Josplay was building the African Music Library, a knowledge base of African music. My part was the user research and information architecture: who comes to the library, what it holds, and the paths people take through it. Ibkay designed the web UI from that research, and I supported some of the responsive mobile UI.
Over 3 months my work covered a review of comparable libraries, mental models and user stories, an entity model, a sitemap, task flows, low-fidelity screens and testing with 7 people. This page walks through that work.
User research and information architecture3 monthsWeb and mobile web
Client: Josplay. Web UI: Ibkay. I supported some of the responsive mobile UI.
The brief
What the library needed to answer
Josplay wanted a library of African music: artists, recordings, genres, instruments, and writing and scholarship about the music. I did not have access to their data, so I worked out from the brief and my own research what the library needed to hold and how one entry relates to another. Before drawing anything, I wrote down the questions the structure had to answer.
Tap to enlarge
Other libraries
How other music libraries connect what they hold
During the project I looked at how established music databases and archives organise their collections, and how they get a visitor from one entry to the next. Each observation comes with what it meant for AML.
Tap to enlarge
The content
What the library holds, and where names get difficult
The library holds very different kinds of things: people, recordings, written work, scores, and ideas such as genres. I built the inventory from the brief and my own modelling: each kind of entry, the details it carries and the other entries it points to. That inventory became the entity model.
Tap to enlarge
Where names get difficult
Several problems in the content are about words. The same music can have several names, and the same word can mean different kinds of thing.
Tap to enlarge
People
How people think about finding music
Visitors arrive with different ideas of what finding something means. I mapped 4 mental models, drawing on desk research, the Josplay brief, my own knowledge, and conversations with students and 1 musicologist. Then I wrote them into user stories that the flows and screens could be checked against.
Tap to enlarge
User story 1
As a busy undergraduate studying music, I want access to a library of African music resources, so I can easily complete assignments, projects and personal learning.
Mapped as the research journey below.
User story 2
As someone exploring an African music genre, I want to understand its history and style and see the artists and instruments linked to it, so I can follow the connections that interest me.
Written from the scenario “use the AML search feature”.
Structure
An entity model first, then the sitemap
I modelled the library as entries and the links between them. The sitemap came from that model: the main kinds of entry got a place in the menu, and every link became a way to move from one page to the next.
Tap to enlarge
Read the model as a list
- Genre → place of origin, related genres, instruments, artists
- Artist → instruments, albums and singles, labels, associated artists
- Album → songs, with writers and producers
- Instrument → artists known for it, country
- Label → current and former artists, releases
- Musical score → composer, recordings
- Publication → author, publisher, citation
2 ways in
The home page offers search for people who know what they want, and a menu for people who want to browse. The menu groups the entities under AML Resources and the writing under Research, with separate branches for pricing, the API, the team and sign-up.
Tap to enlarge
The sitemap on my FigJam board. Select it to see it in full.
Journeys
2 journeys, and where access decisions sit
I walked each user story through the sitemap as a task flow. The student starts from the Research menu and narrows a search. The genre explorer starts from the search bar and follows links from highlife to its instruments.
Tap to enlarge
Story 1, the research journey
Tap to enlarge
Story 2, the genre journey
Access, recovery and membership
My research pointed to paid membership, so both flows had to show where an account or a subscription comes in, and what happens when something goes wrong.
Search is always openMy research pointed to paid membership. In that flow people could search and browse first, and the account and subscription check came when someone opened a result.
Sign-up with verificationA new visitor fills in a short form and verifies by phone or email.
Recovery without a dead endA forgotten PIN leads to a reset by email, with a way to resend it.
Subscription returns you to your resultChoosing a plan and paying leads back into the research the visitor started. Leaving is mapped too.
A visitor who is not a member can preview the item and join with an email address.
Screens
Low-fidelity screens to test the structure on a page
I drew low-fidelity screens at desktop and mobile widths to see whether the model held up once it had to fit a layout. Search results, with filters and sorting, show how different kinds of entry sit together. The creator, genre and academic paper pages carry the links between them.
Search results mix every kind of entry. Filters narrow by kind, subject, access, author, language and year.
A genre page links to its instruments and artists.
Mobile search results
Creators filter by role, country, genre, language and year, and can be sorted.
close-ups
The genre fact box carries the model: other names, origins, and genres that grew from it.
Filters by kind of source: book chapters, journals, reports, albums, songs.
Suggestions say what kind of entry each match is.
Testing
Testing the structure with 7 people
I tested the structure with 7 people: 1 music student, 4 listeners who explore African music and 2 developers. The testing checked the 2 things the structure depends on: people finding an entry by the name they know, and people following links once they arrive.
Tap to enlarge
Research questions
Tap to enlarge
Participants
Tap to enlarge
Tasks
Tap to enlarge
Discussion guide
Tap to enlarge
Synthesis
What the sessions pointed to
Search was the first route to a genreMost people typed the name they knew. The menu mattered more for people who were browsing.
Menu labels needed to name what they held“AML Resources” was not read as artists, genres and instruments by everyone.
Links from a genre page needed to be easy to seeInstruments were found quickly. The artist list further down was easier to miss.
Nobody expected to sign in before searchingResearchers expected to pay, if at all, for downloads or full articles. That matched where the flows placed the account check.
Handover
From structure to UI design
I handed the sitemap, flows and low-fidelity screens to Ibkay, who designed the web UI and made the prototype from this research. I supported some of the responsive mobile UI.
Genre list, web UI by Ibkay
Details page for a visitor who is not a member, web UI by Ibkay
Next case study
Afriex
3 years turning a cross-border transfer app into a product system
Making African music easier to explore
Josplay was building the African Music Library, a knowledge base of African music. My part was the user research and information architecture: who comes to the library, what it holds, and the paths people take through it. Ibkay designed the web UI from that research, and I supported some of the responsive mobile UI.
Over 3 months my work covered a review of comparable libraries, mental models and user stories, an entity model, a sitemap, task flows, low-fidelity screens and testing with 7 people. This page walks through that work.
User research and information architecture3 monthsWeb and mobile web
Client: Josplay. Web UI: Ibkay. I supported some of the responsive mobile UI.
The brief
What the library needed to answer
Josplay wanted a library of African music: artists, recordings, genres, instruments, and writing and scholarship about the music. I did not have access to their data, so I worked out from the brief and my own research what the library needed to hold and how one entry relates to another. Before drawing anything, I wrote down the questions the structure had to answer.
Other libraries
How other music libraries connect what they hold
During the project I looked at how established music databases and archives organise their collections, and how they get a visitor from one entry to the next. Each observation comes with what it meant for AML.
The content
What the library holds, and where names get difficult
The library holds very different kinds of things: people, recordings, written work, scores, and ideas such as genres. I built the inventory from the brief and my own modelling: each kind of entry, the details it carries and the other entries it points to. That inventory became the entity model.
Where names get difficult
Several problems in the content are about words. The same music can have several names, and the same word can mean different kinds of thing.
People
How people think about finding music
Visitors arrive with different ideas of what finding something means. I mapped 4 mental models, drawing on desk research, the Josplay brief, my own knowledge, and conversations with students and 1 musicologist. Then I wrote them into user stories that the flows and screens could be checked against.
User story 1
As a busy undergraduate studying music, I want access to a library of African music resources, so I can easily complete assignments, projects and personal learning.
Mapped as the research journey below.
User story 2
As someone exploring an African music genre, I want to understand its history and style and see the artists and instruments linked to it, so I can follow the connections that interest me.
Written from the scenario “use the AML search feature”.
Structure
An entity model first, then the sitemap
I modelled the library as entries and the links between them. The sitemap came from that model: the main kinds of entry got a place in the menu, and every link became a way to move from one page to the next.
Read the model as a list
- Genre → place of origin, related genres, instruments, artists
- Artist → instruments, albums and singles, labels, associated artists
- Album → songs, with writers and producers
- Instrument → artists known for it, country
- Label → current and former artists, releases
- Musical score → composer, recordings
- Publication → author, publisher, citation
2 ways in
The home page offers search for people who know what they want, and a menu for people who want to browse. The menu groups the entities under AML Resources and the writing under Research, with separate branches for pricing, the API, the team and sign-up.
The sitemap on my FigJam board. Select it to see it in full.
Journeys
2 journeys, and where access decisions sit
I walked each user story through the sitemap as a task flow. The student starts from the Research menu and narrows a search. The genre explorer starts from the search bar and follows links from highlife to its instruments.
Story 1, the research journey
Story 2, the genre journey
Access, recovery and membership
My research pointed to paid membership, so both flows had to show where an account or a subscription comes in, and what happens when something goes wrong.
Search is always openMy research pointed to paid membership. In that flow people could search and browse first, and the account and subscription check came when someone opened a result.
Sign-up with verificationA new visitor fills in a short form and verifies by phone or email.
Recovery without a dead endA forgotten PIN leads to a reset by email, with a way to resend it.
Subscription returns you to your resultChoosing a plan and paying leads back into the research the visitor started. Leaving is mapped too.
A visitor who is not a member can preview the item and join with an email address.
Screens
Low-fidelity screens to test the structure on a page
I drew low-fidelity screens at desktop and mobile widths to see whether the model held up once it had to fit a layout. Search results, with filters and sorting, show how different kinds of entry sit together. The creator, genre and academic paper pages carry the links between them.
Search results mix every kind of entry. Filters narrow by kind, subject, access, author, language and year.
A genre page links to its instruments and artists.
Creators filter by role, country, genre, language and year, and can be sorted.
Mobile search results
close-ups
The genre fact box carries the model: other names, origins, and genres that grew from it.
Filters by kind of source: book chapters, journals, reports, albums, songs.
Suggestions say what kind of entry each match is.
Testing
Testing the structure with 7 people
I tested the structure with 7 people: 1 music student, 4 listeners who explore African music and 2 developers. The testing checked the 2 things the structure depends on: people finding an entry by the name they know, and people following links once they arrive.
Research questions
Participants
Tasks
Discussion guide
Synthesis
What the sessions pointed to
Search was the first route to a genreMost people typed the name they knew. The menu mattered more for people who were browsing.
Menu labels needed to name what they held“AML Resources” was not read as artists, genres and instruments by everyone.
Links from a genre page needed to be easy to seeInstruments were found quickly. The artist list further down was easier to miss.
Nobody expected to sign in before searchingResearchers expected to pay, if at all, for downloads or full articles. That matched where the flows placed the account check.
Handover
From structure to UI design
I handed the sitemap, flows and low-fidelity screens to Ibkay, who designed the web UI and made the prototype from this research. I supported some of the responsive mobile UI.
Genre list, web UI by Ibkay
Details page for a visitor who is not a member, web UI by Ibkay
Next case study
Afriex
3 years turning a cross-border transfer app into a product system