Workshop feedback notes: turn a reaction into a testable observation
Translate a reaction into a question you can actually inspect. Valve says Workshop voting has limitations and is not the sole selection criterion. For an original striped-orbit design, a remark such as “too busy” becomes useful only after you identify where the crowding appears, under what viewing context and which single revision could test the explanation.
CASECS2Updated:
Build a hypothetical feedback matrix
Example reaction
Observation to clarify
Small test
Too busy
Which stripe group competes with the orbit?
Simplify that group
Hard to recognise
Which part of the orbit disappears?
Restore one shape relationship
Prefer the other colour
What reading changed?
Compare palettes with layout fixed
These are invented teaching examples, not collected comments or actual votes. Keep the original wording beside your interpretation so that a useful question does not become falsely attributed to another person.
A check diagram, not a game screen.
Ask for the missing location
Start by identifying the relevant area and view. “The upper stripe cluster dominates in the player view” is more useful than “the design is bad.” If a comment has no location, do not invent one on the commenter’s behalf.
You can inspect your own design for possible explanations and label them as your hypotheses. The in-hand composition guide helps frame a player-view question. Another view may reveal a different issue, so preserve the original context rather than generalising immediately.
Separate preference from a reading problem
A person may simply prefer a calmer palette. That preference can be recorded without claiming the current design is unreadable. Conversely, a visible interruption in the main orbit can be described even by someone who likes the palette.
Use the salience and contrast questions to name the reading problem: first attention goes to a stripe rather than the intended orbit. Keep subjective preference and identifiable visual relationships in different columns of your notes.
Turn the proposed fix into a hypothesis
If the suggestion is to remove stripes, write what that is expected to improve. Then prepare one version that changes only the relevant stripe group. A suggestion is not automatically correct just because it sounds confident or appears several times.
Review the same area and view after the change. The lighting comparison helps keep a different observation environment from masquerading as design improvement. Record both the intended benefit and any new problem introduced by the edit.
Keep disagreement specific
Two observations can be useful without producing one universal verdict. One reader may value a clear orbit while another enjoys the busy stripe rhythm. Return to your own design intention and decide which relationship the next revision should prioritise.
The albedo and lighting explanation can clarify whether people are discussing drawn colour or a particular image impression. Avoid turning a small set of reactions into claims about all players, demand, prices or the likelihood of official selection.
Close the loop with a visible decision
For each note, record whether you tested it, retained the current design or still lack enough context. Give one reason. A completed note might say that reducing upper stripes clarified the orbit but weakened the intended rhythm, so a narrower reduction will be tried next.
The submission and selection guide provides broader context. Your preview does not change inventory and your feedback sheet is not an approval. Its outcome is a traceable creative decision, without invented voting data or an implied agreement from people you have not contacted.
