← Back to home · Background · About
Concept · Functional prototype Product Strategy UX/UI AI-Driven Design

SonLab

An AI co-writer that turns scattered voice memos into organized song ideas you can actually finish — by keeping each spark's context, not just its sound.

Role
Solo — concept, UX, UI, flow, prototype build
Timeframe
3 months · March–May 2026
Context
MA Generative Design & AI, UE Potsdam
Result
Working prototype (simulated AI)
SonLab — idea bubbles in different colours arranged along a song's verse / chorus / bridge / outro structure
I chose bubbles over boxes so ideas read as fluid and unfinished — a box says "done," a bubble says "still forming." Colour signals how developed an idea is.
The 30-second version
Problem
Amateur songwriters capture sparks everywhere — voice notes, memos, scraps — but when they sit down to write, the context is gone. They can't remember how the idea came, or which song it belongs to, so the idea is stranded. It's a capture-and-retrieval problem, not a music-making one.
My role
Solo. Every concept, UX, UI and flow decision is mine. I built the first prototype in Figma Make, then rebuilt it with Claude Code — my limited coding meant I directed the build rather than hand-wrote it.
Key decision
I refused to make SonLab generate songs. I chose organize-and-assist over generate, trading the flashy "wow" demo for a tool that keeps the writer inside their own creative process.
Outcome
A working prototype with simulated AI, plus one validated learning: front-loading context questions created friction, so capture-first beat structure-first. The differentiators — colour-learning bubbles, chatbot, image generation — are designed and simulated, not yet usability-tested.

Context & constraints

A three-month solo concept, built inside two hard limits.

This was a three-month solo project for my MA in Generative Design and AI. It never shipped to real users, and it wasn't meant to — the goal was to prove a concept, not a business.

Two constraints shaped everything. First, I don't code fluently: when Claude Code misread my intent, I often couldn't diagnose the error myself, so I designed around what I could reliably build and simulate. Second — and this is the distinction that matters — the intelligence is faked in the demo, not in the idea. SonLab is conceived to run on a real model: it should learn each idea from the context the writer gives it. In the prototype you can open below, the parts that would need that model — the bubble colours, the chatbot, the cover-art generation — run on presets instead.

I state this because at this stage of my career nothing serves me better than being honest: what the demo shows is the intended behaviour, designed convincingly — not a model I trained.

Strategy

A co-writer, not a generator. That one distinction is the whole product.

I built it from my own frustration: as a musician, I record sparks and then lose them, because a voice memo saves the sound but not the context. So I defined the real problem as capture-and-retrieval, and everything downstream followed from that framing.

The sharpest expression of this is one word. I changed the opening call to action from "Start a song" to "Start an idea." "Start a song" promises an output the product deliberately won't deliver; "Start an idea" sets the honest expectation — this is a place to hold and grow a thought, not a vending machine for finished tracks. I tested the wrong version informally on a non-musician, who expected a finished song to come out. That confirmed the risk: if the framing implies generation, the product fails on contact.

My marketing-communication background led me to also approach this from the perspective of user expectations. My first diagnosis isn't only "redesign the screen" — it's also asking what the product is saying to the user before it says anything visually.

You value the song because you went through the process of making it — not because you prompted it.

That's why I rejected the obvious framing: a Suno-style generator that spits out thousands of songs from a prompt. It would demo better and be easier to market. I killed it because it destroys the thing I actually value — the process is where the meaning is. SonLab is deliberately narrow, built for the person who wants to feel the process, not skip it.

Process

The direction I killed: structure-first onboarding.

The first Figma Make version was almost non-functional: it collected ideas and dropped them into empty boxes with no purpose beyond sitting there. That was enough to see the concept — and enough to see its two problems.

My early flow asked the user for all the context up front — name, general idea, genre, reference artists — before they could do anything. Two people hit the same wall: one told me he faced "too many questions before I could begin." I abandoned the structure-first flow and flipped to capture-first: the open screen lets you capture immediately, and the questionnaire only appears if you choose to build out a full idea. Capture is instant; structure is optional.

Then I watched people use it — and even the capture screen wasn't fast enough. Testers still hesitated at the start, so I split it in two: record on the left, write a lyric on the right. A spontaneous idea arrives as either a sound you hum or a line in your head, so the screen offers both at once instead of making you choose a mode first. The rule under every version: an idea must be savable before it's treated — if someone hasn't the time to add context, the system must not drag them through it.

I moved from Figma Make to Claude Code because Figma Make hit a ceiling — past a certain point it refused to implement the changes I needed, a hard limit for building a working system. The rebuild is where the bubble system, the AI-assigned colours, and the chatbot took shape.

AI in the workflow

AI builds and dresses the product. It doesn't decide it.

Inside the product — the intended design (real model)

The intended behaviour is that the AI learns each idea from the context the user gives it — influences, artist references, title, recorded sounds, lyrics — and assigns each idea-bubble a colour. As the idea grows more complex (chords, reference images, recordings, more lyrics), the colour deepens into richer shades, so the user can locate ideas by feel rather than by reading a list. A chatbot lets the user say what the song is about; an image generator produces cover-art as the AI "understands" the song.

In the demo — simulated with presets

Those three run on preset responses in the prototype, so what you click through is the behaviour I designed, played back. Every screen, state and interaction is the product as intended; only the intelligence behind them is a stand-in — the design is real, the model is not.

In my process — real

Figma Make for the first sketch, Claude Code for the working build, and ChatGPT to generate reference images that showed Claude how I wanted the bubbles to look.

Where I deliberately didn't use AI

Every concept, UI and flow decision came from me. I didn't prompt my way to the product logic — I designed it, then used AI to build and dress it. And I refused AI song generation outright, on principle, not for lack of ability.

Craft

Four screens, four decisions.

Main page — song progress bar, the bubble canvas, suggested ideas, final-draft recorder, AI song image
Colour carries meaning, not decoration — each bubble's shade signals how developed the idea is, so the user reads progress at a glance.
Start screen — split capture: record on the left, write a lyric on the right
Record left, write right — I split capture in two after watching testers hesitate, because a spontaneous idea is either a sound or a line, and the screen shouldn't make you pick a mode first.
Inside a bubble — connect related bubbles and develop one part with chords, images, recordings, lyrics
Users wire their own connections between ideas rather than auto-linking, because meaning in songwriting is personal, not algorithmic.

Outcome & learning

One thing proven. The best parts, still unproven.

SonLab is a functional, simulated prototype that translates a personal frustration into a capture-first songwriting system — and its clearest learning came from watching people use it: they hesitated at anything that felt like setup. That drove two changes — cutting the upfront questionnaire, then splitting the capture screen into record / write — and it's the part of the design I've actually validated. The rest came from my own experience.

If I continued, the one thing I'd test next is usability of the core loop: can someone capture an idea, leave, come back, and find and develop it without help? That's the promise the whole product rests on, and I haven't proven it yet.

This is my critique: I leaned mostly on my instinct — I developed this project more personally, through intuition, than functionally, through testing. I designed the most opinionated features that way. But the features that were validated were the ones that came from testing, not from my instinct. The next step isn't more features; it's evidence.