Anyone know the statistics on how many people can or can’t pat their heads and rub their bellies at the same time? Even if you can, you have to admit, it takes significantly more concentration and focus than you would guess, for something that looks so easy (when someone else is doing it). And we all know that it has something to do with our brain wiring, some of which we are born with and some of which we learn (and re-wire). I always find it interesting when you come across another activity or two, that exhibit the same characteristics.
Like product design and coding. There are lots of great coders out there. And lots of great designers. There are very few who are both. But this post isn’t about how product design (usability design, ergonomics, aesthetics) is different from implementation (technical design and coding). It’s true that you rarely find one individual who has the sensitivities and skills to do either design or coding really well. But let’s assume for a second that you are lucky enough to snag one (congratulations). I propose to you that even though this person has the skills to do both, doesn’t mean you should let them.
The real value of such a person is that they have the capability to do either function even better because they have a very good understanding of the other. And, after all, these are symbiotic skill sets. A really wonderfully designed product is still crap if it’s buggy, slow or doesn’t scale. And a rock solid, fast, scalable system is useless if people can’t (or don’t want to) use it. So we know that a successful product needs an equal measure of both.
What I find interesting is that I have spent years doing both of these activities – designing and coding (not to mention the managing, wrapped around both). Even though sometimes I have been forced to be intimately involved with both at the same time, I can’t escape the feeling that I wasn’t doing myself any favors. You might be tempted to think that having a single brain responsible for the design and the implementation would be wonderful. Think of the efficiency! I believe it has quite the opposite effect. And it has to do with “automatic compromise”. In this case, automatic = bad.
The great thing about having a separate designer (let’s assume that this person has some understanding of implementation so they don’t ask you to build the boat upside down), is that it frees both parties up to start with the “perfect world”. In a perfect world, the designer thinks, we would build it this way… In a perfect world, the coder thinks, we would implement it that way… Now, they can come together to discuss any issues with how the design makes implementation difficult, or vice versa. They can negotiate. They can escalate. Tradeoffs that are made are transparent because both people discussed and agreed to them. Maybe they were even documented in case someone asks later? (ha!)
The trouble with trying to squeeze both activities into a single brain is that for each of the million little decisions you have to make while you’re both building and designing, is that you are always in such a tempting compromise position, that your objectivity gets ruined while you’re “in the moment.” If you’re making big design decisions while your head is immersed in coding and you’re frustrated because something isn’t quite coming along as quickly as you thought (imagine…) or because you’ve hit some unforeseen technical snag, what do you do? You design in a compromise, just so you can get going again, or make up some lost time. Do this a dozen times and soon you’ve got a mediocre design and mediocre implementation. I’ve written about when not to compromise before.
There is a big advantage in being able to focus on just the design (leaving implementation details to someone else), or just on implementation (leaving the big usability decisions to someone else and being free to say, “just tell me what you want it to do”). You both get to start with the “perfect world” scenarios, and then come together to find the smallest possible compromises so that you both get to end up with something that is as close to your original concept as possible.
The funny thing is, even though it is tough to describe the explanation for why it is so tough to be great at design and implementation at the same time (as I’ve just tried to do), is that the rationale (although interesting), doesn’t really matter. The outcome remains the same even if you can’t really explain it. You’d think that if you can either pat your head, OR rub your belly REALLY well, then it should be a simple matter to do both at the same time. Not so much. And even if you can, you’re likely having to exert a significant amount of extra focus and concentration just to avoid rubbing both or patting both, instead of rubbing one and patting the other. And any activities that require THAT much concentration and focus, are even more vulnerable to things like distractions and context switching, which we already know are big problems in software develoment, even for the simple stuff. It’s a risky strategy from a product point of view.
The best possible scenario is that designers and coders get enough exposure to each other’s worlds that they can truly empathize and avoid big incompatibilities with each other’s goals, but that they still get to focus and become specialists. That way, when it comes time to make those compromises, you’ll know it each and every time, because you’ll be sitting down to discuss and debate them to the best possible outcome.
Great post! I happen to think that programmers are the best web designers, however. Prettiness is overrated when it comes to web. Print design is one thing: turning the pages of a book is straightforward, so you can focus on aesthetics to a large degree. The web is another animal. There are hundreds and hundreds of subtle usability rules that programmers “get” more often than professional designers. So while designers are great at finding color schemes and creating accent images, I think coders can lay out the most usable sites. Just my 2c.