Make your game readable on a phone
Check the real player view, safe areas, touch behavior, long labels, and recovery states.
A focused UI review with reproducible issues.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
A basket prompt that survives a narrow screen
- View to inspect
- Use Orchard Delivery at the spawn and basket, in a narrow portrait preview and landscape preview. Record the actual viewport, input mode, and build revision when testing.
- Illustrative issue
- The delivery button and its count occupy the same corner as the touch movement control. A player may move when trying to deliver.
- Proposed change
- Move the delivery action into a clear area above the movement controls, keep the fruit count beside it, and allow the instruction to wrap.
- Check to run
- Approach with two fruit, read the missing-fruit message, move away, then return with all three. Repeat in each orientation and with longer instruction text.
- Evidence still needed
- Save before and after captures of the same route and test touch input on a real device. A Studio preview alone does not establish device usability.
Expected resultOne reproducible UI issue and a clear retest route, with preview and real-device evidence kept separate.
Try it in your blank worksheetRecord the view you are testing
Start at the normal spawn and navigate using the intended controls. Record the build, screen size, orientation, graphics setting, and test mode. Use at least a small phone layout and a larger layout; retain the same route for comparisons.
Studio's Device Simulator previews screen dimensions, input, and device characteristics. It is documented as a beta, so controls may differ by Studio version. Simulation helps locate problems; repeat the route on a real phone before claiming physical-device usability.
- Build / date / reviewer
- Studio version and test mode
- Device or simulator profile / orientation
- Route from spawn to the feature
Source checked November 4, 2026: Roblox: Device Simulator.
Keep the important controls reachable
Check interactive ScreenGui content against screen insets. Roblox recommends CoreUISafeInsets for interactive UI, keeping it away from top-bar controls and device cutouts. Check the visible result as well as the property; nested scale and layout can change the actual target size.
- The main action, close control, and current objective remain inside usable screen space.
- Movement, camera, jump, and game controls do not compete for the same touch area.
- Long labels, large values, and translated text fit without hiding the cost or action.
- Open menus do not leave hidden controls active underneath them.
- Critical status is communicated with text or shape as well as color.
Source checked November 4, 2026: Roblox: On-screen UI containers.
Exercise input and recovery
Use normal player input, not a script that directly invokes button callbacks. For a held action, test leaving its hit area and cancellation during a menu, focus change, or respawn. Confirm the character can still move and the camera remains controllable.
- Tap, hold, release, and repeated input produce one intended action each.
- Cancel, close, and back controls return to a usable game state.
- Loading, full inventory, insufficient resources, and refused actions have readable feedback.
- Returning after respawn or reopening a menu restores the correct state.
- The on-screen keyboard does not hide the current field or completion action.
Capture one issue so another person can fix it
Keep a screenshot or short clip with the build identity and exact steps. Describe the visible problem and its impact before suggesting an implementation. Recheck the same route after the change, including an adjacent state.
Example issue: after opening the shop on the small-phone profile, the close button overlaps the top bar. Expected: the player can dismiss the shop without opening Roblox controls. Status: an illustrative report, not an observed BerryBlox defect.
- Issue title and severity
- Starting state and exact inputs
- Expected result / observed result
- Clip timestamp or screenshot path
- Owner / fix build / retest result
Make a small phone review matrix
Choose three UI states: normal play, the busiest menu, and one refusal. Inspect each in a narrow portrait view and a landscape view. Record the control that is hardest to reach and the label that takes the most room.
After a correction, repeat those same six combinations. A screenshot of one tidy state cannot establish the others. Keep the physical-phone pass separate from the simulated layout review.
- State / orientation / reach problem / text problem / retest evidence
Evidence and limits
This is a source-informed checklist, not a UI asset pack or a Studio test result. A property scan, emulator screenshot, or successful automated click does not prove that the complete interface works comfortably on a physical phone.
Keep simulator and real-device results separate. Mark unavailable tests as not tested, and retain failed cases until they have been retested.