Should Designers Code???
No, Part Three: Roles and Responsibilities.
There’s a recurring debate in our industry over whether or not designers should write code. I answered the question more broadly in a previous post, but there is so much to say on the topic that I am putting more detailed thoughts in this and other posts.
As I’ve said so many times, the answer to the question is “No, designers should not code,” except of course for the times when they should code. This conundrum resolves only when you examine the topic more closely than most commentators do.
The root of the confusion is our naturally human desire to encapsulate and simplify our world. Humans don’t like complicated things, and we fabricate little stories in our minds that reduce the wickedly complex world into one of tribalism, white and black hats, sound bytes, slogans, and overly simplified stories. This tendency to simplify isn’t necessarily a fault. It’s an evolved survival mechanism. Of course, we evolved that mechanism in a pre-digital, pre-industrial world, when we were trying to make sense of the scary darkness. In the modern world, it has been shown to cause problems.
One of the notions that we simplify is the nature of tech work. There are people whose primary job output is code, and we simplify their identity to “coders.” There are others whose primary job output is descriptions of things to code, and we simplify their identity to “designers.” These are not real jobs or job descriptions. They are mental shortcuts, over-simplified approximations, and a great source of confusion and contention.
If you stood outside and peered into the window of most tech companies and saw designers and coders, you’d be hard pressed to tell the difference between them. They both spend lots of time talking with their peers, white-boarding complex diagrams, and typing into their computers.
When a designer creates interactions, they are engaged in a process of designing. They are designing views. They are designing representations of mental models. They are designing paths and journeys through intention and logic. They are designing behavior. They are designing deterministic sequences of events, actions, and reactions.
When a programmer writes code, they are also engaged in a process of design. They are designing code. They are designing data structures. They are designing procedures. They are designing algorithms. They are designing solutions to problems posed by the various interfaces they must access.
In the programmer’s world, the big solutions are often constructed on the white board, on paper, or in their mind’s eye. Reducing them to actual computer code is just mop-up work.
In the designer’s world, solutions are often constructed by iterating through programmed prototypes, through code. They are building interactions in software to see how the program’s behavior feels and to test how users will respond to it.
Do you see where I’m going here? The dividing line between coding and design is wide and gray and ever-shifting. That is, the division is confusing when we use the excessive simplification of “coding” as a litmus. Coding is a tool, and good craftspeople use whatever tool is best for the job. Neither coding, nor creativity, nor design, nor interviewing others, nor any other tool is particularly relevant when we are trying to discern the difference between job roles.
What is relevant, what does differentiate the job roles, is responsibility. The developer is responsible for distinctly different things than the designer is. The coder is responsible for the safety, security, efficiency, and success of the program. The designer is responsible for the experience, the happiness, the satisfaction, and success of the person who uses the program. Both of their responsibilities are significant and important, but they are not at all the same. The developer is responsible for the technology while the designer is responsible for the user. Both have to be made happy for the business to succeed.
When we say someone “is a developer” or “is a designer,” it’s like saying someone “is a doctor.” There are doctors who study disease, study baboons, study bones, who grind up rat livers seeking oncological data, interview accident victims seeking safety insights, perform autopsies on cadavers seeking causes of death, who administer drugs to knock people out, cut them open to repair heart damage, insert robot arms to stitch up tendons. The breadth of skill and activity of doctors is enormous. Some doctors never even touch a human in their professional capacity. What defines a doctor isn’t their tools or their skills, but their responsibility. They even have an oath they recite — and take very seriously — that enumerates their commitment.
Sometimes the best way for a designer to communicate their vision is to code something up so that their colleagues can interact with the proposed behavior, rather than just see still images. The goal of such code is not the same as the goal of the code that coders write. The code isn’t for deployment, but for design. It’s purpose is different. It has a different responsibility. It’s code, but not the same as code as from a programmer.
I have written thousands of lines of code for this purpose. Back in the late 1980s, Ruby, the visual programming language I wrote that became Visual Basic served two purposes: It was a platform for invention, and it was a tool for communicating my invention to others. It was categorically not code that could, should, or would survive shipment to users.
The annoying recurrence of the titular question is evidence not that some group of practitioners needs to learn the other’s tools, but evidence that the groups of practitioners don’t have the same goals, and the organizational structure within which they work is okay with that broken state of affairs.
The goal of managers isn’t to make decisions anymore, but it is to assure that everyone on the team is working towards the same goal, and that everyone is fully informed of the costs, benefits, and tradeoffs of any particular strategic choice. When the organizational structure supports rather than undermines the collaborative efforts of skilled information workers, those same workers are supportive of their siblings in arms. The coders want the designers to design, because they trust the designers. The designers want the coders to code for the same reason. The last thing either wants is to step across into the other’s world.
When people ask if discipline “A” shouldn’t be doing the job of discipline “B,” it’s clear evidence that the organization is flawed and — by extension — that management has failed.
Here’s the second part of this series: No, Part Two: Know versus Do.
Here’s part four.
