AI Builds · Case study · 2026

Drum Kit

Drum Kit

A realistic drum kit you can play in the browser, on desktop, tablet and phone. Every sound is synthesized live and every drum is drawn in code, so the product ships without a single audio file or image.

Play it live

Code on GitHub

My role

Senior product designer: strategy, interaction and visual design, design system, QA

Build

AI-assisted: Claude wrote the code to my specifications

Stack

Vite, plain JavaScript, Web Audio API, SVG

Timeline

4 days to v2.0, then four refinement releases (Oct–Nov 2026)

The drum kit seen from above on a wood floor: cymbals, toms, snare and kick with their keyboard keys, and the toolbar with Hover/Tap, Rec, Concert and Learn.

The Studio kit in its Hot Rod look, seen from above. Keys appear on each drum when “Show keys” is on.

Overview

At a glance

PROBLEM

Browser instruments are usually toys or tied to licensed samples. I wanted a realistic kit that plays with multi-touch on a phone and ships as open source.

APPROACH

Rules before code, three phases, then five releases shaped by playtests.

OUTCOME

v3.0 is live: 3 kits, 8 looks, lessons, layered recording and a concert mode, as a drum kit or a pad grid, by touch, mouse or keys.

3

kits with their own synthesized sounds

11

pads: touch, mouse and keyboard

8 + 10

lessons and style beats

0

audio files, images or outside icons in the app

Process

Four stages, in loops

I used the Double Diamond, but not in a straight line: each release looped back through playtests and refinement.

Discover

Reference apps, a question round, goals

Define

Brief, principles, phases, information architecture

Develop

Concepts, standards, iterations, reviews

Deliver

Build, release, impact

Develop and Deliver looped 5 times: v2.0 to v3.0

Stages 1–2

Discover and Define

Goals, principles and phases

A full product cycle with the AI writing the code to my specifications. Before any code: a question round on scope, sound, input, devices and hosting, and a review of drum apps for interaction patterns (not their art).

Constraints: lightweight and secure, functional first; realistic, not cartoon (true proportions from above, a 14″ snare and 22″ kick); every device, by mouse, keys or multi-touch.

Principles: lock the layout early and the look late, because layout is costly to change while colours and textures live in tokens. A rules file gave the AI the scope, quality bars, file sizes and review gates.

A small product doesn’t need the traditional UX route of full, high-fidelity mockups for every screen, so I kept it lean: concepts first, then functionality, then the UI layer. Quick concepts set the direction, a working build proved the functionality, and the look went on top.

Three contexts of use

PLAY

“Let me hit something now”

Sound on the first tap, keys on a keyboard, thumbs on a phone.

LEARN

“Teach me a beat”

Only the drums that matter lit up.

PERFORM

“Let me show it off”

Layers, a WAV download, a cheering crowd.

A phased rollout

PHASE 1

The core in landscape

The kit, sounds, EQ, recording and lessons where the kit plays best.

PHASE 2

Phones and tablets

Upright phones and tablets brought to the same standard.

PHASE 3

A second way to play

The pad grid, for upright phones and beginners.

Information architecture and progressive disclosure

Toolbar: primary actions only, in priority order: Rec, Concert, Learn.

⋮ menu: rare settings: EQ, metronome and tempo, theme, keys, flashing lights, guide and reset.

Customize: sound (Kit, EQ) apart from look (Look, Background, Sticks), with the view choice above both, because it decides which apply.

Stage 3

Develop

The layout call, then the look

Layout: front view or top view?

A grid of 8 pads was quickest, but it does not read as a drum kit (it returned later as an optional view). The real choice was between the two ways people picture a kit:

FRONT VIEW: REJECTED

Iconic, how an audience sees a kit, and instantly recognisable.

But targets overlap: cymbals sit in front of toms and the kick hides behind the snare, so taps land on the wrong piece.

Perspective shrinks the back pieces into thin ellipses, too small to hit with a thumb.

It is tall, so it wastes a landscape phone screen and multi-touch gets cramped.

TOP VIEW: CHOSEN

The drummer’s view: looking down at the heads you actually hit.

Every piece is a separate, round target the shape of its real playing surface, at true relative size.

Wide and shallow, so it fits landscape screens and leaves room for two thumbs.

The trade-off is that it is less iconic at a glance; realistic hardware, chrome, lathe rings and soft shadows win that recognition back.

Invisible, generous hit areas sit under the art, so small cymbals stay easy to tap and the artwork can change without touching input.

Visual direction: four concept rounds

Flat shapes, then a cartoon kit, then a concert scene that hid the drums; round 4, top-down with light depth, set the direction. The concert idea survived as a feature.

Round 1

Flat shapes: right layout, didn’t read as drums.

Round 2

Illustrated kit: recognisable, but too cartoonish.

Round 3

Concert stage: great mood, but the scene hid the drums.

Round 4

Top-down with light depth: the chosen direction.

System

Rules and tokens, not taste

I set the interaction rules and encoded decisions as tokens and one state model; the AI applied them everywhere and automated checks held them across five releases.

Reach: playing in the thumb zone, rare actions in ⋮ (Hick’s and Fitts’s laws), 40 px tap areas since v3.0.

Accessible by default: 4.5:1 text and 3:1 edges in both themes (WCAG 2.2), safe flashing and reduced motion.

Colour means something: saffron means act, red means recording now, and green stays “on time” in lessons.

Nothing disappears without a reason: options that do not apply are dimmed, with a way back.

Grouping: pads grouped by role, one family and one colour per row (Gestalt).

Status always visible: a countdown, a red Rec with the time, one red Stop and a live timeline.

Scope: lyrics and microphone recording deferred (MoSCoW) to keep the kit instant to play.

Role colours with a contrast budget

One colour per instrument family, each tuned per theme to clear 3:1 against the page (WCAG 1.4.11).

Dark

Light

Cymbals

5.8 : 1 · 3.5 : 1

Dark

Light

Toms

3.9 : 1 · 4.3 : 1

Dark

Light

Hi-hats

6.2 : 1 · 3.1 : 1

Dark

Light

Snare

4.2 : 1 · 4.4 : 1

Dark

Light

Kick

3.3 : 1 · 4.4 : 1

Recording as a state model

Six states, specified before the controls were redesigned, and one rule: no button changes meaning under the thumb. Play only plays or pauses, Stop only ends recording, Add layer only starts one.

State

Rec

Play / Pause

Stop

Add layer

Idle, with a recording

Play

Counting in

3·2·1

Recording the take

0:12

Adding a layer

Playing back

Pause

Paused

Play (resumes)

from here

Available

Recording signal

Shown, greyed (never hidden, never moved)

One spacing system in two densities: tile padding, radius and gap are 20 / 16 / 12 px on desktop and 14 / 8 / 10 px on phones, and controls share one 32 px height.

Four screen classes, one set of components

Desktop and upright tablet: labelled toolbar, recording bar above the kit, text tabs and keys shown; Concert in 4 rows on desktop and a full crowd strip on tablets.

Phone, sideways: a one-row icon toolbar, the recording panel as a column beside the kit, icon tabs, keys hidden.

Phone, upright: the kit at the bottom under up to 15 crowd rows, the recording panel edge to edge and floating over the crowd, and Customize stepping aside while recording or learning.

Recording · v2.0 to v3.0

Obvious to start, impossible to lose

I handed each release to colleagues and friends and watched them play without guidance. Every hesitation became an annotated screenshot and a fix checked on 9 screen sizes. Each topic below follows one problem from v2.0 to v3.0.

The old recording panel: a thin strip with tiny timeline rows squeezed between many buttons.

Before

Layers were barely visible between the buttons.

The new recording panel above the kit: title and player on top, four full-width layer rows, Add layer and Undo below.

After

Full-width rows, the player on the right, layer actions under the layers.

A large number 2 in a dark disc with a red ring in the middle of the kit, counting down before recording.

The countdown sits in the middle of the screen, where the eyes already are.

The recording panel on a phone with two buttons labelled Stop: an orange one in the player row and a greyed one beside Add layer.

Before

Two Stops on screen at once, a REC badge, and a red outline on the panel.

The recording panel while adding a layer: a greyed Play, marks in instrument colours, a filled red Stop beside a greyed Add layer.

After

One red Stop beside Add layer; the player pauses instead of stopping; marks in each instrument’s colour.

Before

A recording and a lesson open together.

After

Opening a lesson stops the take, keeps it, and says so.

Before

The note pointed back up to the toolbar.

After

Rec right where the eye ends.

PROBLEM

Layers were a few pixels wide and nothing said when recording began. Later, five cues and two Stop buttons fought for one state, and a recording and a lesson could run at once.

WHAT I DID

Full-width layer rows and a 3-2-1 countdown (v2.0); one red Stop and a real Pause, so no button changes meaning (v2.3); recording, lessons and Concert take turns and the take is kept (v3.0).

IMPACT

Layer rows from a sliver to 800 px, recording cues from 5 to 2, one mode on screen at a time and no way to lose a take.

Phones · v2.0 to v3.0

Design for the thumb, not just the screen

Concert mode on an upright phone before the fix: a small kit and crowd squeezed into the screen.

Concert mode on an upright phone after the fix: a full crowd of seven rows at the top and a bigger kit below.

A lesson on an upright phone, with a dropdown showing Demo, a Click switch and Speed controls.

On an upright phone: Concert before and after, and the lesson controls tucked into a ⋮ menu.

A phone held sideways: the kit on the left and the recording panel as a narrow column on the right.

Held sideways, the recording panel moves beside the kit instead of pushing it down.

Zoomed view of the old toolbar: Rec with play and loop, a metronome with tempo 100, Learn, Concert and More.

Before

Seven controls competing for attention.

Zoomed view of the new toolbar: Rec, Concert, Learn and a more button.

After

Four controls, in priority order.

Concert on an upright phone: the drum kit centred with empty stage floor above it and a short crowd at the top.

Concert on an upright phone: the drum kit near the bottom of the screen and a large crowd filling the space above the lighting truss.

v2.3, before and after: the kit drops into thumb reach and a bigger crowd fills the space above.

The toolbar and lesson bar on a phone, with dashed green outlines showing each control’s invisible tap area; none overlap.

Dashed outlines show the invisible tap areas (drawn for this picture only).

PROBLEM

Phase 1 was landscape: a two-row toolbar with seven controls, a kit floating above the thumb zone, and small controls too close together for a 44 px tap ring.

WHAT I DID

A one-row toolbar cut to four controls, the recording panel beside the kit when sideways, the kit anchored to the bottom under a bigger crowd, and 40 px tap areas that never reach a neighbour.

IMPACT

Toolbar from 104 to 48 px, a crowd of about 435 instead of 174 on a 390 px phone, and 0 tap collisions on 32 phone screens.

Pad grid and looks · v2.0 to v3.0

A second way to play, built from the same kit

The pad grid view of the same kit: eleven tiles grouped by family, each with its key.

The drum kit view: cymbals, toms, snare and kick seen from above on a wood floor, each with its key.

Drag to compare: the same drums, keys and sounds, as a realistic kit or as a grid grouped by family.

The final pad grid on a dark desktop screen: eleven tiles with instrument drawings in orange, blue, green, pink and red.

The pad grid on an upright phone, anchored to the bottom of the screen.

The final grid on desktop and on an upright phone, where it sits within thumb reach.

The pad grid with red review marks: names tight to the tile corners, and equal gaps between tiles and between rows.

Before

My review marks: names crowd the corners; every gap is the same.

After

Even gaps, room inside every tile, and a border in each family’s colour.

The pad grid on an upright phone in the light theme: coloured tile borders, even gaps, no key badges and an icon-only Customize tab above the grid.

On phones, in the light theme: full-width grid, icon-only Customize tab, no key badges.

The pad grid in the Dragon look: dark red lacquered tiles with a scale texture, and one gold dragon drawn across several tiles, with a band of light sweeping over the right side.

One dragon across the whole grid, each tile showing its slice; a band of light sweeps across once per visit.

The pad grid in the Neon Synthwave look: violet tiles with a striped sunset sun behind the middle and neon horizon lines across the bottom row.

Neon Synthwave: a sunset and a neon horizon running behind the pads.

The Look tab in the pad grid view before the fix: every card shows a tiny grid of outlined rectangles that look almost the same.

The Look tab after the fix: each card shows one large Snare pad in its look, with scales, filigree, a synthwave sun, stars or flames.

The Look tab before and after: tiny grids that all looked alike, then one large sample pad per look.

An earlier attempt: engraved dragons in red and dark ink on the cymbals and in gold on the floor tom; the faces read more like a cat than a dragon.

Cut

Round five of the dragons on the drums: well drawn, but the faces still read as a cat, so I removed them.

PROBLEM

The wide kit fills only a strip of an upright phone. The first grid had cramped names and faint edges (1.2:1), and its looks only recoloured the pads, so every pad looked the same.

WHAT I DID

A pad grid view of the same kit (v2.0); one spacing system and borders in each family’s colour (v2.3); every look drawn across the whole grid, with one large sample pad per Look card (v3.0). Dragon faces that still read as a cat after five rounds were cut.

IMPACT

A full-screen instrument in thumb reach, borders at least 3:1 in both themes, and eight looks that dress both views.

Learning · v2.0 to v3.0

Fair, then calm

A lesson in progress: only the kick is lit and labelled, other drums are dimmed, and a note says the lesson uses only Kick.

Only the lesson’s drums play; the rest dim and stay silent.

Before

A tiny “Get ready”, one colour for every drum, big labels over the drawings.

A lesson in v3.0: a large count-in number over the kit, and the beat grid with the snare steps tinted pink and the kick steps tinted red, the step under the line lit up.

After

The count-in big over the kit; steps with a note tinted in their drum’s colour, the one under the line lit.

The result card over a dimmed kit: 0% on time, a line saying 80% passes, and the buttons Try at 75%, Step by step and Try again.

After a run, a card offers the next step; the main one sits on the right.

During a lesson, a tap on a tom the lesson does not use: no sound, and a note at the bottom saying This lesson only uses Kick and Snare.

A drum the lesson does not use stays silent and says why, on every tap.

The lesson tour, step 3 of 4, pointing at the metronome and speed controls: Too fast? Slow it down with minus and plus, with Don’t show again, Skip and Next.

The tour, laid out to my sketch: step and ✕ on top, then the tip, then “Don’t show again” with Skip and Next on one row.

PROBLEM

On-beat hits scored “Miss”, a result button appeared out of nowhere, and the AI’s idea of playing unused drums quietly would read as the volume dropping.

WHAT I DID

Unused drums stay silent with a reason, cues glow on the beat, hits are timed from the tap, and a result card offers the next step, with speed levels from 50 to 150% and a four-step tour.

IMPACT

Every hit scored within a few milliseconds in a timed test; first-time players get one short tour, then are left alone.

Craft details

The small things that make it feel alive

Details that make people smile in the first ten seconds: a ripple where the stick lands, a crowd that cheers on crashes, a ba-dum-tss on the first touch, coffee steam and an amp cable. All drawn or synthesized in code, never tappable, and still for reduced motion.

The kit in the Neon Synthwave look on the Spotlight stage: glowing cyan and pink heads, a purple kick with a sunset sticker, and lamps above.

8 looks dress the kit itself: Neon Synthwave on the Spotlight stage.

The kit in the Dragon look on a red stage rug, with gold hardware, a dragon on the kick, a record player, a plant and a bead chain on the ride.

Dragon on the stage rug, with a spinning record player and a swaying plant.

The kit in the Classic Studio look on the Plain background, with faint sketched music doodles, a music stand and a guitar around it.

Classic Studio on Plain: sketched doodles, a music stand and clip-on mics.

Close-up of the snare just after a hit: rings ripple out from where the stick struck, and the stick is mid-swing.

Every hit answers back: a ripple where the stick lands, cymbals that wobble, a beater that swings and a hi-hat that lifts.

Concert mode: a cheering crowd with signs, glow sticks and a beach ball, a disco ball and coloured stage lights shining on the kit.

A crowd that listens: it bobs to the tempo, raises hands on crashes, jumps when you play fast and cheers when you stop.

Zoomed Customize drawer with View radio buttons for Drums and Pad grid above the tabs, and Look, Background and Sticks dimmed.

Customize in v2.3: the view choice moved above the tabs; rebuilt as a tab bar in v3.0 (below).

See-through pad grid tiles below a cheering crowd and coloured stage lights.

Concert with the pad grid: laid out under the lights; tiles let the lights glow through.

Props beside the kit: a practice amp with a cable running across the floor, a radio, and a mug of coffee with steam rising.

A steaming coffee, an amp with its cable, a radio.

Stage 4

Deliver

Directing an AI build partner

I owned the what and the why; the AI wrote the how, inside a rules file, approval gates and automated checks I set.

Claude Code answering playtest notes with a numbered proposal and the line “I haven’t changed anything yet.”

Playtest notes in, a proposal out: the AI suggested each change and waited for my OK before touching the code.

How I kept the AI, and myself, on track

PUBLIC REPO

CLAUDE.md: the rules for the AI: scope, quality bars, copyright, and “propose, then wait for my OK”.

src/: audio, input, kit, learn, ui and styles, one job per file.

docs/: the plan and its decisions, plus a log of every outside asset and its licence.

README: what it is, how to run it, and the folder map.

PRIVATE NOTES, NEVER UPLOADED

A start-here handoff, so every new session picks up with the full context instead of from zero.

The decision log, reversals included, and the open to-do list.

Test scripts and case-study screenshots, ready for the next release.

Kept out of Git, with a search for names, emails, paths and keys before every commit.

Read first, update last: every session starts by reading the notes and ends by updating them, so no decision lives only in a chat.

Release cadence

v2.0

The full product: kits, recording, Learn, Concert, pad grid

v2.1

Pad grid sizing and phone polish

v2.2

A fuller Concert crowd on phones; the version in the menu

v2.3

Spacing system, one-Stop recording with Pause, drums in thumb reach

v3.0

Looks on the pad grid, reworked lessons, one mode at a time, 40 px tap areas

5

releases, v2.0 to v3.0, each with notes

9

screen sizes in the automated test matrix

48 / 48

regression checks passed before v3.0

0

tap collisions across 32 phone screens

5 → 2

recording cues on screen at once

0

drums that move when Rec is pressed on a phone

8

looks that dress both the drums and the pad grid

0

known vulnerabilities at release

A live, open-source product on desktop, tablet and phone: 3 kits, 8 looks, 8 lessons, 10 style beats, layered recording with pause, Concert and a pad grid.

Production quality: 167 source files, about 13,700 lines and one build dependency; React, TypeScript and a sampled kit were set aside as too heavy for the job.

Insights

What this changed in how I work with AI

AI defaults are product decisions in disguise.

The AI optimises the component; the designer owns the screen, so every review checks its defaults against the whole screen.

The brief is the design deliverable.

“Nothing that needs attribution” was taken literally and nearly removed Vite; precise rules and true proportions produced original art.

A suggestion is only as good as the user’s mental model.

Quiet unused drums read as the volume dropping, so I chose silence with a visible reason.

Turn taste into tests.

Rules such as every pad reachable and no sideways scroll became automated checks on nine screen sizes, and a tap-area audit found overlaps nobody had noticed.

Know when to stop.

Five rounds of dragon faces drawn in code never stopped reading as a cat. Cutting them kept the release honest, and the decorative art that worked stayed.

One constraint can solve three problems.

Drawing and synthesizing everything in code kept the download tiny, made theming a token change and removed asset licensing.

Next time: every device in scope and a live link from day 1, a time-box for exploratory visuals, and moderated tests with first-time players on their own phones.

Result

Play it

Drum Kit runs on desktop, tablets and phones, with touch, mouse or keyboard. It is open source under the MIT licence.

drummingkit.vercel.app

github.com/Mehulworks/DrumKit