Don’t let programmers design.

Don’t remove programmers from your design cycle.

Okay, that’s not helpful advice. Let’s be more accurate.

Designers need to be as varied as your sales targets should be. Programmers need to think like programmers. Let’s face it; no one who can deal with a few thousand lines of C++ is still going to think like a normal user.

Normal users don’t think like normal users. Look at the demographics of any given group. A little over 50% of the population in the English-speaking world is female. Nearly one in ten is left-handed. Between one in twenty and one in a hundred like the company of those of the same gender a bit different than the other portion of the populace. Just under one in one-hundred and fifty of the next generation may land somewhere significant on the various autism spectrum disorders. As many as 3% of the next generation will be diagnosed with ADHD. Color-blindness, directional language preferences, whether your users were hooked on phonics, a thousand different attributes that you’ll never find in a single team.

You can’t have that on a development team, not without having a small country worth of people, and each attribute can easily change you how a user looks at an application, often to massive degrees.

Some of them you can simulate. Most forms of color-blindness aren’t hard to correct for, and doing so is strongly suggested for anything starting at a web page, which is good since color-blind artists are not exactly common. Left-handness can be mimicked, although it’s amazing how often you’ll run into issues if you don’t design for it from the ground up. Others aren’t so easy.

Don’t design with just programmers. It’s a good thing to know what can and can’t be done well from the code. But you can’t have a programming team that understands how people think, and you can’t afford to wait until late beta or post-release to discover that your user customization drives even one in a hundred people crazy. Far too many games and programs have made that mistake.