Putting any song on a child's screenless speaker — from your phone.
A mobile-first web app that lets parents upload personalised audio stories and songs to their Faba device in under 2 minutes, no technical knowledge required.
My Role
UX Designer + Vibe Coder
Tools
Claude · Figma · Render
Development
1 week (evenings)
My son has a Faba+ — one of those screenless storytellers where kids tap figurines to play stories. He loves it. But there's no Brazilian Portuguese content in the library, which for a Brazilian-Italian family is a real gap. I wanted to add songs from his other culture, but the only way to do it required a desktop computer, a Chrome extension, and about 20 minutes of trial and error.
Before building anything I checked the Faba Parents Facebook group. The question "how do I add my own songs?" came up every single week. Same question, different parents, no good answer. That's when this stopped being a personal project and started feeling like something worth actually solving.
Existing workaround
FabaMore Chrome Extension
✕ Desktop only — requires PC or Mac
✕ Browser extension installation required
✕ Non-obvious 5-step flow
✕ Must find and prepare an MP3 file separately
✕ Single file upload only per session
✕ No YouTube integration
12k
members in the Faba Parents Facebook Group
#1
most recurring question: custom audio upload
0
mobile-friendly solutions before this project
FabaMore, a Chrome extension, technically solves it — but only for users who own a PC, know how to install browser extensions, and can navigate a non-obvious multi-step flow. For the typical parent on their phone, the gap was total.
User Journey
Before: the FabaMore path
Mapping a parent's experience trying to upload a Brazilian song using the only available solution — the FabaMore Chrome extension.
TRIGGER
Child asks for a Brazilian song they heard somewhere
"I'll just add it to their Faba…"
Optimistic, motivated
DISCOVERY
Searches Facebook group, finds FabaMore suggestion
"There's a Chrome extension? Let me try…"
Must switch to a desktop computer
SETUP
Installs extension, opens MyFaba, tries to find the invite link
"Which button? Where is the link?"
Non-obvious flow, multiple attempts needed
FILE HUNT
Tries to find an MP3 file of the song
"Where do I even get an MP3?"
Most people drop off here
OUTCOME
Returns to Facebook group, gives up
"It's too complicated."
Child doesn't get the song
Key pain points identified
🖥️ Desktop dependency
Parents are on their phones. Requiring a PC is an immediate, hard drop-off point for most.
🎵 File sourcing gap
Parents don't have MP3 files. They know the YouTube video they want — not the file format.
🔗 Invisible flow
The invite-link mechanism is non-obvious. Even technical users needed multiple attempts to understand it.
User Journey
After: Faba Me Uploader
Every friction point from the previous journey is directly addressed. Same goal — completely different experience.
TRIGGER
Child asks for a Brazilian song
"I can do this from my phone!"
Opens the app on mobile
STEP 1
Searches Facebook group, finds FabaMore suggestion
"There's a Chrome extension? Let me try…"
✓ Verified in 3 seconds
STEP 2
Installs extension, opens MyFaba, tries to find the invite link
"Which button? Where is the link?"
✓ Song found instantly
STEP 3
Tries to find an MP3 file of the song
"Where do I even get an MP3?"
✓ Audio sent to Faba
OUTCOME
Returns to Facebook group, gives up
"It's too complicated."
✓ Task complete. Child happy.
What Changed
Before & after
Before — FabaMore Extension
Uploading a custom song
✕ Requires a desktop computer (PC or Mac)
✕ Must install a Chrome browser extension
✕ Navigate MyFaba → generate invite link → copy → send to laptop
✕ Must find and have an MP3 file ready on the computer
✕ No YouTube integration — must pre-download audio separately
✕ Single file upload per session
✕ No upload progress feedback
✕ Estimated time: 15–30 min for first-time users
After — Faba Me Uploader
Uploading a custom song
✓ Works on any phone — no app download required
✓ No installation — just open the web link
✓Paste invite link in a single guided step with contextual help
✓ Upload MP3 files or paste a YouTube link directly in the app
✓ YouTube integration built-in — no file sourcing needed
✓ Multi-file queue with drag-to-reorder and per-file titles
✓ Real-time per-file progress bar with status messages
✓ Estimated time: under 2 minutes
Design Process
From Insight to Interface
🤖
Vibe coding with Claude
The whole app was built through conversation with Claude — I'd describe what I needed, explain why, share a Figma screenshot, and Claude would write the code. I never touched the implementation directly. What I did do was evaluate every output, decide what wasn't working, and figure out why. That back-and-forth was faster than I expected and slower than I hoped, in equal measure.
→ 100+ iterations across a week of evenings. No code written by me.
📱
Mobile-first, always
Every decision started from a 390px screen. These are parents on their phones, usually standing in the kitchen. The 4-step wizard, sticky bottom nav, generous tap targets, iOS safe-area handling — none of that was optional. Desktop got a proper two-column layout eventually, but as progressive enhancement, not the starting point.
→ All 5 test users completed the task on mobile, without prompting.
🎨
Figma for concept validation
I used Figma to work out the step structure, visual hierarchy, and component design before any code existed. The stepper pattern, card layouts, disabled-state colours, typography — all defined there first. Sharing a screenshot with Claude turned out to produce much more accurate results than describing the same thing in words.
→ Visual briefs consistently outperformed written descriptions.
🔬
Real users, real iteration
Five mothers from the Faba Parents Facebook group tested the app on their own phones, unmoderated. V1 was a single-page form — 3 of 5 dropped off before completing it. V2 was the 4-step wizard — all 5 finished. I didn't tell them what to do differently between versions. I just watched, took notes, and changed what wasn't working.
→ 100% task completion in V2. Every change came from something I saw.
V1 → V2
First version, then a rethink
The first version was a single scrollable page — all fields at once, submit at the bottom. It seemed logical. In testing it caused immediate confusion: people didn't know where to start, skipped the link verification step, and hit errors they couldn't explain because they'd done things in the wrong order.
V1 - Single Page
✕All fields visible at once — users didn't know where to start
✕Single global title field confused multi-file uploads
✕No link validation before attempting upload — errors came at the end
✕No YouTube option — users had to source MP3 files externally
✕Grey disabled button felt broken — 3 users tapped it thinking app had crashed
No guidance, no progress
V2 - 4 Step Wizard
✓Progress indicator — user always knows where they are
✓Link verified before selecting files — error surfaced immediately
✓Per-file titles, YouTube integration, drag-to-reorder queue
✓Quick-select name pills — Step 3 time down from 18s to 4s
✓Salmon disabled button — signals "not ready" not "broken"
One task at a time
The core shift: from a form to a flow
Drop-off at V1
3 / 5
users left early in the first round of testing
Drop-off at V2
0 / 5
everyone completed on first attempt
KEY UX DECISIONS
Design rationale
These are the decisions that actually moved the needle — each one came out of something observed in testing, not a hunch.
1
4-step wizard instead of a single long form
There are four separate things the user needs to do: verify a link, choose audio, say who they are, and confirm. Putting all of that on one screen meant nobody knew where to start. Splitting it into steps made each task obvious — and the progress indicator meant people knew they were getting somewhere, which turned out to matter more than I expected.
→ 3 of 5 users dropped off in V1 before reaching the upload button. 0 dropped off in V2.
2
YouTube as the primary audio source, not an afterthought
4 of 5 testers couldn't find an MP3 on their phones. Two opened Spotify. One searched for "how to download MP3." All of them immediately knew which YouTube video they wanted. That was the clearest signal in the whole study — the problem isn't uploading audio, it's finding it in the first place. Moving the YouTube field above the file dropzone was the most impactful single change I made.
→ 4/5 users used YouTube rather than uploading a file
2b
Getting YouTube to actually work took much longer than expected
Deciding to add YouTube was easy. Making it work from a cloud server was not. YouTube blocks audio extraction from datacenter IPs — hosting services like Render use exactly those IPs. Everything failed in sequence: ytdl-core (deprecated), youtubei.js (crashes on certain responses), direct InnerTube API calls (LOGIN_REQUIRED across all clients), yt-dlp with exported cookies (Google invalidates sessions from different IPs). A diagnostic test confirmed that only the ANDROID_VR client — which impersonates an Oculus Quest headset — returns a usable response from Render's server, and only for videos without major-label restrictions. The solution that finally worked: a third-party API (RapidAPI) that handles all the authentication complexity on their end. The app sends a video ID, waits for the MP3 to be ready, downloads it, converts to WAV via ffmpeg, and uploads to Faba. The whole thing takes 20–60 seconds, which the progress bar communicates clearly.
→ Works for all public videos, including those with label restrictions
3
Per-file titles instead of one global title field
V1 had a single "track title" field at the top — one name for all the files you were about to upload. In testing, nobody uploading multiple songs knew what to type. The fix was obvious once I saw it: give each file its own title, auto-filled from the filename or YouTube video title. Most people never changed it. The ones who did, knew exactly what they were doing.
→ Removed a consistent point of confusion for anyone uploading more than one file
4
Salmon-pink disabled button, not grey
Three testers tapped the grey "Avanti" button and assumed the app had broken. Grey reads as "something's wrong" on a phone. Switching to a desaturated, washed-out version of the orange kept the visual language consistent while signalling "not yet" instead of "broken." A small change that stopped a recurring moment of panic.
→ No tester assumed the app was broken after the change
5
Name pills for the author step
Typing your name on a phone keyboard took 18 seconds on average and produced typos. Once I noticed that everyone was typing the same small set of words — Mamma, Papà, Nonna, Nonno — the answer was obvious. One tap. Done. Most users smiled when they saw the pills, which I hadn't expected but probably should have.
→ Average time for Step 3 dropped from ~18s to ~4s
The 4-step mobile flow
Interface
Each screen is scoped to a single task. No unnecessary information, no visual clutter, no ambiguity about what to do next.
User Testing
5 mothers. 5 successful uploads.
Unmoderated testing was conducted with 5 mothers recruited from the Faba Parents Facebook community. Each received a single task: "Upload a song for your child's Faba device using this invite link." No instructions were given. No guidance. Phone only.
100%
task completion rate — unmoderated, on mobile, first attempt
4 / 5
users chose YouTube over file upload as their primary method
< 2′
average time from opening the app to audio successfully sent
KEY FINDINGS
1
Finding MP3 files was the primary pain point — and YouTube solved it
4 of 5 users were unsure how to locate an MP3 file on their phone. Two opened Spotify. One searched for "how to download MP3." All of them immediately knew exactly which YouTube video they wanted. This was the clearest signal in the entire study: the file-sourcing problem is real, and YouTube integration is the right answer — not a nice-to-have.
→ YouTube section repositioned as the primary audio source above the file dropzone
2
The invite link step needed explicit navigation instructions
2 users weren't sure what an "invite link" was or where to find it in the MyFaba app. Once the helper copy was updated to include exact navigation steps ("MyFaba → Faba Me → Add track → Invite to record"), both completed the step without hesitation on their next attempt.
→ Inline contextual instruction added directly below the link input field
3
The success screen needed device-specific sync instructions
After uploading, every user asked "now what?" The original success screen said only "check the MyFaba app" — leaving users with the original Faba Raccontastorie (which requires a PC sync) confused and stuck. Two distinct completion paths were needed for the two device types.
→ Success screen redesigned with two explicit paths: Faba Raccontastorie (PC sync) and Faba+ (automatic Wi-Fi sync)
4
Typing a name on mobile was slower and more error-prone than expected
The name field in Step 3 averaged 18 seconds to complete and produced typos in 3 of 5 sessions. Observing that "Mamma" appeared in every single session, and that the same 6 relationship names covered virtually all use cases, led directly to the pill-based quick-select system that reduced this step to a single tap.
→ Name pills introduced; average Step 3 completion time dropped from 18s to 4s
"I didn't know I could do this from my phone."
Valentina, test participant — completed upload in 1 min 42 sec
How it was built
Tools & Process
-
Claude (Anthropic) — Primary development partner
-
Figma — Wireframes & visual design
-
Render — Deployment & hosting
-
Node.js / Express — Backend (AI-generated)
-
RapidAPI (YouTube MP3 Audio Video Downloader) — YouTube audio extraction
-
Facebook Groups — User research & recruitment
This is a vibe coding project — every line of code was written by Claude through conversation. My job was every design decision, every requirement, every "this isn't quite right, here's why," and all the research and testing. I didn't write code, but I directed everything that shaped it.
What "vibe coding" means in practice
My role as UX Designer
→Defining user requirements and UX constraints
→Evaluating each build iteration against design principles
→Creating Figma mockups as visual briefs for Claude
→Conducting user research, testing, and synthesis
→Directing all iteration: what to change, why, how
Claude's role as Engineer
→All HTML, CSS, and JavaScript implementation
→Node.js backend and server architecture
→Faba API reverse-engineering and integration
→Audio conversion pipeline (FFmpeg)
→Docker configuration and Render deployment
Reflections
What I learned
1. When you remove implementation friction, design clarity becomes the bottleneck
Vibe coding is fast — but only if you know precisely what you want before you ask for it. The hard part shifted from "how do I build this" to "what exactly do I need." That sounds obvious but it's a different skill, and one I got noticeably better at across the week.
2. People think in songs, not files
The most useful thing I saw in testing wasn't a broken interaction — it was five mothers opening Spotify when asked to find an MP3. They didn't think in file formats. They thought "I want that song." YouTube integration wasn't a feature request; it was the obvious answer to a mental model mismatch.
3. A Facebook group can be a better brief than a stakeholder doc
The Faba Parents group gave me the problem statement before I wrote a single line of code. The same question, from different people, every week, for months — that's as clear a signal as you'll ever get. Testing with people from that same community closed the loop in a way that felt rare for a solo side project.
4. Some constraints only appear when something is actually live
YouTube blocking audio extraction from cloud servers isn't documented anywhere — you only find out when your deployed app stops working. Getting to the solution required building a diagnostic tool, testing six different API clients, and working through the logic of why certain IPs get flagged and others don't. None of that was predictable upfront. It was just problem-solving, iteration by iteration.