Why Developers Quietly Hate Vague Designers
One of the biggest frustrations developers experience in game teams is vague design feedback.
Programmers usually approach problems with logic, systems, and measurable parameters. When they receive feedback that lacks clarity, it becomes extremely difficult to translate that feedback into actual implementation.
Unfortunately, many developers have encountered situations where the designer gives feedback like:
- “It just doesn’t feel fun.”
- “Something about the combat feels wrong.”
- “This animation looks stupid.”
- “Make the gameplay smoother.”
- “Can you make it more exciting?”
These comments might express genuine concerns, but they are not actionable instructions.
From the developer’s perspective, this creates a difficult situation.
They now have to guess what the designer actually wants.
The Problem With “Feel-Based” Feedback
Game design often involves emotions and player experience. Designers naturally evaluate things based on how the game feels.
However, developers work with specific systems and variables, such as:
- animation frames
- cooldown values
- hit detection
- physics parameters
- timing windows
- input buffering
When feedback stays at the level of feelings instead of mechanics, programmers are forced to interpret those feelings themselves.
This can lead to several problems:
1. Endless Iterations
If developers guess incorrectly, the designer might respond with:
“No… it still doesn’t feel right.”
So the developer changes something again.
Then again.
And again.
What could have been solved in one clear instruction becomes five or six iteration cycles.
2. Hidden Design Decisions
Sometimes developers accidentally become unofficial game designers.
Because the instructions are unclear, they start adjusting:
- attack speed
- damage numbers
- animation timing
- enemy reactions
They are effectively making design decisions without realizing it.
This can cause the game’s design to drift away from the original vision.
3. Developer Frustration
Developers usually enjoy solving clear problems.
For example:
These instructions provide a clear target.
But vague requests like:
❌ “Make the combat feel cooler.”
Leave developers stuck in guessing mode.
Over time, this leads to frustration.
Developers may begin to feel that the designer does not fully understand their own system.
The Communication Gap
This tension is rarely caused by bad intentions.
It usually happens because designers and programmers think in different languages.
Designers think in terms of:
- emotions
- player experience
- pacing
- immersion
Developers think in terms of:
- systems
- parameters
- logic
- implementation
A great designer learns how to translate experience into systems.
For example, instead of saying:
❌ “The attack feels weak.”
A better explanation might be:
Now the developer has clear directions to implement improvements.
The Designer’s Hidden Superpower: Clarity
The best game designers are not just idea generators.
They are translators between creativity and implementation.
Their real skill is turning abstract ideas like:
- “powerful”
- “satisfying”
- “fast”
- “dangerous”
Into concrete instructions like:
- shorter attack windup
- stronger hit reaction
- louder sound effect
- larger particle burst
- brief hit pause
When designers reach this level of clarity, developers can implement features quickly and accurately.
Respect Goes Both Ways
Interestingly, developers tend to respect designers who communicate clearly.
When a designer provides:
- clear mechanics
- defined goals
- measurable values
- good references
Developers feel confident implementing the system.
Instead of guessing what the designer wants, they can focus on building the best technical solution.
This creates a smoother development process and a healthier team dynamic.
The Simple Rule
A good rule for designers is this:
If developers have to guess what you mean, your design is not clear enough yet.
The goal is not to remove creativity or experimentation.
The goal is to ensure that everyone on the team understands what needs to be built.
Because in game development, the difference between a frustrating workflow and a productive one often comes down to how clearly ideas are communicated.
Final Thought
A game designer doesn’t need to know every technical detail, but they must be able to describe the experience clearly enough for the team to build it.
A game designer also need to avoid the larger misconception in game teams:
"When Game Designers Expect Everyone to Be a Designer"
When designers learn how to convert instincts into actionable feedback, collaboration between designers, programmers, and artists becomes dramatically smoother.
And the game improves faster as a result.
Comments