Gramo

Process

Gramo uses an internal tool called Echo to manage data and distribute royalties. I was tasked with improving the efficiency of its data administration process.

I started by interviewing Echo administrators to understand their roles and daily tasks. It became clear that most of their time was spent in the “Unidentifiable Tracks” section—where tracks that had aired on radio but couldn’t be matched in Gramo’s database were stored.

These tracks were often unidentifiable due to issues like:

• Obscure or rare songs

• Spelling variations

• Misattributed artists

• Translated titles

• Incorrect ISRC codes

• Newly released tracks not yet in the database

To dive deeper, I shadowed users as they worked. I observed a highly repetitive, manual process that consumed significant time and led to user frustration.

Users had to manually check each unidentifiable track to see if it already existed in Echo’s database. If it did, they could simply link it to the unidentified track, allowing the system to distribute royalties.

If the track wasn’t in the database, the process became much more complex. Admins manually gathered details—such as artist name, track length, release date, ISRC, and label info—by cross-referencing platforms like Spotify, Discogs, and VRDB. They then entered this data into Echo manually.

Though tedious, the goal was to ensure royalties went to the correct recipients.

Echo’s interface made this even harder. Simple tasks like adding a release title, performer, or additional tracks required navigating through multiple pages. While manageable for occasional use, these were daily tasks for admins. The inefficient navigation slowed them down and caused frustration—making this a key focus of my redesign efforts.

Research Process

Example work flows that I observed during my shadowing: I began by understanding the overview of their process.

I then mapped out a more detailed view of the flow. These were important to understand correctly so that the team I could use it as a foundation for the project.

Identified frustrations

From my discovery here were the main patterns I found:

• There are too many steps to do simple tasks, such as adding supporting artists to a track.

• Simple tasks often require jumping to different sections of the app, even though they are all related.

• Lots of copying/pasting of the same information to different parts of the app.

• Although a variety of sources are used to verify a track, Spotify is used as a main source of truth for track/album information.

My goal was to see how these frustration could be eased for the user.

Improvement: Re-organize Unidentified Tracks

Previously, admins had to verify the same track multiple times if it played on different radio stations. For example, “Western Broncos” by Hermanos Gutiérrez had to be verified separately for each station—creating redundant work.

This happened because the system treated each station as the parent and the track as a child.

The new system flipped this relationship: the track became the parent, and the stations its children. Now, once a track is verified, the update applies across all stations that played it—eliminating repetitive verification tasks.

Improvement: Use Spotify API to import most data

Although Echo admins used multiple sources to verify track data, they relied heavily on Spotify. When a song was available there, they often copied and pasted details manually into Echo. While Echo already automatically imported some data—like artist, title, and duration—I found, through the Spotify API documentation, that much more could be automated.

Already automatically imported:

• ✅ ISRC

• ✅ Main artist

• ✅ Track Title

• ✅ Duration

Additional info that can be imported:

• Label

• P-line

• Country of release

• Date of release

Along with track information, release (album) information could also be imported from Spotify.

• Release title

• Tracks on release + relevant information mentioned above

• Genre

• C-line

The most important piece of data is the ISRC - a unique identifying number for each track. With ISRC, information can be either directly imported or deduced.

✅ Indicates information that was automatically imported previously

⭐️ Indicates information that is automatically imported with update

🛑 Indicates information that must always be manually entered because API is not available

Below is a tree I created showing relationship of data to ISRC.

By directly importing data from Spotify API as well as automatically looking up and importing related data, 11 additional data points can be automatically filled for the user.

I worked with devs to make sure that not only could the API be used, but that we could use it without upsetting Spotify’s terms and condition since we would have to ping their servers multiple times a the day, five days a week. Luckily our usage of their API did not break their Ts&Cs and we could successfully implement this.

Improvement: General UI/UX clean up

The UI was contributing to inefficiency. For example, users would have to hunt for the ISRC field. Even though it was the first form field they always filled, it was the 5th field down. Misaligned fields and inconsistent component sizes further hurt usability. The inconsistent and unpredictable layout impacted the overall user experience, so a general UI cleanup was necessary.

Old Designs

Examples of low fidelity and flow designs (click to enlarge)

Designs were continually presented and discussed with the devs, PM, and clients throughout the process.

Testing Table Designs

Tables became a focal point of my design since that’s how users compared and scanned data for Unidentified Tracks. I wanted to design something that reduced cognitive load/eye strain and yet make it very obvious at a glance if data was correct or incorrect.

After some testing with Echo admin, the design below was the winner. By only scanning the first column, it’s obvious at a glance what is correct or not. This type of missing data is typical.

Extra: Updating the font

Though not originally a priority, I saw an opportunity to improve readability by changing the font. Echo used “Circular XX,” which—with its rounded shapes—wasn’t ideal for scanning and entering data.

I tested the “Inter” font, which offers features like tabular numbers, case alternates, and clearer distinctions between similar characters—helpful for reading serial numbers, codes, payouts, and names.

In an A/B test with everything else unchanged, admins clearly preferred Inter. It improved readability, reduced eye strain, and made data tasks faster and more accurate.

Samples of Final designs

My research unveiled areas for automation and streamlined processes to improve workflow, user experience, and accuracy. I worked closely with the dev team to ensure my solutions and designs were feasible and fit within the team’s and client’s budget. My designs have decreased the time it takes to identify a song and update its records by up to 23%. Below are samples of the final design work I’ve done.

Below is the main screen for “Unidentified Tracks”. On the left panel, you have a list of Unidentified Tracks. With the right panel showing details of the track that is selected.

The overall layout of the application remained largely unchanged, as users appreciated the ability to view unidentified tracks like a ticketing system. This allowed them to search related data in the left panel while keeping the active track visible on the right.

For example, while working on the track “Highway Tune,” users could keep its details open on the right panel and simultaneously search for related tracks, artist names, or labels on the left—a common first step in verifying information.

The left panel displayed key details such as track title, artist, label, play duration, play count, and ISRC. Now that tracks are the parent, radio stations appear as tags (e.g., NRK, P4, Lokal).

However, I removed the persistent underlines from clickable items in the old design. While underlines suggested interactivity, having them on every item added visual clutter and cognitive load. In the updated design, underlines now appear only on hover. Initially, users were unsure if items were still clickable, but quickly adapted once they saw the underline reappear on hover—preserving functionality while improving readability.

New Format

Old Format

During observation, I noticed admins frequently copied ISRCs, catalog numbers, and nrkIDs to cross-reference with external sources—an essential part of their workflow that couldn’t be automated or removed. To save time, I added a hover-triggered copy button, eliminating the need to highlight text manually.

When adding a new track, users can now search by ISRC and import suggested data from Spotify. Previously, this had to be entered manually. Key details—album cover, title, ISRC, artist, track name, and duration—are now clearly displayed in a horizontal layout based on user preference for easy comparison.

Once a source is selected, all relevant data is automatically imported.

In the left panel, blue squares indicate the number of data variations for each field. For example, "duration" shows 2 results if one source lists the track as 8:34 and another as 8:35. Users can click the squares to choose preferred values from different sources.

Once a track is added, all tracks from the same album are automatically imported. Research showed users preferred this, as related tracks are often played together on the radio. Preloading them into their database helps with future identification.

Editing performers (utøvere), ownership (eierskap), remuneration (vederlag), and claim numbers is now consolidated on one screen to reduce navigation.

A key time-saver was improving role code handling under the performer section. Two fields—Rollekode and Rolle—contain the same info from different sources, but use different formats (e.g., "A" vs. "MS/NF"). Previously, users had to manually match these formats. The new design automatically translates them in the backend, reducing user error and improving efficiency.

Conclusion

This was a great project where I got the opportunity to learn a complex process of paying royalties to performers and artists. I learned the “why” behind certain things from dev perspectives and user perspectives. Such as why role codes are so convoluted, when I thought it would be simple to consolidate them, or that changing the parent/child relationship between track and radio is a simple task, when I thought it would be hard.

It was a joy to see things go from initial research, brainstorming, collaboration with different teams, designs, testing, to launch. I look forward to receiving more feedback on my designs to so that I can evolve designs and features to help users do their jobs more accurately and efficiently.