Appearance
16 · UI / UX
Status: Skeleton · Owner: TBD · Updated: 2026-09-23
Purpose
Define screen flow, information architecture, and the onboarding that decides whether anyone stays past day one.
To define
Think about
- The genre's UX default is a screen buried in red dots and floating sale icons. It converts, and it is also why people describe these games as exhausting. Decide deliberately how much clutter you accept; a clean version of this game is a real differentiator, and a real revenue risk. Pick knowingly.
- The first 5 minutes decide the install. Most of this genre opens with a scripted attack, a rescue and a rebuild — it works because it gives emotional stakes before it gives systems. Your premise supports something stronger: the player arrives at the ruin of their own dynasty and lays the first stone.
- Do not teach the whole game. Teach one loop, then let events and the alliance teach the rest over the first week. Front-loaded tutorials are where new players are lost.
- The return summary is a core screen, not a courtesy. Players are away for 8–12 hours. What happened while they slept — attacks, help given, completed builds, alliance events — should be one readable screen, not eight popups.
- Alliance chat is the most-used screen in the game and usually the worst designed. Treat it as a first-class feature: translation, pins, rally links, readable at a glance.
- Design for one hand on a large phone. Primary actions belong in the bottom third. This genre's players play in bed, on transit, at work.
- Notification policy is a retention lever and a churn lever simultaneously. "Your city is under attack" must arrive; "A new bundle is available" thrice daily gets your notifications disabled entirely — and then the attack alert never arrives either.
Open questions
| # | Question | Blocks | Owner |
|---|---|---|---|
| 1 | How aggressive is store/offer surfacing? | Monetisation, retention | |
| 2 | Is the tutorial skippable? | Onboarding metrics | |
| 3 | Portrait, landscape, or both? | Art, UI, all screens |