David Sirlin has great GDC notes up. Particularly:
Jaime Griesemer made a point yesterday that when gets feedback, he doesn’t like hearing solutions, just problems. He’s ok with “I don’t like this” and he’s even better with “I don’t like this because [of X]” but he’s not hot on “this should be changed to that.” Often these solutions are not feasible. Sometimes they have technical problems, sometimes they cause other even worse problems in some other area of the game, or whatever. He says don’t discuss solutions with playtesters, do that with other designers.
GOOD GOD YES. Three quarters of time I have responding to feedback is trying to turn “this should be changed to that” into “I don’t like this” and almost always I think the person I’m conversing with is thinking I am just mining for a way to ignore the comment. There are dozens of ways to solve most problems in design. Your solution is probably pretty good, but unless I know the underlying problem you are trying to solve, I can’t find that one that merges so beautifully with that system or dynamic that you just don’t know about yet.
I think people make the assumption internally that if they don’t offer up a solution that they will seem dumb, especially if the solution is clear. Not so. It’s my job to understand how the systems of the game work. If you think there is a problem with one, tell me, but don’t tell me how to fix it as I am likely the one most qualified as I know the systems the best. It’s not an ego thing, but a specialization thing.
I try my best when artists show me things to respond in the same way. I try not to say “make this darker”. Instead I try to say, “that’s hard to read” or “that might obstruct this other thing”. I say “try” because it is so damn easy to fall back on doing the thinking for someone else.


