I think a lot of software developers fail to realize the fact that people are very emotionally-driven. They try to design software as if it was interacting with completely rational and logical machines. Which is great for specialized programmers, but this paradigm is very useless when it comes to product design.<p>It's easy to fall into this line of thinking because software is written for rational and logical machines -- computers. Especially in the Unix world, where software programs interact with other programs. Or in the Windows world, where modules interact using COM or .NET. Or networks where they interact using network protocols.<p>Computers are like little societies of robots that just sort of do their own things (sometimes in a way similar to societies of humans, especially when it comes to resource allocation, haha :).<p>Human-computer interaction is like international relations, and it's hard to establish because software societies and human societies have different customs and priorities. But it's also very profitable due to the laws of comparative advantage.<p>Humans are computers have different strengths, so for them to function in a state of symbiosis, someone from human society has to teach "software delegates" proper manners of interactions with humans. That someone is your traditional UX/web/UI designer.<p>Badly designed software is like some guy from another planet coming to your house and taking a shit in the middle of the room. Now, perhaps that guy is GREAT AT MATH but he just took a shit in the middle of the room and he is trying to stick a finger up your nose -- perfectly acceptable behavior on his planet. And it's hard to get along with that guy so at some point you're like "ok, fuck it" and you don't really care how great he is at math because it's hard to get his help when he's dancing naked on your table and rambling in a crazy language you do not understand.
So I've been thinking about this more since yesterday. I think some people misunderstood me and thought I was saying that pixel-perfect and polished designs are always necessary. They're not. Sometimes fast and sloppy UIs are what you need to build in order to learn the fastest, and eventually get to a better product. (Sometimes misaligned elements and odd typography gets the brand tone just right, like on hacker news.)<p>The part I haven't quite figured out how to think about yet, is how teams decide how much the details matter. How do you know when the fit and finish is good enough? I'm not sure. I do think though that as products are competing more on experience (easier, more delightful, focused, etc), that the details will matter more than they ever have in the past.
There are software developers who have this kind of attention to detail and who have some design aesthetic. I consider myself one of them.<p>I think the easiest place to catch mistakes like misaligned pixels is in the development environment. In fact, there are ways to <i>programmatically</i> make designs look "nice" (e.g. mathematical expressions to align things, algorithms that achieve smooth animations, or applications of the Golden Ratio).<p>It is sensible to have at least one engineer who is as comfortable with design as he or she is with text editors, makefiles and programming languages. It seems extremely inefficient to <i>only</i> have a design team at the top of a mountain periodically sending in requests to fix every little thing.