JAAK's vision & Defining the user requirements

JAAK is utilising blockchain technology to build shared infrastructure to allow the music and media industries to collaborate on a global view of content ownership and rights, aiming to simplify content licensing on the web.

First step was to conduct a series of user interviews to better understand our users needs and pain points and to better define our product roadmap.

After defining a user script and conducting user interviews, we started noticing some patterns around what type of features the users were requesting as well as what they found difficult in the current process of licensing music. This gave us a better foundation to shape the user requirements of our features as well as the information architecture.

The type of content surfaced

From conducting the user interviews, we noticed users were interested in the most popular content that was added in other applications as well. The content could be sorted by collections (curated playlists), artists or genres. Most popular content would be defined by the number of purchases from other applications, sorted in descending order.

For every type of content, user requirements had to be defined for what type of functionalities an individual page would have. Can content be added to the application? Can you bulk add content? Can you add individual items?

Artist page

Thought had to be put in what type of functionalities the artists page would have. While you could bulk add all the content from an artist from the main page by hovering over the component, you could also have the same functionality by going to the individual artist page. A grid view / list view functionality was also added for easier accesibility to smaller components (i.e tracks in this case).

List view

By adding a list view functionality, users could easily add individual tracks to their application. Iterations between using subpages for every type of content vs displaying content in tabs/views were made. After conducting qualitative research, we decided to keep the usage of tabs/views as the amount of necessary steps the user would need to complete the journey was less and more seamless.

Genres page

The genres page had to comply to the same patterns used in the other types of content as well, keeping the structure the same.

Adding content to application functionality

One of the main features of the applications is the sidebar. Similar to a shopping cart, the user could add any type of music content available in the platform. User requirements had to be defined for edge cases where added content would overlap with content already added, as well as removing content would intersect with other type of groups added in the sidebar.

Admin section

Another important part of the application is the admin section. Here, users could see important details related to their music application as well as data related to usage and streaming of content. The type of data surfaced inside the admin section was mostly defined through the user interviews.

Tracking devices

One of the requirements was to surface data related to devices that stream from the music application.

Dashboard data

Users were also interested in seeing data related to most popular tracks streamed in their application, a history of events as well as the usage of credits purchased.

User research & user testing

For each developed feature, we did user testing with our initial sample of users who participated in our user interviews as well. Since it was an early stage startup, it was important to have a close relationship to our users, understand their background and motivation as well as their pain points. We mostly conducted qualitative research by testing out with prototypes. After the features were implemented we conducted quantitative research to fine tune the application.

You can find me on linkedin, angellist, twitter and insta or email me at alinacolceag@gmail.com