I've seen some very skilled designers. Generally though, they are the ones with a technical background.

Then again, I'd argue that any producer, artist, qa with some coding experience tends to e better to interact with.

I anticipate that people may disagree, but I tend to believe the best approach is to call everyone a 'developer' and let them do what they do best. It's something that works for Valve and for many successful indie teams, and I fully support that.

My personal day job description is 'producer'. I spend about 80% of the time doing 'producer things'. I like it, but its not ideal.

On my hobbyist project, I'm a developer. I do producer, programming, UI and design work (including some of the pixel art such as projectiles, etc.).

I find that its the best way to go along with everybody on the team.

But to your point, I've seen very junior designers and they can be a pain. The issue here is that aspiring 'game developers' are charmed by this position, which results in a lot of rookies flooding the market. I'm not sure where all of the senior designers are, but for some reason, HR needs to hire juniors... like... straight-out-of-school-prepubescent-juniors. That's probably to cut on the expenses.

The same argument could however be made for artists (a lot of the communication complaints I get from my programmers is about them). And I imagine that this goes both ways (programmers).

What you need is a common language in which you guys can discuss, and a form of 'safe word' where authority is bestowed upon the owner of the field...

So for example, you're discussing about potential ways to improve mechanic X, and the designer comes up with idea A, which is way too complicated. You have idea B, which isn't quite idea A, but the effort is simply not the same. You use your safe word (let's say "ImdacoderheresoIknowbest") and propose to use idea B.

The key here is that this discussion happen before any doc is written for the improvement of mechanic X.

The best designers I've worked with involve the programmers at the earliest stages, long before designs are complete or even approved.

Often the designer would explain his rather complex design then ask "What is easiest for you?" Then I would go through the entire design and do my best to respect his goal. If I could add a feature that meets the goal but wasn't in the design, I would tell him. If I could simplify something without impacting the design, I would tell him. Sometimes I would suggest a change and he would be adamant that the feature needs to be a certain way, but he would always give a reason and we could negotiate from there.

As a team we would discuss the designs at the earliest prototype stage, and because we respect each other we always ask, "What is easiest for you?" If making a small change to the design will simplify the code by 20%, make the change. If a small change to the code would reduce animation effort by 10%, make the change. Every game object has a goal, a purpose it is trying to fulfill. Everybody on the team is committed to make the object the best it can be, but we also want to do it as quickly and easily as possible.

Because we respected the designers and also wanted to make the best game possible, we would suggest new features that would improve it but not add much work. If I as the programmer could easily add an existing component, I would suggest it. If the modeler could add some extra detail easily, he would suggest it. If the animator could import existing animations to create some fun feature, he would suggest it. All of us had the shared goal of making the best object possible for as little work as possible, and by suggesting new easy tasks that make the object better, we were following our mantra, "What is easiest for you?"

By the time we got to design approval (which is weeks before work started) the designer had already vetted the design with the programmers, animators, and artists who would implement it. Usually all the disciplines had already met together two or more times to work out any difficulties in the design, and everybody has a shared vision having negotiated all the details they need.

Communicate early and often. It is very rare for a team to suffer from too much communication.

By the time we got to design approval (which is weeks before work started) the designer had already vetted the design with the programmers, animators, and artists who would implement it. Usually all the disciplines had already met together two or more times to work out any difficulties in the design, and everybody has a shared vision having negotiated all the details they need.

Communicate early and often. It is very rare for a team to suffer from too much communication.

Well, our feature cycles are pretty short usually... so that may be one of the problems.
Another one may be that it's getting quickly emotional if things are technically not
possible to do (= would need a recoding of core systems).

Also - my fault - it's hard for me to accept that it's not me who can decide things if it's
just a question of taste but the designer. => he has always the better taste per default.
That's an immense motivation stopper if 95% of the work and pain is yours and you
learn that you have a shit to say and just need to do as told.
If you're lucky the producer may be on your side in the end (annoying GD)... but if he
doesn't care...

For me - even after years - it's still hard to understand how all the creative fun of game
development could end funnelled at one department... reducing artists to art deliverers
and coders to problem solvers realizing (good or bad) designer dreams.

But maybe I'd just need to meet some really good designers, so I'd change my mind.
With junior game designers coming from gaming schools and career changers who
just like to play a lot... it's hard to accept. The more if they ruin the work of others,
as I mentioned.
Yes, sure... there must be someone keeping the vision of the game in mind, but for
me this doesn't explain why everyone else needs to be turned into a service provider
for him. Unless this man is one god of a designer.

Well ... this may be the other part of the story.
I totally understand the role of the producer ... but game design... as I said... maybe
I yet have to meet a really great one.

What you need is a common language in which you guys can discuss, and a form of 'safe word' where authority is bestowed upon the owner of the field...
So for example, you're discussing about potential ways to improve mechanic X, and the designer comes up with idea A, which is way too complicated. You have idea B, which isn't quite idea A, but the effort is simply not the same. You use your safe word (let's say "ImdacoderheresoIknowbest") and propose to use idea B.
The key here is that this discussion happen before any doc is written for the improvement of mechanic X.

Hey Orymus,
Of course we cover technical feasibilities similar to the way you describe.

The problems are of a different nature.

When I was in the game industry, I was lucky enough that everybody can voice their opinions and ideas, and make it happen. Programmers and artists can have ideas what they want in the game we were making. This is important because we were the ones who would end up implementing it. So even if the ideas were "cool", we would also take the development consequences into account. The company did not have an official "designer", but when it later did, the person was cool enough to express what he wanted and the logical why, which is the most important thing. Give me use-cases why your idea is necessary, don't just tell me it's cool, then I'll implement it.

Now in the corporate enterprise world I am today, there are people who carry out the "Product Manager" titles. Their roles are pretty much the same as GDs in the game industry. They come up with ideas, talk to the people, and run the products. Success/failures of the products lie on their shoulders.

PMs, in my experience, are as clueless as what you have experienced. They think their ideas are the next Facebook. They think their ideas are so cool that people would rave and worship them, while everyone else thinks they are the most clueless people in the company. "Why are we doing this?", "Why don't we do it this way?" are typical common chatters I heard in my company (which I'm sure can also be found in other companies).