Overview
A breakdown of 6 UI/UX lessons learned while developing ZINTOROAD — from fixing broken button interactions to repositioning HUD elements based on where players actually look.
Excerpting my own article from the jack blog.
Hey there, I’m norinori1, jack’s ghost.
Today I’d like to share some of my own UI/UX design techniques and advice for game development, based on my experience developing “ZINTOROAD,” a game I brought to beta this year.
For more about “ZINTOROAD,” check here (I entered it into “Game Creator Koshien”) ↓
ZINTOROAD (Minna no Game Parade)
You might get a better understanding by viewing the “Work Introduction PDF” from there.
From here, I’ll talk about the improvements I made based on alpha and beta survey results for ZINTOROAD, and the UI/UX techniques I learned from them.
First, let me express my gratitude to everyone who played the ZINTOROAD alpha and beta versions, and to everyone who participated in the surveys.
(a) Title Screen
Alpha version → Beta version
In the alpha version, the game would only advance to the next scene by holding down Z — clicking “▶ Start” with the mouse actually did nothing.
(This happened due to a misconfiguration in Unity’s PlayerPrefs. Even with a button component on the Start button, it wouldn’t respond. For anyone hitting this in Unity 6.0: fix it by setting the UI action map in EventSystem’s “Action Asset” — copy the UI map from the default InputSystem_Actions.)
This was flagged by quite a few survey respondents, so I updated it so clicking the start UI also starts the game.
Takeaway: UI should match the behavior users naturally expect.
Also in the beta: pressing [Esc] on the title screen now shows a confirmation dialog with an “Exit” button. Always give players a way to quit from within the game itself.
(b) Play Screen
Alpha version → Beta version
Feedback from surveys and friends on the alpha:
- “Why is Pause mapped to ‘C’? (Shouldn’t it be ‘Esc’?)”
- “Clicking the Pause UI doesn’t do anything”
- “There’s an HP bar in the bottom-right but I never look there during gameplay”
- “I can’t tell how many anchors are on the board” Points 1 and 2 come back to the same principle from (a): follow control conventions players already know from other games.
(Pause ended up on ‘C’ because two scripts were handling key input simultaneously and ‘Esc’ caused conflicts. Fixed in beta.)
For point 3: I discovered that during gameplay, players’ eyes stay near the object they’re controlling. The bottom-right HP gauge was basically invisible to them — they’d take damage without noticing and suddenly hit Game Over.
Fix: moved the HP gauge and AP gauge (as a percentage of max) to the center of the screen. Players can now register damage immediately from the visual.
Point 4 was similar. The game has a “Destroyer” enemy that specifically targets anchors — so anchors can disappear without warning, leaving players confused why their triangle preview disappeared.
Fix: added a UI indicator next to the anchor placement display showing how many anchors on the board can currently form a triangle.
Takeaway: Show all information that matters to the player, and position the most critical elements where their eyes actually go.
(c) Boost Selection Screen
Alpha version → Beta version
After defeating enough enemies, the game levels you up and lets you pick a “boost” — a special ability (think the level-up screen in Vampire Survivors).
In the alpha, selecting a boost required holding down Z. Survey respondents found this confusing.
(Happened because I lazily reused the anchor-placement code.)
In the beta: single press of Z, plus mouse click support added.
On fonts: the alpha used a blocky, angular typeface called “Makinas” to match the game’s aesthetic. Surveys said it was hard to read, so I switched to “Smart Font UI.”
Takeaway: For any UI that explains or instructs, legibility beats style.
Third issue: the ◀▶ arrows in the input guide UI (bottom-left “Select” / “Determine” indicators) looked like they applied to both labels, which confused players. I fixed this by boxing each operation’s controls separately.
Takeaway: Enclose or clearly space UI groups so it’s unambiguous what belongs to what.
(d) Summary
- Align controls with conventions from other games; make UI behavior match what it implies
- Provide a way to quit from within the game
- Ensure UI communicates all information the player needs
- Place critical UI where the player’s eyes actually go
- Use legible fonts for any explanatory text
- Enclose control groups so there’s no ambiguity about what applies to what ### Closing
Thanks for reading!
If you’d like, I’d love it if you hit the “Cheer for this!” button on Minna no Game Parade:
ZINTOROAD (Minna no Game Parade)
See you next time!
This article was automatically cross-posted from norinori1's portfolio
Top comments (0)