Wayne wanted drag-and-drop. Jayne couldn’t scroll past song 9.

The same setlist feature got two opposite reactions from two beta testers in the same week. Worth writing down what I learned, because I think it’s the most useful thing the beta has taught me yet.

Two reactions, same feature

Wayne is The Imitation Zone’s guitarist and the band’s MD. He’s been the most active beta tester — he’s the one who told me to add play counts and rehearsal notes back when the app was held together with hope. Last week he opened a setlist and discovered I’d shipped drag-and-drop reordering. He loved it. Texted me about it.

A few days later Jayne — the band’s manager, not a player — opened the same setlist on her phone. She’d been added to the band so she could see what’s going on, organisationally. She read the gig details, looked at the songs, and then tried to scroll down the setlist to see what was after song 9.

She couldn’t. The list wouldn’t scroll.

She emailed me to ask if the WoolyFest set was really only 9 songs long.

What I’d built

Every song row had a drag handle on the left. The handle activated the touch sensor on tap-and-hold. To stop the browser fighting the drag, I’d put touch-action: none on the whole row. That meant the row didn’t scroll under your finger.

If you were Wayne — actively reorganising the set — that was perfect. Tap, drag, drop. Beautiful.

If you were Jayne — reading, not editing — every row was a tap-bait that intercepted your scroll attempt. The sliver of real estate on the row that did allow scrolling was so narrow that her phone couldn’t tell what she was trying to do.

I’d built a power-user thing into the default. Anyone who wasn’t actively reordering paid a tax. Anyone who was, got value.

The fix

I shipped a small button at the top of the setlist that toggles between two modes:

• View mode (the default): no drag handles, no remove buttons, the list scrolls like any list. Same Jayne-flow as her instinct expected.
• Reorder mode (after tapping the button): drag handles appear, remove buttons appear, the row is draggable. Same Wayne-flow as before.

It’s the iOS Notes / Reminders pattern. Most testers — including Jayne — will already know it implicitly: see the Reorder button, intuit what it does, get on with their day.

A side-effect bonus: the always-visible remove button was also tap-bait. Hiding it behind the toggle eliminates an entire category of “wait did I just delete that song?” moments I hadn’t even seen yet but was probably going to.

The lesson I keep relearning

Wayne is one kind of user. Jayne is another. They’re in the same band. They use the app for opposite reasons. If I’d only had Wayne in the beta cohort I would have shipped what felt like a great feature and quietly broken it for everyone else.

The thing I keep getting wrong is assuming the user who’s loudest is the user I’m building for. Wayne is great — he tells me what he wants and he’s right about most of it. But Wayne’s MD-shaped attention means he never sits with the app the way Jayne does. He never tries to just read a setlist. He’s always doing something to it.

You need both. The reader and the editor. The player and the manager. Not because one’s right and one’s wrong — they’re using it differently and both ways are valid — but because the default has to work for the user who isn’t pushing buttons.

This is the third time in this beta I’ve thought “Rob you idiot, of course”. It probably won’t be the last.

What’s next

Stripe billing in a couple of weeks. The plan was always to give beta testers a month free when subscriptions launch — they earned it. Public launch is the month after that. In the meantime I’m two hours a week into building in public. If you’re a working musician and you want to follow along, the waitlist below is where you wait.