Project

Melo

Exploring Sound as a Design System

Manage, edit & distribute your sound experience - Melo is a platform that allows you to create and share your sound experiences.

Type

Case-Study

Role

UI/UX Design & Frontend Prototypes

Year

2021

What This Is (and What It Isn’t)

Melo is an exploratory case study.
It is not a shipped product, but a structured investigation into how sound could be treated as a first-class design concern rather than an implementation detail.

The work sits at the intersection of interaction design, system thinking, and tooling design. The goal was to explore concepts, not to validate a market or build production software.

Motivation

Sound plays a critical role in how digital interfaces feel — feedback, confirmation, error states, and ambience all rely on it. Yet in most products, sound decisions are made late, are hardcoded, or live entirely in engineers’ heads.

What interested me was not “how to add sound”, but:

how sound decisions are communicated
how intent gets lost between design and implementation
and why sound is rarely designed with the same rigor as visual systems

This case study asks a simple question:

What if sound was designed like a system, not like an asset?

Framing the Problem

In most teams:

designers talk about sound abstractly (“subtle”, “playful”, “serious”)
engineers need concrete parameters and constraints
product teams want consistency and predictability

There is no shared interface or model that connects these perspectives. Sound becomes either:

overly flexible and chaotic
or overly rigid and underutilized

The core tension explored here is:

How can sound be expressive without becoming unmanageable?

Exploration & Approach

Treating Sound as Behavior

Instead of thinking in terms of audio files, sound is reframed as behavior tied to events and states:

confirmations
transitions
errors
background states
attention cues

This shift makes it possible to think about sound in the same way we think about interaction patterns.

Designing for Intent, Not Parameters

Rather than exposing raw technical controls, the exploration focuses on:

intent-driven configuration
constrained choices over infinite flexibility
sensible defaults that communicate meaning

The interface concepts deliberately avoid traditional “audio tooling” metaphors and instead borrow from familiar UI system patterns.

Personas as Constraints

Lightweight personas were used not to simulate users, but to create design constraints:

someone who cares about experience but not audio engineering
someone who needs predictable, testable behavior
someone responsible for consistency across surfaces

Each concept was evaluated through these lenses.

Outcomes

The result of this exploration is a set of interaction concepts that:

demonstrate how sound could be configured alongside UI
surface trade-offs between flexibility and control
create a shared language between design and engineering
make sound decisions inspectable rather than implicit

The value of the work lies in:

the framing of the problem
the abstractions explored
and the design patterns proposed

—not in feature completeness or production readiness.

Reflections

Two insights stood out during this work:

Invisible systems need the strongest abstractions
The less visible an interaction is, the more intentional its design must be.
Constraints are a UX feature
Removing options often increases clarity, trust, and consistency — especially in system-level design.

This way of thinking later informed my work on agent UX and change tracking, where the same pattern repeats: users don’t just need power, they need legibility.

Technical Architecture (Schematic)

schematic
1
2
3
4
5
6
7
8
9
10
11
12
[Custom Frontend]
    | user interactions (click / hover / scroll)
    v
[npm sound-behavior library]
    | maps UI events to sound behaviors
    | pulls intent + config from API
    v
[Next.js app — sound store & orchestration]
    | manages presets, assets, rules, telemetry
    | exposes routes for config + playback instructions
    v
[Sound assets + behavior graph]

melo studio

melo dashboard

Why This Case Study Still Matters

Melo represents how I approach ambiguous problems:

start with framing, not solutions
design systems before interfaces
and use constraints as a design tool

Even though this was not a product, the thinking behind it directly applies to complex, real-world systems — especially those involving automation, AI, or collaboration.