Most mobile game UX advice is either platform guideline restated or a list of dark patterns with the labels filed off. What follows is neither — it's the set of decisions we've ended up making again on every puzzle game, usually after getting them wrong once.
The through-line: phones are held in one hand, played in interrupted bursts, by people who will not read anything. Every pattern below falls out of one of those three facts.
Put controls where thumbs are
The top of a modern phone screen is out of reach for one-handed use, and phones have only gotten taller. Yet the top-left back button and the top-right settings gear persist in game after game, inherited from desktop and from an era of much smaller devices.
The pattern: anything the player touches repeatedly lives in the bottom third of the screen. The top is for information — score, timer, level name — and for nothing you need to tap mid-play. If you must put a control up there, duplicate it somewhere reachable or make the whole header region tappable rather than a 30-point icon in the corner.
For a grid puzzle specifically, this means the grid sits high and the input palette sits low, close to the thumb, even though the visual balance of a centred grid is nicer. Reachability wins.
And make the targets bigger than they look
Apple's guidance has long put the minimum comfortable tap target around 44 points square. Grid cells frequently end up smaller than that on a 9×9 board. The fix isn't to enlarge the cells — it's to enlarge the hit area independently of the drawn cell, so the visual design stays tight while the touch target is forgiving. Same for small icons: draw at 24, hit at 44.
Undo is a design tool, not a convenience
Unlimited, instant, free undo changes how players engage with a puzzle. When mistakes are cheap, people experiment; when they're expensive, people freeze or look up the answer. Experimentation is where the fun of a logic puzzle lives, so anything that taxes it is taxing the game itself.
This is also why monetising undo is such a bad trade in a puzzle game. It converts, and it converts by making the core experience worse for everyone who doesn't pay — you're charging for permission to enjoy the mechanic. Charge for content, cosmetics, or ad removal instead.
The related pattern: make destructive actions confirmable but not annoying. "Clear board" needs a confirmation. Placing a wrong colour does not — that's what undo is for.
Never let the player wonder what just happened
Every state change gets a visible cause. A cell that turns red should turn red from the tap, with motion connecting the two. A level that unlocks should visibly unlock, on screen, while the player is watching — not appear already unlocked when they next open the menu.
The specific failure to hunt for: silent rejection. A tap that is invalid and produces nothing is indistinguishable from a bug. Give it a small shake, a dimmed flash, a short haptic — anything that says "I heard you, and no."
Haptics deserve a mention here because they're underused and cheap. A light tap on placement, a sharper one on error, a distinct one on completion. Players who play with sound off — which on mobile is most of them, most of the time — get almost all their feedback from motion and haptics.
Assume every session is interrupted
Someone will call. The app will be backgrounded mid-move. The phone will die. Design as if this happens every session, because it roughly does.
- Save on every meaningful state change, not on a timer and not on quit.
- Restore exactly — same puzzle, same progress, same selected colour, same scroll position.
- Never show a "resume?" dialog. Just resume. If they wanted a new puzzle they'll go get one.
- Pause timers on background, obviously, but also decide what happens to a timed challenge and tell the player before they start one.
Getting this right is invisible when it works and generates one-star reviews when it doesn't. It's the highest ratio of "player never notices" to "player is furious" in mobile.
Teach by doing, in the smallest possible dose
Nobody reads the tutorial. They tap through it to get to the game, and then don't know how to play, and then leave.
What works better:
- Name the familiar thing first. One sentence: this is sudoku with colours. If your game is a variant of something known, saying so is worth more than any interactive tutorial.
- First puzzle is the tutorial. A trivially easy real puzzle that can only be solved one way teaches the rule through the solving, and the player ends with a win rather than a lecture.
- Introduce one mechanic at a time, at the moment it first matters, not all at the start.
- Always skippable, and track what skippers do. If they retain better than completers, your tutorial is a tax.
Settings that respect the player
A small set of settings, all of which persist, none of which are buried:
- Sound and haptics, separately. People who want silence often still want haptics.
- Accessibility options in the main settings, not in a submenu called "accessibility". Options for symbols, patterns or numerals in a colour puzzle are gameplay options — treat them as such and more people will find them.
- Respect system settings. Reduce motion, larger text, dark mode. If the OS says the user wants less animation, honour it.
- A visible way to reset progress, with a confirmation. People hand phones to their kids.
Ask for things at the right moment
Rating prompts, notification permission and review requests all follow the same rule: ask after a success, never at launch, and never twice.
A player who has just completed their fifth puzzle is in the best mood they will ever be in about your game. That's the moment. Launch — before they've experienced anything — is the worst possible time, and a permission denied then is denied for good.
The one-line summary
Most of this reduces to a single instruction: make the game forgiving. Forgiving of thumbs, of mistakes, of interruptions, of players who didn't read anything. Puzzle players want to be challenged by the puzzle and by nothing else in the app.