When a Design Feels Off
What to do when a teammate is sure your design is wrong but can't tell you why.
"It just wouldn't work." That's what a colleague kept telling me about a design I was working on, and the more I asked why, the firmer the answer got. I was trying to understand what they were seeing, but every question seemed to push them further into the same sentence. At first that felt bad, and part of me assumed I must have done something wrong to get a reaction that strong.
The design itself was a change to how part of the game played. Nearly everyone had settled into the same safe way of playing it, which was efficient and also pretty boring, so I wanted to give players a reason to take more risks and try something different. I had a clear reason for the change, and my colleague was just as clear that it wouldn't work, but couldn't tell me why.
Eventually I shook that off and focused on what I could actually do. "It just won't work" wasn't something I could act on, because there was nothing in it I could fix or test, and I needed something actionable to make a decision. So I set out to figure out what it meant, and whether I could solve it without sinking a ton of time into it.
Building it anyway
I kept building. The prototype came together, the core mechanic was really nice and the team liked it, but people kept saying the same thing about it, which was that something just felt off. At first, nobody could say what.
Picture a slow, heavy attack that gets reworked into a fast combo, but the sound and the screen shake are still tuned for one big hit. That example's made up, but the problem is the same kind. What do you think a playtester says after trying that combo?
In our case it took several iterations to pin down. Pretty much everything the player saw and heard around the new mechanic still described the old one, so the game was promising one thing while the mechanic did another, and that's where the friction and confusion came from.
Somewhere in the middle of that, I went back to my colleague with the specific problems I'd found and asked for ideas. It turned into a loop about whether they'd been right all along, which, to be fair, they kind of had.
We kept iterating anyway, matching the feedback to what the mechanic actually did, one piece at a time, and playtesters started enjoying it too. We improved the feel as much as we could, but it never reached the best feel it could have had, and we chose that on purpose, because the variety it added to the game was worth more.
The testers said it too
Looking back, my playtesters were telling me the same thing my colleague had been telling me from the start, just in different words. My colleague was right. Something was off, and neither of us knew what it was yet.
The only real difference was how sure each version sounded. My colleague's came as a verdict, "it just won't work," and the testers' came as an observation, "something feels off," so I treated the first as a dead end and the second as something to dig into.
Okay, but doesn't that mean I should've just listened in the first place? If I'd shelved the change, we'd have lost a mechanic people ended up enjoying, and if I'd waved the feeling away, we'd have shipped every bit of that friction, so neither of us had the whole answer.
It's the same thing your playtester would say about that made-up combo: it feels off. They'd be right, and they'd have no idea why. A teammate's gut can work the same way, picking up on a problem before it can put a name to it.
So a feeling about a design isn't a verdict. It's a clue that something real is going on, and the work is figuring out what.
Turning a no into something you can test
One thing I'd do differently is how I asked. Every "why" asked my colleague to defend a feeling they couldn't put into words yet, and the only way to defend it was to say it more firmly, which is about what happened. If I could redo that conversation, I'd ask questions a gut feeling can actually answer, like "what would the player notice first?" or "what would you need to see to change your mind?"
We were at the same level, so neither of us could just make the call, and in the end the prototype made it for us. That's the part I'd keep. When a debate stalls, build the cheapest version that answers it and let the playtest decide, because a playtest doesn't care which of you sounded more sure.
Once you know what a feeling is about, you can do something with it, and that includes deciding not to fix all of it. You can weigh what fixing it would cost against what you'd get, which is the call we made when we gave up some feel for variety. That's a decision a team can actually make, instead of a standoff between two people who are each certain.
I'd still take that kind of opinion seriously, because this one turned out to be right. I just wouldn't make the call on it alone, since the why is what opens up a conversation about how to move forward. And if nobody can say why yet, the next step is to go find out, ideally together this time.
When I'm running the room
I still find it hard when the most certain voice in a discussion starts steering it, whether or not it has the best case. Between two people it can stall a design, and in a bigger group it can quiet the people who'd otherwise speak up.
When I'm running that kind of discussion, I use two rules. I go around the room so everyone gives their take once before the debate starts, with the most senior person going last so nobody anchors on them. And afterward, I find whoever stayed quiet and ask them one to one, because staying quiet doesn't mean they had nothing to say.
There's research behind the first rule. In a 2010 study, Woolley and colleagues found that groups whose members took turns more evenly scored higher on a measure of collective intelligence, while the members' average and top IQ weren't strong predictors of it.
None of this guarantees a happy ending. Sometimes the prototype tells you the design is dead after all, and that's still a good outcome, because you found out for the price of a prototype instead of a long standoff.
It didn't go smoothly with my colleague, either. For a while we drifted apart, and what helped was working out why. Their objection came from design rules they hold firmly, and from where they stood my change broke one of them, so every push on the design felt like a push against the rule itself. They were right about that, too, since the feel never did reach its best. In later discussions like that one, I started by saying where they were right and then talked about the trade-off we were making, so it was clear I wasn't arguing against their rules or what they believed.
But if I'd given in to a no that came without a reason, I'd have lost a design a lot of people really enjoyed.
So the next time someone tells you a design just won't work, try not to argue it out or fold. Ask what the player would notice first, then go build the cheapest thing that answers it.