Identify the rule color is carrying
Color can strengthen focus and mood, yet it may quietly become the only carrier of information. On each screen ask: what judgment must the player make, what does each color mean, and could they complete the same choice if color disappeared?
| Where color appears | Rule to trace |
|---|---|
| Quest-card border | Available, missing a condition, or complete |
| Choice text | Available, locked, or already chosen |
| Portrait halo | Current speaker, willing respondent, or departed character |
| Map marker | Place type, risk, or current objective |
| Result flash | Action committed, refused, or still pending |
Settle the real state before designing its presentation. Color, label and icon all read that same state; none of them may independently turn “awaiting confirmation” into “complete.”
Pair critical information with a non-color cue
Redundancy does not require dense text everywhere. Choose the shortest second channel that fits the information's job:
| State | Readable second channel |
|---|---|
| Available | Verb label, solid dot and normal focus order |
| Missing a condition | Lock shape or dashed border plus one line stating what is missing |
| Complete | Check mark and completion label while retaining access to the actual result |
| Current objective | Map position, objective name and directional cue |
| Warning | Pattern or outline change plus the specific risk |
Shape, position or wording should remain identifiable in a dark presentation, a low-motion mode and an ordinary screenshot. Sound may reinforce feedback, while critical information remains visible on a muted path.
Complete original example: which oral-history reel can be delivered
The following is a paper interface and path design. No screenshot was generated and no program was run. In the fictional interactive story *Afternoon Sound Archive*, the player organizes three oral-history reels for a community archive. The first interface uses dot color alone: green means a copy is ready to deliver, yellow means awaiting permission, and red means internal preservation only. Cards have no labels or shape differences, so a player who cannot distinguish the colors lacks the rule information needed to choose.
The revised cards are:
| Reel | Multiple expressions of the same state |
|---|---|
| A, “A Day at the Shoe Stall” | Solid dot; label “Copy ready to deliver”; button “Send copy to exhibit” |
| B, “Choir Under the Bridge” | Dashed border and hourglass; label “Awaiting contributor reply”; locked action with “Current public permission missing” |
| C, “Old Pier Meeting” | Square archive stamp; label “Internal preservation only”; no public-delivery action, with “View preservation note” retained |
The complete path is: the player opens B, sees that a contributor has not replied, and returns to the list. They select A and receive, “The exhibit received a copy of A; the original remains in the archive.” The list changes A to a check mark and “Copy delivered.” C remains internal.
Color may remain as visual reinforcement, but labels, outlines and actions now carry the judgment on their own. A's result also separates delivery of a copy from movement of the original; a green flash cannot collapse those facts.
Walk a counter-path as well: repeated attempts on B cannot turn it into “ready” when an animation ends. Returning from A's result cannot reset B and C together. This example illustrates how to check the rule-and-presentation handoff on paper. The real candidate still needs actual input checks in its target viewport.
Check action, basis and result in the target viewport
After integration into a real candidate, walk one complete path from a clean initial state:
- Read only player-visible information, without source code or hidden state.
- Find the current action and state the basis for choosing it.
- Choose one item and observe input feedback and the actual result.
- Return to the list and confirm that complete, waiting and internal states remain distinct.
- Enable the project's existing dark, low-motion or muted state and repeat the critical step.
- In the reading and input modes the project actually supports, inspect obstruction, clipping, focus and activation in the target viewport.
Record what was seen, what was done and what resulted. A colorful screenshot proves only that one frame exists; it cannot prove real input, committed state and the returned list all behave correctly.
Common wrong repairs and better fixes
| Wrong repair | Better fix |
|---|---|
| Make green brighter | Add a label, shape or position cue while brightness continues to serve focus |
| Add a paragraph to every state | Use a short state label plus on-demand detail, keeping the current action clear |
| Let icon and text calculate state separately | Make both read the same committed result so one cannot say complete while the other says waiting |
| Show a lock only through grey color | State the missing condition and keep available actions discoverable |
| Declare success from a screenshot | Use real input, reach a result, return and inspect persistent state |
If added cues crowd a phone viewport, repair hierarchy, wrapping and card layout first. Do not shrink all text again merely to create space.
FAQ
Is adding an icon always enough?
No. The icon must be identifiable and map to a clear state. Tiny similar icons, abstract symbols without labels, or explanations available only on hover can still force guessing. Check the actual target viewport and input mode.
Can the game keep red, yellow and green?
Yes. Color can reinforce hierarchy and mood as long as critical conditions, actions and results have a non-color expression and every cue reads the same game state.
Do it with the skill
Use $game-art-direction to inspect information conveyed only by color. List the current action, necessary basis and result; add label, shape, pattern or position redundancy to critical states; keep every cue tied to the same committed state; then hand the target viewport to an actual-input check.
Read the method: Non-color redundancy, low-motion expression and target-viewport requirements · Functional state, readable boundaries and in-game checks · Player-visible assertions and target-viewport paths