Work backward from the present decision
game-art-direction separates persistent, scene-specific and on-demand information. Function matters more than length. A short irrelevant note can move; evidence essential to a choice must be available when needed.
Original game: a harbor dispatcher decides whether a late cargo ship can unload tonight. Relevant facts are warehouse capacity, refrigerated medicine and worker availability. The main view focuses on the dock, request and arrangements, not every voyage, relationship and weather record.
Write the current question in one sentence: unload tonight or wait until morning? Connect each visible element to it. Information without a current role can remain accessible on demand rather than occupying the screen simply because it is a real state.
Give each information layer a reason to appear
| Layer | Content and presentation |
|---|---|
| Persistent | Content: Tonight, current dock, warehouse closing Presentation: Brief orientation and deadline |
| Current scene | Content: Cold-storage needs, capacity, overtime request Presentation: Beside the relevant arrangement |
| On demand | Content: Old rotas, voyage history, relationship records Presentation: A recognizable archive entry |
If an earlier promise makes workers refuse overtime, bring its relevant sentence beside the request. Do not expect players to infer the condition from a long history. Keep the full record accessible too.
Options state their distinct action and cost without repeating global rules. Show responses and actual results after selection rather than displaying every distant ending in advance.
Complete Paper Example: An Overtime Request Is Not Unloading
Make the harbor case a complete original design route. The example distinguishes requests from actual results; it is not a working interface or a completed target-viewport test.
It is 20:40; cold storage closes at 21:00 and has room for exactly two medicine crates. Both crates remain aboard. The captain supplied evidence that onboard refrigeration lasts until 09:00 tomorrow; cold storage reopens at 08:00. This makes waiting viable rather than leaving medicine outdoors. The current shift has ended, so unloading needs voluntary overtime. Reading and sending the request do not advance this example’s clock. The crew agrees at 20:40 on the normal route, after which the defined job takes ten minutes; consent alone does not perform it.
| Beat | Input and outcome |
|---|---|
| Enter | Focus on “Late cargo: unload tonight or tomorrow?” with 20:40 and closing time. Beside the choice: two crates, two cold-storage spaces, onboard refrigeration until 09:00, morning opening at 08:00, and the ended shift. |
| Choose | “Request overtime to unload both tonight” or “Schedule morning unloading; keep them refrigerated aboard tonight.” The first needs consent; the second leaves the crates aboard. |
| Send request | “Request sent to the current crew; awaiting response.” Both crates remain aboard and both warehouse spaces remain free. No completed-unloading signal. |
| Normal response | In a history without a conflicting promise, the crew says, “We agree. We’ll unload these two medicine crates first.” Record consent and begin execution; consent has not moved cargo. |
| Actual completion | At 20:50 both crates enter cold storage. Free spaces change from 2 to 0; this medicine aboard changes from 2 to 0. Show “Two medicine crates stored” and the next action, without declaring all ship cargo unloaded. |
| Refusal in another history | A verified earlier promise of no more overtime tonight appears beside the request. The crew refuses; crates remain aboard and free spaces remain 2. Morning scheduling is available, with refrigeration evidence accessible again. |
Selecting morning on the refusal route commits a schedule, not tonight’s storage. Recheck then-current space, staff, and refrigeration when morning unloading actually happens. Completed unloading on the normal route does not establish consent to unlimited future overtime.
Keep the full rota and promise in the archive, but display the sentence affecting this request where it matters. Present the actual crew reply after its response rather than listing every history’s answer beforehand. Returning to the choice retains checked capacity and refrigeration evidence. Text and quantities support icons and colors; a green dot alone cannot establish safe storage.
After implementation, read and operate the screen in its target viewport and check that current prose, choices, and essential feedback remain readable together. A paper organization does not establish that these sentences fit on a phone.
Split information beats before adding scrolling
An overloaded screen includes the captain’s letter, warehouse explanation, old disputes, every resource, long options and an outcome summary. By the buttons, the present question is lost. Instead establish arrival and conditions, allow evidence inspection, then offer arrangements. Present results afterward.
If essential choices require scrolling, check for archives and repeated explanation. Hiding the scrollbar or shrinking all text does not solve overload. An explicitly opened history page can scroll with a clear boundary and return route.
Splitting screens must preserve causality. Keep relevant inspected evidence available beside the decision. Judge line length and interaction in the target viewport, not solely in a layout document.
Check what a cleaner interface removes
Read a normal and a refusal path. Can players see costs before choosing, identify which option an earlier promise affects, and distinguish an accepted request from completed unloading?
A decorative map without capacity prevents judgment. Showing every internal relationship score crowds out actual conditions. Return to the present question instead of imposing a fixed information count.
Icons and colors need understandable supporting expression. A focused cleanup moves or compresses identified information while preserving rules, option meanings and history. If rules must change to make the screen work, that is a separate design change. This example is not a completed usability test.
FAQ
Will an archive hide essential evidence?
It can. Keep evidence essential to the present decision near its option, while allowing the full source record to open on demand. Do not move everything into a menu.
Do it with the skill
Use game-art-direction to simplify this story-game screen. Identify the present decision, classify persistent, scene and archive information, and preserve its evidence. Remove duplication or split beats without changing rules.
Read the method: Interface information hierarchy · Information before decisions