CASE STUDY

Muse · Icon system · Governance

Unified Icon System across Muse products

I consolidated 1,136 fragmented icons across five libraries into one shared icon system used by seven Muse products.

RoleDesign System & Icon DesignerScopeSeven products · Web + AppOutcomeFive libraries → one source
CONTEXT

Overview

How I consolidated 1,136 fragmented icons across five libraries into one shared icon system used by seven Muse products.

1,136 existing assets · 5 libraries · 260 icons in the current shared library · 7 products

My role: Icon system designer and owner. I led the inventory, developed the visual direction, redrew the core set, formalised the construction rules and continue to own new icon requests.

OVERVIEW

01 — The fragmentation problem

The old icon ecosystem had no single visual language or source of truth. Filled and outlined icons were mixed inside products, sizing and scaling rules differed, visual quality depended on the author, and one product maintained three separate icon libraries for different platforms or bundles.

The same metaphor could therefore exist several times and require several independent maintenance paths.

The problem was not just inconsistency — the same work was being repeated across products.

Fragmented icon libraries across Muse products
CHALLENGE

02 — 1,136 assets became ~200–250 unique metaphors

I manually collected the existing icons, compared the libraries and grouped them by shared metaphor.

The inventory reduced 1,136 assets to roughly 200–250 unique metaphors that actually needed to be solved. It became both the production plan and a clear measure of duplicated maintenance in the old model.

The shared library has since grown to 260 icons as new product needs were added.

1,136 assets · 5 libraries → ~200–250 unique metaphors → 260 icons in one shared library

STRATEGY

03 — Finding a visual language that worked for both brand and UI

During the Muse rebrand, an external branding agency explored several icon directions. The concepts had strong brand expression, but they were too detailed for real interface sizes: when reduced, details collapsed and the symbols lost clarity.

I proposed an alternative direction built specifically for UI use.

Muse uses two very different typefaces: Muse Display, an expressive accent face, and Muse Sans, a practical interface grotesk. A conventional outline style worked with Muse Sans but did little to connect the interface with Muse Display.

I explored the characteristic shapes of both typefaces and developed a predominantly filled, simplified icon language with a contrast between sharp angles and rounded forms.

I refined the direction with the Brand Director, then continued the remaining work independently once the system was established.

Project diagram
ARCHITECTURE

04 — Turning the direction into a system

Before scaling production, we tested the new icons on key screens of two core products and adjusted the style in real interface context.

Project diagram

I then redrew the complete core set and formalised the rules needed to keep future icons consistent.

The system uses a 20×20 px base grid with a 16 px safe area. The main working size is 20 px, with 16 px as the recommended minimum and 24 px for larger standard UI use.

Icon anatomy: size variants, grid, optical compensation, construction shapes, crossed-out states, and arrow geometry

Construction guidance covers simplification, optical compensation, centering, line weight, corner treatment, crossed-out states, repeated arrow geometry and form joints. Usage rules also define semantic distinctions such as chevron for navigation and caret for local expand/collapse or dropdown behaviour.

Principle: reduce the form as far as possible without losing the metaphor. Brand character is added only when it does not make the symbol worse.

Project diagram
DECISION

05 — One predictable source for design and development

The final library replaced fragmented local sets across the Muse design ecosystem.

Icons are organised into functional groups and include synonym tags in their descriptions, so designers can find an existing metaphor even when they search using a different term.

Developers built a parser to consume the published assets from the same source.

New icons follow a controlled flow:

Request → context → metaphor research → design & review → naming/tags → publish

This keeps the system consistent without making the maintainer a bottleneck. In everyday work, designers usually know where to search and can reuse existing icons without assistance.

Project diagram
EXECUTION

06 — Proof it scaled

The first consumers were MuseScore, Ultimate Guitar and Audio.com. MuseScore used the system across two platforms, while Ultimate Guitar used it across Web, Mobile Web and App.

Later, Sheet Music Plus, Muse Hub, Hal Leonard and EEMC joined the same library, bringing adoption to seven products.

New products no longer need to create another icon language or another local asset library. They connect to the existing source and reuse the same metaphors, rules and assets.

What became simpler: one source to maintain, one place to search, one controlled visual language, and one new icon design that can become available across the ecosystem.

Project diagram
GOVERNANCE

Outcome

1 shared system replaced five fragmented icon libraries.

260 icons now live in the maintained shared library.

7 products use the same source across the Muse design ecosystem.

My contribution: inventory, visual direction, complete core-set redraw, system rules, taxonomy and ongoing governance.

Desktop music-editor applications remain outside this system because their teams, technology and dense interface requirements follow a separate design ecosystem.

NEXT CASE

Muse · Color system · Design tokens

Semantic Color Architecture across Muse products