In our second episode, we discuss the wonderfully polarizing question, “should designers code?” We'd go so far as to say that this is the definitive guide to this question, as we remain as cool-headed, reasonable, and rational about the topic as is humanly possible. And you honestly will never need to read another article about it. Nor should you. The question of whether designers should code is now a solved problem.Not only is this episode more fun than flogging a dead unicorn, it also sports our new intro and outtro music, performed by Mr Pickering himself. We've also got a painfully proper transcription this time around.Please enjoy!Transcript permalink00:38 (Heydon): Since our first episode, I've decided to work in some structure, so I've written—I've actually used a word processor—to write an introduction. And that introduction goes like this: “Hello! In this episode, we ask the question, ‘should designers code?’ We're certainly not the first people to ask this, and you'd be forgiven for accusing us of flogging a dead unicorn. But we have to say”—oh sorry, I fucked this up, really. I'm gonna try it again from the start. (laughter)01:08 (Stephen): Okay.01:10 (Heydon): “Hello! In this episode we ask the question, ‘should designers code?’ We're certainly not thee first people to ask this, and you'd be forgiven for accusing us of flogging a dead unicorn. But what we have to say is better, because it takes the exalted form of metacommentary. Just kidding. Let's get stuck in.” (laughter)01:31 (Heydon): How does that sound? Does that work as an introduction?01:32 (Stephen): (laughing) Okay, that's good, yeah.01:34 (Heydon): I've done my research—I've done a very small quantity of research but which can still technically be referred to as research—and I've basically gone and tried to find all of the articles which touch on this subject, and I've got a list of them here. So perhaps if we start with that… those articles are titled:“Should designers code? No, Part 1” (Heydon, laughing): I like that one. “No, Part 1” was my favorite part of that.“Coding for designers: how much should we know?”“Should UX designers learn how to code? A definitive answer”“Why designers shouldn't bother learning to code”“Why designers need to learn to code”“Should designers code, or should developers design?”“Why designers should stop coding (written by unicorn)”“Should designers know how to code”“UX designers should code (among other things)”“Should a designer code?” (Heydon): I don't know which designer they're referring to.“Five good reasons why designers should code”“Why designers should not code anymore”“Designers who code for real, learn for real” (Heydon): I don't know what the language there is meant to mean. For real! For real!“Product designers should say ‘Fuck you!‘ to being forced to code” (Stephen): Wow.“Designers shouldn't code; they should study business”(Heydon): and that's all the ones I could find. I—03:04 (Stephen): Hey, hey, hey! You missed mine!03:06 (Heydon): Wait, what was yours called? I'm gonna add it to the list now.03:09 (Stephen): “Put the ‘designers should code’ debate to rest”03:15 (Heydon): But's that's too reasonable.03:17 (Stephen): Oh, I'm sorry, I'm too reasonable. I should be… polarizing.03:21 (Heydon): It's too even-handed, even in its title.03:25 (Stephen): Yeah, I should be more confrontational. I'm sorry. (laughs)03:30 (Heydon): I honestly don't recommend it.03:32 (Stephen): No, well, yeah, your experience… we'll probably need…03:38 (Heydon): I mean, I'm okay.03:40 (Stephen): No, I mean—03:41 (Heydon): I didn't get death threats or anything like that.03:43 (Stephen): Oh, I'm surprised. But no, I didn't mean in the sense that you're suffering somehow, but in the sense that things can get complicated pretty quickly. Yeah, so, “Put the designers should code debate to rest” was… well, ask me what you want to ask me, first. (laughs)04:08 (Heydon): No, reiterate what you said in your article, because I think that's important.04:15 (Stephen): Well, what would you say if I said designers should learn how to communicate well, or effectively. Would that be weird? Or am I asking too much? Should they all hire a special PR person or liaison to talk, to sit between them and their clients or stakeholders, or should they also learn how to—you know—write an email and communicate well?04:42 (Heydon): Yeah, so this—obviously I'm gonna say that I think communication is a very important part of (laughs) whatever you do, whether you normally call yourself a designer or a developer or an engineer or whatever.(Stephen): Right.(Heydon): It all succeeds or fails based on effectively you manage to communicate. How persuasive you are, how good you are at listening, how good you are at adapting to other people's perspectives, all of that is good stuff. The so-called soft skills which aren't actually soft. They're hard.05:14 (Stephen): Right. And there's a lot of those, right? There's a lot of meta-work around design. Of course, that's kind of inflammatory from my end, because communication is something that you probably need in most jobs. Not even design, but anything else you could think of, almost. But what about if I said, let's say you're an architect. Would it be useful to know something about the materials that are going to be used to make the bridge, for example—(Heydon): Right.(Stephen): —the bridge that you're building. So that people don't die. Right? If you're a fashion designer, is it useful to know something about textiles, different materials and how they react, and should you know something about the production process so that you know what's possible to make and what isn't. And without having to do those processes yourselves, these things are probably pretty useful. If you design furniture, it could be useful to understand the processes that are needed to create something that you design and to even know if it's possible. Or if you're gonna have to hand carve these things, you know, for thousands of people, or whatever.So, my position on the whole designers should code debate is not that designers should code like it's a requirement, but it enriches your skill set as a designer. I see it as: you have pencils, you have a mouse, you have a stylus, you have Sketch, Photoshop, paper… If you do UX you can interview people, you can survey them, you can watch them as they use something… There are all these different ways that you can—all these different tools in your toolbox, and code is one of them. And I think that when people talk about this, they're thinking about, like, you need to become a developer. Or you need to make production-ready code. That's not it at all. It's about understanding how these things are made, to a level that allows you to create better design work. So, how can you, as a designer, understand, and say, from an accessibility perspective: you kind of have to know what those concerns are. And learning a bit about HTML will help you understand: “Okay, so if I do (x), then I have to be careful about this, because it might not be as accessible as we want it to be.” Or something like that. So you don't have to become an accessibility expert, or an HTML expert. But there's a definite usefulness to learning HTML and knowing what's possible with CSS. And it's also kind of fun to play with those things. To find out… playing with materials.08:23 (Heydon): Find their tolerances, in a way, isn't it? So they're becoming familiar with what's possible and what's not possible. You know, I have to say that we do think about it along the same lines. In one of my notes I've written down here is, “code is a tool/material”. You mentioned Sketch, and I've written, “code is equivalent to Sketch, Inkscape, clay, or pipe cleaners”. They're all just materials. And I think that's where we go wrong a lot of the time, is, I think, being able to code is a sort of functional skill. But design is something else. It's higher-level. So, I think we have this false dichotomy, which is between people who are developers and people who are designers.(Stephen): Exactly.(Heydon): What we mean is: people who think about things at a high level and people who think about things at a low level. And I think “design thinking”—if you want to call it that—can be part of those two levels, it's just that sometimes you're thinking more in the abstract or thinking more holistically, or just like, using systems thinking and trying to connect together sort broad concepts. And that's probably more the kind of activity we'd expect from someone who's role is designer. Although I think that's an arbitrary title, to some extent.But there is design to the way that you write HTML, and there's design in the way that you organize CSS. There's design in the way that you make relational databases have an internal structure that makes sense. And not just in terms of performance—from a back-end perspective—but also in terms of communication, going back to that. So, if you're writing an API, you want to make sure that that API is designed such that other people understand it. So that in itself is a form of… it has to take communication into account.So yeah, I think “high and low level” makes more sense as a way of comparing what people's activities are within an organization.The first question I was going to ask you was, “what is design?” (laughs) Which is a horrible question to ask.10:40 (Stephen): Yeah, because there's no right answer. I kind of like Jared Spool's answer to that question, which is—and I don't even really know what it is _exactly—_but basically to me, design is… well, what Jared says is “design is the rendering of intent.” And I kind of like that definition, because it's broad enough that it kind of encompasses the reality of my 25 or 26 years as a designer, that it never really has a very narrow focus. So, I like that definition because it kind of covers all the stuff that I've had to do in my career as a designer, and it speaks to the inten