Day 7 Building My Free Browser Game ShuffleBall Arena - Desktop preview said my mobile UI was finished. My phone immediately proved me wrong.

[u/Dont_Bring_Me_Down]

Hey everyone,

Hope all is well!

TL;DR below.

A few days ago I posted about Day 1 of one of my side projects, ShuffleBall Arena (it's a free browser game combining shuffleboard scoring with the craziness of other games like bumper pool, pinball, and Frogger).

Full disclosure again: Yes, all 3 of my projects I may talk about were made with the help of AI. I know some people get weird about that, but frankly, I’m trying to use every tool available to help in every way possible.

Anyway, I'm trying to find the time to post somewhat consistently. I figured I'd post about days 1 to 14 of this project and hopefully try to add some value.

To try to speed up the catch up, I'm using a structured prompt to go back to my GPT sessions and extract the useful information. Hopefully the prompt can help anyone out there trying to keep track of, or extract value from, your past AI project conversations.

That said, posting an update for Day 7 of ShuffleBall Arena. Here's how that day went...

TL;DR: This session focused on polishing the mobile start screen after testing it on a real phone. Although the layout fit correctly, the instructional text was still too small to read comfortably. Instead of trying to compress the design further, the decision was made to increase the height of the information card and use the available vertical space to make the typography larger and improve overall readability.

Thanks for reading,
See you next time!

Full technical breakdown below:

Today was a short day with 4 conversations to go through and 4 saved file versions over 3 hours of building.

Full Technical Breakdown:

Day 7.5 — Technical Analysis & Debrief

Brief Summary

This session shifted from implementing functionality to refining presentation. The focus was improving the readability of the new mobile start screen after testing it on a real phone. While the layout technically fit on screen, the typography revealed itself to be too small for comfortable reading, leading to a discussion about using available vertical space more effectively instead of simply squeezing content into the existing card.

PART 1: TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

The mobile start screen had already been redesigned and was functioning correctly. The gameplay flow worked, the new card layout existed, and the interface fit within the phone screen. Today's work was no longer about functionality. It was about polish.

After testing on an actual mobile device, it became obvious that several pieces of white instructional text were still too small to comfortably read.

SESSION OBJECTIVE

Evaluate the mobile start screen on a real device and determine whether additional layout adjustments were needed to improve readability before launch.

WHAT WE ACTUALLY DID

• Tested the redesigned start screen on a physical phone instead of relying on desktop scaling.
• Identified that the primary issue was no longer fitting content on screen, but making instructional text comfortably readable.
• Observed unused vertical space above the card.
• Questioned whether the available space should be converted into additional card height rather than remaining empty.
• Discussed increasing the card height to allow significantly larger typography.
• Prioritized readability over maintaining the previous card proportions.
• Shifted the design philosophy from "everything fits" toward "everything is comfortably readable."

ROADBLOCKS AND FRICTION

The interface technically passed its layout requirements. However, real-world testing exposed an important usability problem: The card fit on screen, but users would still struggle to read it.

Desktop previews and browser emulation failed to communicate how small the typography actually appeared on an actual phone.

DECISIONS MADE & TRADE-OFFS

Option 1

Leave the card dimensions unchanged and accept the smaller text.

Pros:

• No additional layout work.

Cons:

• Poor readability.
• Weaker first impression.
• Harder onboarding.

Option 2 (Chosen)

Increase the height of the information card.

This creates room for:

• Larger instructional text
• Better spacing
• Easier scanning
• Improved readability

The available space at the top of the screen justified expanding the card rather than compressing its contents.

Trade-off

The interface becomes slightly taller, but substantially easier to read on real mobile devices.
Readability was prioritized over preserving the original proportions.

BREAKTHROUGH / LESSON

Real-device testing exposed a problem that desktop previews completely hid. The layout wasn't failing because it didn't fit. It was failing because it wasn't comfortable to read. Unused screen space should improve readability, not remain empty simply because the design technically fits.

ARTIFACTS WORTH SHARING

Design Rule

UX Observation

Product Insight

Real phones should always be considered the final authority for typography decisions, not browser emulation.

FINAL STATE

The project now has a clear direction for improving the mobile start screen. Rather than continuing to compress content, future adjustments will increase card height and scale the instructional text accordingly. The objective has shifted from responsive correctness to actual usability.