Gramo

Redesigning the Echo Admin Tool

Role: Lead UX Designer

When I joined Gramo, I was asked to redesign Echo, the internal tool used to identify music played in public venues and distribute royalties fairly to rights holders, artists, and record labels.

At first glance, Echo seemed functional. But once I shadowed administrators — the people who spent their entire workday inside the tool — I saw the cracks.

Simple tasks like identifying a track took far too many steps. Admins bounced between Echo, Spotify, Discogs, and other external databases just to cross-check information such as: 

• Spelling variations

• Misattributed artists

• Translated titles

• Incorrect ISRC codes

• Newly released tracks not yet in the database

• Obscure or rare songs

Worse, if a track appeared on multiple radio stations, they had to verify it multiple times, repeating the same work over and over. The interface itself didn’t help: important fields were buried, layouts were inconsistent, and dense tables slowed down scanning.

The system worked — but not for the people behind it.

My Process

1. Observing and Listening

I started by sitting with administrators during their daily routines. I mapped their workflows, listened to their frustrations, and documented every workaround they had developed to cope with Echo’s inefficiencies.

From this, I surfaced the core friction points:

• Redundant verification steps.

• Excessive manual data entry.

• UI layouts that buried important fields.

• Visual clutter that made scanning slow and tiring.

Samples of some notes from work flows that I observed

2. Defining the Core Problems Through Jobs to Be Done

To make sense of what I observed, I reframed the admins’ pain points as Jobs to Be Done (JTBD) — what they were really trying to accomplish, beyond just “using the tool.”

Jobs to Be Done

When I receive a list of unidentified tracks,
I want to quickly verify them against trusted sources,
so I can finish my work without spending hours jumping between tools.
Before: Admins copied details into Echo from Spotify, Discogs, and VRDB manually.

When I identify a track once,
I want that information to apply across all radio stations,
so I don’t waste time doing the same work multiple times for multiple radio stations.

Before: Echo treated each station separately, forcing duplicate verification.

When I’m entering or reviewing track metadata,
I want the most important fields (like ISRC) to be easy to find,
so I can avoid errors and work faster.

Before: ISRC was buried in the layout, requiring constant scrolling.

When I need track details like label, release date, or P-line,
I want them imported automatically,
so I don’t have to gather them from multiple sources.
Before: Admins did repetitive copy-paste tasks across several databases.

These statements became the north star for my design decisions.

3. Designing Smarter Workflows

Armed with the JTBD, I set out to redesign Echo so that it supported — instead of hindered — the admins’ goals.

Restructuring the data model

I changed the relationship between tracks and radio stations. Tracks became the parent entity, with stations as child tags. This meant that once a track was identified, that verification applied everywhere — no more duplicate work.

Automating data imports

I expanded Echo’s integration with the Spotify API. Instead of pulling only artist, title and duration from ISRC, Echo now imported label, release date, genre, country, and P-line/C-line automatically. Manual copy-paste of these information became the exception rather than the rule.

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

✅ 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

Cleaning up the interface

I reorganized form layouts so the most critical fields (like ISRC) appeared first, aligned components for consistency, and reduced clutter by only showing underlines on hover.

Improving readability and legibility through typography

The existing system used Circular XX.

• Designer & Foundry: Created by Swiss designer Laurenz Brunner and released by the Lineto foundry in 2013.

• Style: It's a geometric sans-serif, meaning its letterforms are based on simple geometric shapes like circles and rectangles.

• Characteristics: It's known for its clean, minimal, and warm aesthetic. A key and very recognizable feature is the lowercase "t," which has a distinctive, rounded base. It's often used for branding, particularly for technology companies and modern, design-focused brands like Spotify.

• Availability: It is a commercial font, meaning you need to purchase a license to use it.

For users engaged in extensive data comparison and analysis, the choice of font is critical for legibility and efficiency. I did not see Circular XX as the correct font choice. Thus, I tested typography specifically for long alphanumeric codes and data. I chose and switched to Inter.

Reasons for the switch in typography:

4. Testing and Iterating

I prototyped new workflows and tested them with admins.

Table redesigns

I presented multiple layouts and measured which one allowed faster scanning and error detection.

The winning design

Main verification page redesigns: I presented multiple layouts and measured which one allowed faster scanning and error detection.

Micro-interactions: Small changes like hover-to-copy buttons for ISRC codes removed tedious steps and boosted confidence.

The Results

• Verify once, apply everywhere: Tracks were now the parent entity, eliminating redundant work across stations.

• Automated metadata import: Spotify API integration drastically reduced manual entry.

• Prioritized layouts for speed: ISRC and other key fields surfaced first for quicker access.

• Fast, confident workflows: Cleaner tables, improved hierarchy, and better typography reduced scanning time.

• One-click efficiency: Hover-to-copy buttons cut small but constant interruptions.

🔁 100% less duplicate work for verifying the same track — restructuring tracks as parent entities eliminated repetitive verification across stations.

🤖100% auto-fill of metadata for 11 data points.

🤖100% reduction in time to copy paste these 11 data points from around 60-70 seconds to 0 seconds.

🤖 100% automated role code translation (e.g., “A” → “MS/NF”), saving ~6 seconds per track by removing the need to manually match the two fields (Rollekode and Rolle).

✅ 100% fewer errors thanks to automation of meta data import and role code translation.

👀 4 out of 5 of admins preferred Inter font — A/B testing showed improved readability.

💪 5 out of 5 admins reported higher confidence in their work after the redesign.

📈 About 6 hours saved per admin per week — cumulative time savings from automation and reduced duplication.

🎶 15% more tracks processed weekly — from around an average of 500 tracks per week per admin to 575 tracks.

Reflection

This project reinforced a principle I carry into every design: internal tools deserve as much care as user-facing products.

By reframing pain points into Jobs to Be Done, I was able to align the redesign with what users actually needed to accomplish. Pairing that with close collaboration, technical improvements, and iterative testing, I turned Echo from a source of frustration into a tool that empowered its admins. I ultimately made royalty distribution faster and fairer for the artists who depend on it.

Samples of Final designs

The main screen for “Unidentified Tracks” features two panels: a list of unidentified tracks on the left, and detailed information about the selected track on the right.

The overall layout remained largely unchanged, as users valued the ticketing-style workflow. This setup allowed them to browse related data on the left while keeping the active track open on the right.

For example, when working on the track “Highway Tune,” users could keep its details visible in the right panel while simultaneously searching for related tracks, artist names, or labels in the left panel—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. Since tracks are now the parent, radio stations appear as tags (e.g., NRK, P4, Lokal).

One visual change was the removal of persistent underlines on clickable items. While underlines did signal interactivity, having them on every item created unnecessary visual noise. In the updated design, underlines appear only on hover. Although users were briefly unsure if items remained clickable, they quickly adapted once they saw the underline reappear on hover—maintaining functionality while improving readability.

New Format

Old Format

During observation sessions, I noticed that admins frequently copied ISRCs, catalog numbers, and nrkIDs to cross-reference with external sources—an essential but unautomatable step. To streamline this process, I added a hover-triggered copy button, removing the need to highlight text manually.

When adding a new track, users can now search by ISRC and import suggested data from Spotify. Previously, all details had to be entered manually. Key information—album cover, title, ISRC, artist, track name, and duration—are now displayed in a horizontal layout, reflecting user preference for easier 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.