CHÀNG 唱

A note on method: I built and shipped this product first, then reconstructed the design reasoning behind it. To keep this case study honest, I’ve labeled which parts are grounded in evidence or lived experience and which are reasonable, defensible assumptions I did not formally validate. Nothing here is invented data.

Overview

Project	CHÀNG (中文跟唱) — a browser-based tool for practicing Mandarin pronunciation, line by line, through spoken and sung repetition
My role	Product Designer — sole designer and builder (concept, UX, interaction design, visual design, and implementation)
Timeline	~3 weeks, solo
Tools	Claude Code (build), browser speech recognition + speech synthesis, client-side pinyin generation, localStorage for persistence
Status	Shipped and in daily personal use

CHÀNG lets you pick a song, paste in its lyrics (pinyin is generated automatically), and then practice one line at a time: you speak each line to get scored on how clearly the syllables land, and sing it for fun once it feels solid.

---

The Problem / Challenge

Most language apps can already tell you that your pronunciation is wrong. What they don’t solve is the harder problem underneath: for people whose pronunciation was set early and informally, the errors aren’t gaps in knowledge — they’re automatic motor habits that are genuinely difficult to unlearn. Fixing them takes targeted, feedback-driven repetition, and repetition is exactly what drill-based tools make too tedious to sustain.

So the real challenge wasn’t building another feedback engine. It was designing a practice format that a person will voluntarily repeat, aimed at the specific learner whose sounds are ingrained rather than unknown.

---

Empathize — Who the user is

Primary archetype: the early-informal learner.

Someone who can already read and speak basic Mandarin, but whose pronunciation and tones were shaped early and informally — through a regional home dialect or casual learning at home rather than formal instruction. Their errors are consistent and confident, which is what makes them hard to catch and correct. They’re often understood by family but misheard by standard-Mandarin speakers, and standard learning tools feel either too basic or too boring to hold their attention.

A closely related secondary case is the classroom learner from the same background who tries to correct tones and pronunciation through formal study and finds it disproportionately hard, because they’re fighting an existing pattern rather than learning a blank one.

How I sourced this (honestly):

I did not run formal user research up front. This archetype is grounded in my own lived experience and close, direct observation of people around me with the same background. I’m treating it as a well-grounded design assumption, not a validated finding — and the “Test” section below is where I’d close that gap.

What this literature-adjacent framing does have behind it:

The core mechanism is a documented phenomenon in second-language acquisition called fossilization (Selinker, 1972) — errors that become ingrained and resist correction even with instruction. Pronunciation is singled out as the most stubborn case, because it involves rebuilding motor patterns, not just knowledge — and first-language influence is one of its main drivers. That maps cleanly onto this archetype. (I’m careful not to overstate the fix: the evidence that repeated training reliably improves production, as opposed to perception, is mixed. So I frame repetition as design rationale, not a guarantee.)

Needs and pain points (assumptions, flagged as such):

• “I know I’m off, but nothing tells me precisely which syllables.” Feedback exists in other tools, but usually on isolated drills, not in the flow of practicing something I actually want to say.
• “The practice that would fix this is too boring to keep doing.” Correcting an ingrained habit needs volume; drills don’t survive contact with real motivation.
• “Nothing lets me learn through the one activity I’ll happily repeat.” I’ll sing the same line twenty times. I won’t do twenty flashcards.
• “Practicing out loud is a little embarrassing.” I want something low-stakes and private.

---

Define

Problem statement

For learners whose Mandarin pronunciation was shaped early and informally, the barrier to improvement isn’t knowing they’re wrong — it’s sustaining the targeted, feedback-driven repetition needed to retrain ingrained motor habits. Existing tools deliver correction but not a practice format people will voluntarily repeat.

Motivation is not a “nice to have” here. It’s the actual bottleneck: the correction is useless if the learner quits before the reps add up.

How Might We…

• HMW give learners precise, syllable-level feedback inside real practice, not in a separate drill?
• HMW make the repetition required to retrain pronunciation something people want to do?
• HMW let learners isolate and master small units before facing a whole song?
• HMW separate the two hard problems — base syllables and tones — so learners aren’t overwhelmed by both at once?
• HMW respect copyright while still letting people practice the songs they love?

User needs

1. I need to see exactly which sounds I’m getting wrong, line by line.
2. I need practice enjoyable enough to repeat daily.
3. I need to build up in small, masterable chunks.
4. I need to choose my difficulty — syllables first, tones later.
5. I need to practice privately, at low stakes, on my own material.

---

Ideate

The direction I chose: learn through singing, scaffolded by speaking

Singing was the deliberate answer to need #2. It’s the activity this user will voluntarily repeat at volume, which is the whole game. Melody and rhythm also aid memory and prosody, and the practice transfers — once a line is internalized, you can rehearse it anywhere, no app required.

Alternatives I considered and rejected

• Shadowing videos — passive, and gives no feedback on whether you landed the sounds.
• Flashcard / drill apps — the exact failure mode I was solving for. Effective in theory, abandoned in practice.
• Whole-song karaoke scoring — too coarse to correct anything, and it collides head-on with the technical reality below.

The insight that shaped everything: speak to score, sing to enjoy

While prototyping, the decisive constraint surfaced: speech recognition reads spoken Mandarin far more reliably than sung Mandarin. Singing stretches vowels, bends pitch, and blurs word boundaries — exactly what wrecks a recognizer.

Instead of fighting that, I turned it into the pedagogy: you speak each line first to get it scored cleanly, then sing it once the syllables are solid. Speaking forces you to articulate each syllable without slurring; singing afterward makes those now-correct sounds even clearer. The limitation became the method.

---

Prototype

Information architecture

Song list  ->  Paste lyrics (auto-pinyin, stored locally)  ->  Line-by-line practice
   |                                                              |
   +- difficulty tags, "add lyrics"       speak -> score | hear model | replay | prev/next

Three screens, each tied to specific user needs.

1. Song list — choose a song

A calm, editorial list: title, translation, artist, a one-line character note, and a difficulty tag. Songs ship without lyrics; each has an “add lyrics” affordance.

Design decision → need: Not bundling lyrics is a conscious copyright constraint turned into a product principle. The learner pastes their own material, which also means they practice the songs they actually love (need #5), not a fixed catalog. An info banner states this plainly rather than hiding it.

2. Paste lyrics — one line per row

A single textarea. Paste raw lyrics, one line per row; pinyin is generated automatically for every character, punctuation is ignored, and everything is saved only in the browser (localStorage) — it never leaves the machine.

Design decision → need: This removes all setup friction (need #2) and makes the privacy/copyright stance a visible promise (need #5), which lowers the stakes of practicing out loud.

3. Line-by-line practice — the core loop

Each screen shows one line: large characters with per-character pinyin beneath, a progress indicator (e.g. Line 1 / 4), and three controls — a mic (speak to be scored), a speaker (hear a model reading), and a replay. Copy explicitly guides: for scoring, speak the line rather than sing it.

Design decisions → needs:

• One line at a time, with progress dots → small, masterable chunks and earlier feedback (need #3). You get a win every line instead of a verdict at the end of a song.
• Per-character pinyin → syllable-level clarity (need #1) and support for a syllables-first mindset (need #4).
• Speak-first guidance built into the UI → encodes the core insight so the user succeeds by default.
• Planned settings toggle: syllables-only vs. syllables + tones → lets learners separate the two hard problems and match feedback to their goal (need #4). This is directly supported by evidence that lexical tones respond well to targeted training, and it fits the archetype: get base sounds clean first, layer tones second.
• Restrained, warm visual language (serif display type, muted paper palette, minimal chrome) → a deliberate emotional-design choice to make a slightly embarrassing activity feel low-stakes and unintimidating.

Honest scoping note: the scoring is intelligibility-based — did the recognizer understand you as saying the right syllables — not fine-grained phonetic or tone analysis. That’s a deliberate scoping decision given the technology, and I’d state its ceiling plainly rather than imply the tool “grades your accent.”

---

Test

Status: not yet formally validated. Below is the validation plan I’m running (over ~1 week) and the hypotheses it tests. I’ll backfill real findings here — this section is written to be filled with evidence, not to fake it.

Hypotheses (each tied to a design decision)

• H1 — speak-first: spoken lines score more reliably than sung lines. (validates the core insight)
• H2 — chunking: line-by-line practice sustains more repetition than whole-song attempts. (validates the loop)
• H3 — progression: starting with syllables-only reduces frustration versus syllables + tones at once. (validates the toggle)
• H4 — motivation: the singing framing is enjoyable enough to sustain daily practice. (the central bet)

Method

• Self-log (daily): note lines the recognizer repeatedly marks wrong, cases where I was sure I said it right but it failed (separating my error from recognizer error), and whether speaking a line then singing it felt like it transferred.
• 2–3 external testers, including at least one classroom learner from a similar background. Give one task: “learn one line you couldn’t say before.” Watch for whether they grasp “speak, don’t sing,” where they stall, and whether line-by-line feels motivating or tedious.
• Lightweight measures (honest at small n): line completed? self-rated confidence 1–5 before/after? would you use it again?

[Backfill: key findings, surprises, and any changes made in response.]

The one real iteration so far

The biggest design change was a test-driven one: I started toward real-time feedback on sung karaoke and discovered the recognizer couldn’t reliably read singing. That failure is what produced the speak-first / sing-for-fun model. It’s a genuine prototype → insight → revision loop, and it’s the decision I’d defend hardest in an interview.

---

Outcome & Reflection

Outcome

CHÀNG shipped as a working tool I use daily — roughly half a song a day. I’m treating that as a personal, qualitative result, not a generalizable metric: it tells me the format is sustainable for the target user profile I designed against (which happens to be me), and the planned testing is what would extend that beyond n=1.

What I’d do differently

• Do lightweight discovery first. I reconstructed the user and problem after building. The thinking holds up, but I’d rather have entered the build with even a handful of conversations behind me.
• Stress-test the recognizer on day one. It drove my single biggest decision — I’d want that constraint surfaced before, not during, prototyping.
• Define the tone-scoring scope earlier. The syllables-vs-tones question shaped the feature set and deserved an explicit decision up front.

What I learned

• Designing around a hard technical constraint produced my best pedagogical decision. Speak-first wasn’t a compromise; it was the answer.
• The defensible version of “make it fun” is motivation-as-sustainability: the reps only pay off if the learner keeps showing up.
• Scoping feedback to intelligibility (rather than promising phonetic grading) kept the product honest and shippable.

Future directions

• Syllables ↔ tones toggle as a first-class setting, with tone feedback informed by the evidence that tones respond well to targeted training.
• Multiple model voices — moving the practice closer to established “high-variability” training principles, where hearing several speakers builds a more robust sense of a sound.
• Background music for a fuller singing mode — explored and deliberately deprioritized: it adds licensing complexity and pushes setup work onto the user, which conflicts with the low-friction paste flow. Knowing when not to build something is part of the reasoning I want on the page.

---

Reference concept: Selinker, L. (1972). “Interlanguage.” Fossilization and high-variability phonetic training are cited here as design rationale; the evidence base is stronger for perception than for production, which the copy above reflects.