I agree with everything Steven said above! As a developer, I swear off any pretense of being a visual designer. It disturbs me greatly to see so many job reqs that presume that you can find people who are equally skilled in two distinct areas, one of which is highly analytical and left-brained while the other is highly creative and right-brained. Unfortunately, people seem to think this is a natural pairing of skills just because you use the same tools in many cases for both.
I'm constantly getting hit up to build web apps that require a skilled database designer as well as someone who's intimately familiar with the entire freaking Adobe Creative Suite! These people ultimately wonder why in the world their web apps run so slow. It's because they ask to SEE a VISUAL portfolio of the person's work without evaluating their DEVELOPMENT skills. Oh, yeah, they know SQL, so obviously they can design and build-out an entire database back-end. NOT!
Ask them to explain the difference between first, second, and third normal form, as well as how they deal with fields that are related but have vastly different update requirements ... do they put them all into the same DB records/files or separate them into different records/files based on how often they're updated? Ask how they approach and utilize stored procs and the difference they make on performance. You're most likely to just get blank stares from them! But, man, their portfolios LOOK GREAT!!! Too bad they don't understand anything that affects performance and couldn't scale-up a design if their life depended on it.
I'd also like to add the following. There's a school of thought (that I tend to agree with) that says your initial prototypes should be as bland visually as possible, even to the extent of looking hand-drawn. The more effort you put into the "look and feel" of prototypes, two things happen: (1) people you give demos to end up commenting more on the visuals than the functions and flow; (2) they also think, "it looks nearly complete". If the demo looks "production quality", and the logic you demo to them works smoothly, they cannot distinguish it from something that's "ready to ship". They think you're blowing smoke up their butt if you say there's a lot more work to be done. You need your software / virtual prototypes to LOOK like prototypes, just like how mechanical prototypes have all sorts of visible flaws on them.