# Make your game readable on a phone

BerryBlox creator resources
Edition 1.0 · November 4, 2026

Check the real player view, safe areas, touch behavior, long labels, and recovery states.

Take away: A focused UI review with reproducible issues.
Beginner · 7 min read

Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms.

Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox.

## Record 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](https://create.roblox.com/docs/studio/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](https://create.roblox.com/docs/ui/on-screen-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.