If you are a programmer who lacks visual design skills, what has
worked best for you -- to pair up with a graphic designer or to do all
the programming and then piece out specific work?
I worked as an indy dev for a long time before company work and I recommend the latter if you are on a tight budget and schedule and need to ship.
The trouble is that working with a designer upfront is ideal, but the collaboration overhead can be enormous, especially if they are great designers. Great designers will obsess over every detail, except their designs often won't communicate every detail down to every last function. You can end up having to read between the lines for all the mock-ups, and it starts to become unclear who the actual designer is when it comes to those subtle yet very important workflow decisions.
Working with Designers Upfront
A tricky thing that can occur is that you might get a designer who makes this beautiful, final-product-looking mockup rendered meticulously in Photoshop, e.g. It's good to actually avoid those types or at least train them upfront.
The problem in those cases is that you can end up spending all your time trying to make a drop shadow or a button bevel/rounding or font antialiasing match the look of Photoshop, e.g.
Ideally both your software design and the designer's graphic design evolve together, so it's great if you start with a designer upfront to have the designer keep his designs very loosy, sketchy, like "scribbled on a napkin" kind of loose. It needs to be highly collaborative, and ever more so in the very beginning. Both you and the designer have to be willing to evolve your designs and deviate quite a bit from the beginning "sketch", and there needs to be a very strong emphasis on "loose sketch".
It's also good to establish some constraints upfront so that you aren't trying to match the rendering capabilities of Photoshop or Illustrator, e.g. For whatever GUI toolkit you're using, you want to pay attention to its practical rendering capabilities, how it looks, and train the designer to make his designs match the capability (and even the encouraged usage/layouts) of your GUI kit.
If you're fighting the GUI kit to try to get your designs to match, either you need to train the designer of the system constraints more upfront or ditch the GUI kit and possibly even roll your own if you really want to get a perfect match. Ideally the designer actually sketches his design inside the GUI kit, but that may or may not be practical depending on your tools.
Working with Designers Late
I guess this happens since I have to be explicit in what I want with
contractors, and they are limited in creativity by the architecture I
This is not necessarily a bad thing. A great designer can make fantastic things out of tight constraints. Sometimes they even do better with tight constraints, like the sprite designers for Super Nintendo, Ridley Scott when he made Alien, etc. I actually would recommend this route if you are short on time/budget, and not be disappointed to see a lot of your imprint in the design.
Third Option: Develop Your Design Skills
I'm a horrid UI designer but I'm not a very wealthy programmer and never had the money to afford a UI designer.
Also my company experience didn't give me a good impression as to the cost (time and money-wise) to work with a dedicated one (even after going through several designers over a decade of time), though everyone's mileage may vary. It seems some people here have had great experiences working with designers so it may have just been that company setting (all the programmers hated working with the designers there and saw it largely as spending extraneous amounts of time on fussy details).
So I always tried to develop my design skills a little bit. An example of one of my little apps:
It got some nice responses as to the design, though that may be users just flattering me, and also because this application is a bit technical (visual programming with audio and images and video). Hopefully I didn't embarrass myself too much just there (I think it's reasonable but it might just be "programmer art").
If that doesn't look too horrible, I find the key is just to work with my limited design skills. Since I'm so horrible at it, I use minimal palettes, like some dark grey with no more than two or three main colors for selection highlights and things like that, take it easy on the gradients, use menus and stuff instead of lots of fancy dialogs, but don't make them scroll when possible. Basically I'm doing everything I can to hide the fact that I don't know what the heck I'm doing.
Usually when I see developer designs that seem really gross (not just to my eyes but to pretty much everyone), the programmers are probably no worse than me at design and very possibly much better but just too ambitious. They're putting fancy gradients all over the place, trying to make a very colorful design -- and that takes a lot of skill to get right. It's easier to kind of make a subdued design with a careful selection of a handful of colors to make things pop out, and that takes little design skill at all.
It's all organization as I see it. My designs might not actually look good but they're kind of tied with the functionality, and I focus on the things I can easily focus on as a programmer like keeping everything responsive, fast, low-memory, stutter-free. It seems to get a positive response, but I dunno.
Another thing is that if you work on an application where there's like a main focus area like a canvas or viewport or something, people are surprisingly generous with an incredibly minimalistic design here. Below I just kept it to menus and dialogs all the way and the users at least didn't seem to hate it even though there's not much of a "design" here at all (just a "start"-style menu and top-level menus and some basic popup dialogs that can be docked):
Here I really hid the fact that I don't know what I'm doing by just decorating the viewport with basic menus and stuff, but the artwork in the center makes it look kinda interesting without my "design intervention". So you can really, really subdue the design in those cases and let the beauty of the user's work pop out.
... It's not that hard to design a software that might at least fare reasonably well with an indy audience. I usually don't compete with big companies when I'm solo, so maybe people are just giving me a lot of leeway with my designs. Yet I think it's worth kind of developing your design skills a little teeny bit, if only to better communicate your intentions with the designer. I might have just made a jackass out of myself with these above images, but if not and they're not too bad, I found it takes no formal training or time at all to make these kinds of basic designs. All we need is restraint.