Mobile game development / DIJION
Designing controls for one-handed mobile games
A mobile control test plan covering grip, touch areas, accidental input and visual occlusion together.
A game with one-tap input is not automatically comfortable to play with one hand. Balancing the phone, reaching a moving target and seeing around a finger are separate tasks. Begin by writing down which decision the player makes with each movement, rather than drawing buttons first.
Map an action to a movement
In an illustrative avoidance game, a tap might switch lanes while a drag positions the character directly. When comparing the two in a prototype, hold speed, obstacle layout and feedback constant. Otherwise it becomes difficult to tell whether the control or the level change produced the difference.
Do not rely on one universal thumb map
Hands, phones, cases and grips vary. Observe access to important areas on real devices with left- and right-handed use. Instead of declaring a universally comfortable screen region, record grip shifts, repositioning and the play area hidden by the hand.
Scroll the table horizontally to see all columns.
| Condition | Problem to observe | Adjustment to try |
|---|---|---|
| Left-handed grip | Repositioning to reach the main action | An option to move the control |
| Finger over the target | The outcome is obscured | Place feedback in an unobstructed area |
| Rapid repeated input | An unintended second action | Clarify input acceptance rules |
| Near a system gesture | System navigation replaces game input | Reconsider control placement |
Separate decision errors from input errors
Seeing danger and choosing badly differs from making the intended movement without it registering. Record intention, movement and the game’s response separately. Treating every failure as a difficulty issue can hide a control defect.
Consider a simpler alternative when holding, repeated tapping or precise timing is unnecessary to the mechanic. Game Accessibility Guidelines discusses control simplicity and adequate spacing; the suitable adaptation depends on the game. An alternative input path should work in menus too.
Keep feedback observable
Show a small visual response when input is registered and distinguish that acknowledgement from successful execution. Sound and vibration can supplement it. With sound disabled, the player should still understand whether the control was received and what happened in the game.
Move beyond the first short attempt
- Observe initial use without verbally explaining the controls.
- Compare the same layout across hand preferences and screen sizes.
- After sustained play, ask about grip changes and discomfort.
- Verify that pause and settings remain reachable with the gameplay input method.
The outcome is a record of which movement caused trouble under which conditions, rather than a universal best-control verdict. This example plan does not report tests of a Dijion product.