Micky Gousset added these comments in his Team System blog

One thing I have found though, is that appearance is everything. I can have all the functionality working perfectly, and it does everything the customer wants, but if I have not prettied up the final site, they are always very negative towards testing it. However, if I have prettied up the site, even if have the stuff on there does not work, they are always more positive toward the application. Go figure.

This is something I'm pretty passionate about. It's true - people don't want to use good software if it looks bad. A good parallel to draw here is the "broken windows" principle, which Rudy Giuliani is credited with using to clean up New York:

The germ of the idea is simple and compelling. A broken window--or a littered sidewalk, a graffito, or what you like--does no great harm to a neighborhood if promptly addressed. But left untended, it sends a signal: that no one cares about this neighborhood, that it is a safe place to break things, to litter, to vandalize.

If software looks bad, then it sends a message about the quality of the product underneath. Unfortunately, it's not something that in my experience developers instinctively pay much attention to, and is frequently treated as a low priority issue - something "we can fix later". This is true across the industry, and not just the internal enterprise developer that Micky talks about.

In Team System, we've still got a long way to fix the all of the broken windows, but a bunch of us are working on it.