Is design a noun or a verb?

If design is a false nominalization, then we should look at the process of design instead of pontificating on what makes good design.

Transcript

"Is design a noun or a verb?" Hi, my name is Eric Normand, this is my podcast, and I'm currently exploring these ideas of design and modeling, just to get a better handle on what these ideas mean. You know, we use the terms a lot, and I find it very useful to go through and really think about terms we use all the time. I have a conversation with someone regularly who always uses the term design, and I shy away from talking about design because I feel like the term is used too loosely, and so I always require him to define it before I will talk about it. It's kind of a jerky thing to do, but I think it's important to know what we're talking about before we start. And it struck me looking at a dictionary about design and reading a lot and watching a lot of videos talks about design, graphic design or product design, any kind of design. I'm trying to find out what's going on. And it strikes me that the talks that seem the best, the most practical, are way less philosophical. Because we often ask this question, like, what is good design, right? We're looking at an object, we're looking, you know, let's say it's an Eames chair. We're looking at an Eames chair and we say, why is this so good, why is this a good design and this other one is bad design, I mean, I can intuit that this is better, but what is it about it, we're trying to, we're trying to figure out what this idea is of design. And it strikes me that that is a wrong headed thing to do, because when I listen to these talks where I read these things about design, the best ones are about a process. How do you design, what, what is the design process, less about some philosophical notion of design. So then I get the idea, wait, is this a false nominalization that we're, we're imbuing this imaginary property of something that has gone through a good process and that really we should be focused more on the process. So if you look at that Eames chair, you say, why is this good design, well, it could be that you could come up with something that's just as well designed, you know, if that means something. If you went through as many iterations as the Eaves couple did when they were trying to build a chair, if you don't know the Eames chair, they have a famous chair that's made of plywood and it was revolutionary because they figured out how to make new shapes out of plywood by steaming it and, you know, molding it and make a single piece chair that stood up on its own out of plywood. So it's a cheap material, you can mass produce it, et cetera. But it's also a beautiful piece of furniture and it's, I don't know how comfortable they are, but I think people say they're comfortable, but if you learn anything about their process, they had to make so many chairs to get to that point. And a lot of it was learning to use the material, the plywood, how do you steam it, how do you mold it, like what kind of curves can you get out of it? If you steam it in this way, if you steam it more or less hotter, you know, more water, you know, hotter air, you know, how do you, how do you turn this flat piece of wood into a curved shape in such a way that you'll get a comfortable chair? And that was the main challenge is all these constraints and solving this problem within those constraints, that was, that was the task. And they did it and it turned out to look pretty nice. You can look at something else that people think is well designed, which is something like the iMac, right, Joni Ives baby. And it is well designed as I think it's a really elegant, nice thing. But it too went through a process and the process was how do we get this computer inside of an aluminum case and so, and it still has to do all of its work, right, it has to, and it can't get overheat, you know, there's all these constraints, you just keep trying and trying, trying different things and eventually you're going to come up with a design, right? And a lot of it is simply the striving and the not giving up and trying to do something. Solving may be a new problem that no one else had seen before, so there's that element of design, right, is like we actually want to make it smaller than the last version or than our competitor's computer. We want to make it beautiful, right, compared to our, I mean those are constraints, right? But at the end of the process, what you see is the result which went through many iterations, okay, so it wasn't just they had this idea and could describe the idea and then make it. No, they didn't know what it was going to look like at the beginning. They had to try something and it didn't work and they tried something else and they didn't work but they learned something so they apply that to the next thing. And like eventually it turns into something. What you, the aesthetic of the thing, yes it's cultivated but it's also largely dictated by the medium, by the other constraints of the problem and so it's almost, it's almost like what we're looking for is not, not some principles but how do we shortcut that process so I can do it in one. And time and time again, designers will tell you you cannot shortcut the process. You need to go through the iterations and so my, what I wonder is we get, we have experienced programmers who write books on software design, again it says a noun and they are trying to describe their, you know, good intuition, their good expertise about design but they're not talking about it as a process. They are talking about it, trying to shortcut the process and shortcut 25 years of experience into some rules that you might be able to follow. And when I read it, what I see is there's a rule but it only applies half the time and here's the cases where it won't apply, here's some examples and I can't really explain why it doesn't apply or maybe this other principle applies more here and it's really a mess. It's a mess because it's someone's intuition, right? It's like when you have a neural net that you've trained, you don't know what its model is and the model, you know, it might not even have the kind of model that we would want in it. It just can classify some images as cat or dog, right? And it won't, it can't tell you why. And so in addition to these rules that don't apply all the time and kind of supersede each other in some hard to explain way, they also invent new concepts and those concepts aren't, they just, they don't work, they're just made up and, you know, you see someone who's good at design and maybe they've mentored people through the years, so they've taught a lot of people. When you're teaching someone, there's a nice thing that happens which is you can give the person that you're teaching the student, you can give them something to do, like write this code and then they write it, they show it to you and you can then see that this is not the best design, there's, it's actually a bad design and you can help them see by pointing at things like oh don't you see how it's got too many arguments or you can kind of guide them so that they can see a better design, a better approach. And that works really well because it's very interactive and anything you say is just kind of a pointer for them at that moment to see something different but then you go to write it down in a book and in a book it is a tome, a product that is going to someone who hasn't just written a piece of code that you've looked at, it's starting from zero and you're trying to build it up from nothing. So when you try to do that, these ideas of like oh look at this, look at that, look at this, they're totally, there's no context and they're taken as truth, right? So it's much harder, all I'm saying is that it's much harder, someone can be really good at design and even good at helping someone else be good at design and still be bad at writing it down and explaining what they know. So I wonder if the whole focus on design is a false nominalization and we should instead embrace the idea of iterations. So you try a design and you learn something from it and then you do another design. You write some, you know, let's say you write a class some way or you write a function some way and then you try another way and you try another way and you try another way and you don't look to have a good design in the first go around and you don't look to improve the design of one of an existing thing. You often start over, you learn from it and you start over. We don't do that that much and we don't push it and say I'm trying to solve a new problem here, trying to, there's a problem that I would like to push the envelope on, right? I wanted to take fewer lines of code or I wanted to be faster or I wanted to be crystal clear what it's doing, like we could push these extremes, right? And that's how you get better and that's how you find the new frontiers of design for your system is you push it into these different areas where you don't know if you don't know what the solution is going to look like but you want to find something in that new space. So okay, that's where I'm at, I'm really exploring this idea of design, of modeling, I really want to find something that is, well, I'm not looking for anything, I'm just going somewhere where I'm lost because I don't think that we use the terms very well and I think that this is how I learn is by going into a place where I feel confused. So I don't know what I'm talking about and that's why I'm doing this because I feel like I will eventually make sense of the mess that I find, both in my mind and in the materials that I've got access to. So thank you for joining me on this. You can, I mean, I really would love to hear what you have to think about this, whether you've got some good materials on trying to define design or define the design process. I think that we've taken wrong turns or maybe missteps in software development and we talk about design but no one has a good definition of it and that bothers me, it also makes me think that there's a lot of good material there and it's something we talk about a lot. So it's probably important but we don't know what it is or what to do, right, what actions to take. And so we have these debates about, you know, is this good design, is this good design? And maybe if we talked more about design as a process of solving a problem within a set of constraints, then it wouldn't be so much of a, you know, a debate about nothing. It would be more about, yes, this does solve the problem or no, it doesn't because you forgot about this constraint. Okay, that's enough. So get in touch with me. You can go to lispcast.com/podcast. You'll find links to get in touch with me also to, you know, email me. That's the best way really to get in touch with me. If you email me, I'll either respond with an answer if you have a question or a discussion or I might make a podcast episode about it. So I love, I love when that happens. So please do also subscribe, rate and review on whatever system you use for your podcasts might be iTunes, might be Google Play, that really helps other people find it. And if you like it, please tell your friends about it. So thank you very much. My name is Eric Normand. This has been the Eric Normand podcast. And as always, rock on.