Design · 4 min read
Why the whole app is two buttons
Somebody is standing at a pool table, in a dim room, with music on, holding a phone in one hand and a cue in the other. That is the entire design brief.
The thing you are competing with is a pen
Not another app. A whiteboard and a marker. Somebody writes names down the left, scratches a tally next to one of them, and moves on. It takes about a second and a half and requires no attention.
Anything that takes longer than that loses. Not "is worse than" — actually loses, because the person running the night will stop reaching for the phone and go back to the board, and you will never see them again.
What that rules out
Almost everything, as it turns out.
It rules out selecting which player you are recording against, because by rack four nobody is reading the screen — they are tapping where the button was last time. The app has to know whose turn it is.
It rules out a confirmation step. Two taps is not two taps; it is a tap, a glance, and a second tap.
It rules out anything that waits on the network. A spinner in the middle of a rotation is the moment the whiteboard wins.
And it rules out moving the buttons. Ever. Not when the player is on their last life, not when the rack is empty, not for a special case. A button that is sometimes somewhere else is a button you cannot learn.
What that leaves
Two buttons: made it and missed. Fixed positions, full width, 88 pixels tall, with an icon and a word on each so they are not distinguishable by colour alone.
Above them, the shooter's name — set in a condensed face at up to seven rem, so "Christopher" still fits across a 375 pixel phone, and so the whole thing is readable when the phone is mirrored onto a television.
Below them, three quiet things: undo, new rack, and the board.
That is the screen. Everything else in the product — the roster, the payouts, the stats, the TV display — exists on other screens, because none of it is happening while somebody is waiting to shoot.
Undo is the other half of it
If there are only two buttons and no confirmation, people will hit the wrong one. That is not a flaw in the design; it is the cost of the design, and it is cheaper than the alternative.
So undo had to be genuinely unlimited, and it had to correctly reverse anything — including a third strike, which has to un-eliminate the player, put them back in the right place in the rotation, and rewind the rack count.
That is hard to do by writing an inverse for every action, and easy if the night is an append-only log of events and the state is just a replay of it. So that is how it is built. The two buttons on the screen are the reason the architecture underneath looks the way it does.