Goat roping.

Should Designers Code????

No, Part Four. A few other reasons.

The self-referential view.

It’s unsurprising that a lot of bogus thinking has penetrated the “should designers code” debate. People have a tendency to extrapolate from their own preferences and experiences some universal quality that simply isn’t there. Just because certain things are important to you, that doesn’t mean it’s a universal truth for everyone.

Some interaction designers have defended their coding skills as a useful interaction design tool. I think it is wonderful that you know how to code, and it is totally okay that you have made it an effective part of your work process. I, too, am an experienced programmer and I have often used coding as an integral part of my design process. I’m in full, unqualified agreement.

However, I do not believe that our anecdotal experience should be construed as a general truth. Just because coding might help you or me, it does not help everyone. Over the years I have worked side-by-side with some of the finest interaction designers in the business, and many of them do not code at all. Coding is not a skill necessary to be a top notch interaction designer. The majority of the better designers I’ve been privileged to know do not code.

The cry for help.

If the recurring question of whether or not designers should write code were an honest enquiry into workplace effectiveness instead of a dog whistle for simmering tech-world prejudices, the question would not be worded in such a one-sided manner.

Everyone wants their coworkers to empathize with the work they do, but only in the software world is this one-sided version of the question treated as a serious enquiry, and it is always posed by developers about designers. It’s always about whether or not designers should become more sympathetic, more empathetic, more knowledgable about programmers.

On the TV show, Sheldon is a scientist, but he’s a programmer.

Sheldon, the main character on The Big Bang Theory television show, is an amusing character because he is a hyper-logical, pedantic nerd whose defining character trait is his inability to empathize with others. In other words, he’s a programmer, and like programmers, in every episode Sheldon demands that the other characters show empathy for him.

It’s a cry for help. On TV it’s funny. In real life it’s sad.

It’s always those with the least empathy demanding it from those who have the most empathy: designers. The designer’s job is to empathize with the user, so they are either natural empaths or they have powerful tools for seeing things from the other’s point of view.

Designers never ask the inverse. They never wonder whether programmers should become designers. They have a better grasp of the concept of teamwork, and how teams are built on mutual trust, trust that one’s teammates are responsibly performing their part of the team’s job.

This one-sided demand for empathy is not benign. When regarded seriously, it encourages unsavory behavior. It’s not a coincidence that the most technical side of our industry has a problem with misogyny. It’s not a coincidence that the selfish and destructive political doctrine of libertarianism is respected by so many developers. These and other social aberrations stem from the same inability to empathize with others.

The conflict of interest.

A well-hidden yet powerful force affects us every day in our jobs: conflict of interest. The goal of creating any product is to serve a user, but when your job is about coding and not about serving, there is a conflict of interest.

Of course, a characteristic symptom of a conflict of interest between the various team member’s goals is one member demanding special personal care from other members. That is, when developers want designers to code.

When one is paid to deploy code, anything that slows down one’s coding process will be attacked, denigrated, and marginalized. This has often been the fate of interaction design. Many second-rate business people don’t see the problem. They imagine that more code sooner is better, and don’t understand that software that behaves badly is not only offensive to their users, but, like concrete poured in the wrong place, will be an obstacle to future progress.

When an important staff member is judged by criteria different from the other staff members, the seeds of discord will sprout. When the designer is judged by user satisfaction but the developer is judged by feature quantity, the developer will regard any notion of user satisfaction as the enemy of their job. Conversely, when every member of the team is judged by user satisfaction, the first person the developer will seek out is the interaction designer; the person who helps everyone to understand the user.

I don’t have any illusions about programmers ever becoming more empathetic to users. It’s not in our nature. I just want to make sure that regardless of how awesome our technical chops are, they aren’t worth much if users aren’t made happy, and that’s what a well-balanced team does.


Click here to find the first part of this series.