Problems and Solutions

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.

2 Comments

  1. I love this point. As someone who has walked in the shoes of Tester, Lead Artist and Designer, I’ve found myself guilty of this on each level.

    My solution when I was playtesting was to outline the problem in as detailed a way as possible and then if I had a proposed solution, I would place it in a “spoiler div” that the designers could easily ignore.

    Humility (and knowing your role) is very helpful as any cog in a creative machine.

    Also: Love your blog. I’m a new subscriber.

  2. David Schwartz

    May 10, 2010 at 4:32 am

    The people who most need to heed this advice are folks who interact with testers and pass their reports on to developers. It seems odd, but developers need problems, not solutions.

    I think a big part of the solution is to have a submission form that asks very specifically for a description of the problem, how to replicate it (if it is repeatable), the actual results, the expected/preferred results, and a suggested fix area that’s clearly marked “optional”.

    This allows people to speculate if they feel they need to. But it also makes it clear that they aren’t expected to suggest solutions.

Leave a Reply

Your email address will not be published.

*

Human? * Time limit is exhausted. Please reload the CAPTCHA.

© 2016 Zack Hiwiller

Theme by Anders NorénUp ↑