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.
Context & constraints
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
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 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
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
Outcome & learning
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.