Using Yourself as a Constraint

You're listening to Working File, a podcast about design and its relationship with the world. My name is Andy Mangold.

And I'm Matt McInerney.

On this episode, we talk about the relationship between design and various means of production.

And the requirement that all designers must learn to code.

So, yeah. Welcome to Working File, Episode 5-ish depending on how we numbered them. This is a design panel discussion podcast where couple of designers talk to a couple other designers, and we talk about design stuff, and we try to do it in a good way, and not a bad way. And have interesting conversations that are actually compelling. I'm Andy, and Matt you're joining me as always from Philadelphia. Hello, Matt.

Hi. Andy, that's a perfect description of the show. It is a design podcast about design stuff, design, design, design. Have you pinned down where we are exactly?

Well, look. We've struggled in the past because you know how much I hate calling a thing a design thing, and I figure maybe just try shooting the moon. If you call it a design thing enough maybe it'll feel less gross to me.

Look, I understand Andy. You hate describing a thing accurately. That would really put you in a box. It'd be terrible.

When it involves me, yeah, I hate to think that I can be summed up so easily. I like to think I'm a deep ocean of possibilities and not so easily summarized, but...

You're an ocean in a snowflake. I hope you feel better about yourself.

But we're joined by two important guests. I should say our topic for tonight is The Relationship Between Design and Production. We're gonna try and discuss that relationship across a couple different industries and in general, and we have two wonderful people here for this discussion. You're both joining us from San Francisco, correct?

Yes.

Yes.

Hello.

From different rooms, different rooms in San Francisco.

From across the world next to each other.

We're like five blocks away from each other.

We are joined by, first, Linda Eliasen. Is that how you say it? Eliasen.

Yeah, that's one of the ways. Yeah. There are couple of ways to say it.

Eliasen, is that better?

That's a nice way of saying Andy screwed up.

Let's take that another time.

No, no, Andy actually said it the right way and it's just that most people say it the wrong way so the wrong way has become the normal way, in a way.

Okay, well get ready because I'm about to say your studio name the wrong way too. Linda is an art director at Ueno. Is that how it's pronounced?

Yeah! You said it.

Not, U-wee-no?

It's not U-wee-no. It is Ueno.

The ueneders.

Some other series of vowels. It's just vowels. You're an art director at Vowels. Welcome Linda!

Yeah, just a bunch of vowels and me. Hi. Thank you for having me.

Thank you for joining us. And then also, finally, in a different room in San Francisco, we are joined by the one and only Jon Gold. He's an inter-disciplinary designer, an engineer, and he's working on merging design, AI, and the future tooling. But first, he needs to figure out how to work his computer in general: Skype, Google Hangouts, basic microphones, anything before he can get to all that fancy AI stuff.

See unfortunately, design and use has never really discussed whether a designer should learn audio production, so I kind of messed up there but I think we're good now. We're gonna find out in an hour when we've hit stop on the recording.

You're here now. So we're gonna find out if the audio is actually recorded. This will either would be lost to the ages or it'll be Episode 5. We'll find out when this thing is all said and done.

We can just keep it blank whenever Jon speaks. If it's not recorded, just leave it.

You can just put fart sounds in or something.

There you go.

Cool.

Or maybe you can choose your favorite song and we'll just cutaway to your favorite song for some period of time whenever you're speaking.

Yeah.

That could be fun.

That'd be good.

It's a way to keep you involved even though you've been cut out of the show by technology.

Alright, so as I mentioned, tonight I wanna discuss broadly the relationship between design and production. I wanna start just by having everybody talk about their own personal relationship between design and production. I will start with me so you have some time to think about your own personal relationship between design and production. I am a trained graphic designer. I have a degree in graphic design. That is what I would have to put on... That's what I probably have on LinkedIn right now if I were to check. Not that I remember what that is. And so, what that means to me is I have an understanding of color, form, typography, composition, hierarchy, all these fun words we used to describe design generally.

And for most of my life, I've also produced the things that I have designed, which I didn't realize until actually much later on, like when I was in college that what I was doing my entire life was designing. I thought it was just tinkering or making stuff, but really I was designing things and I was implementing them in whatever fashion that was. So, I do occasional woodwork. I write CSS at work. I wouldn't say I'm a full front-end developer because JavaScript is still completely unintelligible to me for the most part, but I do write CSS and HTML and build most of the front end of the web sites and work on in that sense. So for me, it's something that I've always done, is done both the design and the production side of most of the things I'm involved in. But I will say that the most valuable things I've ever made have been in collaboration with people that possessed production skills I myself did not possess. And that was some of the work that was most valuable to me. So with that, Matt, I'm gonna make you go next.

That's fair.

You, design, production. Where do you sit man? What's the deal?

I feel like I've had this weird journey from making stuff on the web and just making things that I can make on the web. Well, I'll learn enough programming to make the thing I wanna make, and that'll be the extent of the production, to getting an actual graphic design degree and learning how to do that, to going and working in a traditional firm where I would do a little less web and a little more like design a book, design a poster, or ad campaign that gets printed, or design a 3D object. And now I'm much more back in the world of designing things for the web, but this time I'm not producing them because I'm actually a bad programmer.

So I feel like I've had a little bit of everything. I've programmed poorly, I've made things that other people have to physically make, and now I make things that people have to digitally make.

And fair to say you weren't also printing enormous books and doing the production when you were at your more traditional graphic design job, right? You were working with vendors and you were getting things made, but you weren't yourself making them.

I've definitely printed and made a book myself poorly, but I would say my clients wouldn't prefer that.

Linda.

Hey.

Linda, what do you do?

I don't do anything anymore.

You sit in conference rooms and watch television on Netflix.

Yeah. Stranger Things is so good.

No, [chuckle] I was definitely always the kid making the things. What you said resonated with me, Andy. I remember doing arts and crafts with my grandma, she'd be like, All right, take a bunch of trash bags and cut it into pieces and then we're gonna take the pieces...

And put trash in them and take it out of the house.

This is an elaborate trick to get you to take out the trash.

But we would tie these little pieces of trash bags together to make Christmas wreaths. She would just have those types of crazy craft projects. And no matter how lame the project was, I wanted to be the best at it. I just had to be the best in the class at whatever projects that we made, so it was always this solo thing where I wanted to draw cartoons, and just make stick houses out in the yard, like whatever. But it was never a collaborative process, so I think that... Eventually I ended up going to design school just like you, and learning all those things. And I think it was still kind of like the every man for herself, or woman for herself, kind of feeling where it was a little competitive and you don't really want to work with other people because you still kind of want to be the best at whatever you're doing. And yeah, so slowly over time I've had to learn that if you want to get really good work done you have to work with people who are good at your weaknesses. So, yeah.

So has this carried over into your professional work now? Do you still like to be in charge of everything and not only design something but make it, or make a prototype of it? Or do you work now with vendors and programmers and printings and whatever to get things made?

Yeah, I've gotten really good at handing things over and just being like, You do this because I suck at it. [chuckle] And yeah, it started at MailChimp and working with the dev team there. We worked really closely with the front end team. And also, just if we ever needed anything printed we would go to the printer and watch them work, and approve of things, and it was really awesome. So then, at Dropbox, you work with a whole dev team a lot of the time, and that was a big learning challenge for me. But I think it's all for the best, and yeah, now I feel like I have a pretty good working relationship with a lot of people. It's really nice; it takes a lot of the stress off of you.

So Jon, I know you pride yourself on being able to produce the things you design, at least when it comes to programming. Can you talk a little bit about what your relationship is between these two kinds of sides of the practice?

Yeah. I feel like it's changed, or it's evolving over the past couple of years. Like the rest of you I also did a graphic design degree, and I think for a long time I assumed that I would always, always be a graphic designer. I loved doing print design. That stopped being the case somewhere around when I was graduating, I guess. And I always coded in different capacities, and I've been trying to piece together why that was. And I think there's a couple of reasons there. Part of it I think was my way of dealing with impostor syndrome, I always coded more because I thought I was a bad designer and it was my way of masking it. It was also quite nice because as a self-taught developer I could also mask myself there as well. I could be like, Oh, I'm just a designer, it doesn't matter if my code's bad. So it was kind of self-preservation on both levels.

And there are a couple of other reasons in there that maybe we can get into, but over the past couple of years it's definitely evolved from a designer who writes some HTML and some CSS to a designer who definitely codes and thinks other designers should code to at the moment, I don't really like job titles but I feel like right now I'm very, very 50/50, like software engineer/designer. I've started using the title software engineer occasionally recently, which is weird because I definitely never thought I would feel comfortable calling myself a software engineer, but life is weird, I guess.

That's actually a good transition Jon, because the place I want to start with this conversation is, there is some subset of designers, or people that do a lot of writing and tweeting about design that would say that designers today have to be involved with the production. Specifically they have to if not know how to code the things they're designing, they need to understand how they're sort of put together. And I think that argument is based on two assumptions; one assumption is that the designer that is more prepared to be able to write some code is more prepared for employment in the future.

Everything is gonna be computers, we're gonna live in Tron, The Matrix. So, the more you program computers just the better your job prospects are. And the other one which is the one I'm more interested in, is the idea that, I've heard from a number of people that I respect significantly that their belief that being closer to the thing that you're designing, understanding how it's made, understanding what goes into the actual production of it, makes you better at designing it. Is that something you believe Jon, that understanding how it's made, being involved in the production will make you better at doing your job when it comes to the design side of your job?

Yeah, I think that's one of the things that I'm pretty confident about. I think you have to understand the materials that you're working with. There are so many analogies that you could draw but I think an artist that doesn't understand the materiality of oils versus canvases versus acrylics versus... I'm really bad at art so I'm gonna stop with this analogy, I can't paint for shit. But generally I think you design better things when you understand the materiality of it. If you wanna add some show notes, I think the first thing we can throw in is Jony Ive did a fantastic talk at the Design Museum in London a couple of years ago and it really, really resonated with me. He was talking about how the way that things were designed at Apple in hardware design intensely reflected the materials they were using when they switched from that translucent plasticky stuff to aluminum or aluminium as we call that. It changed the way that they...

Yeah, you have to say it the British way, we have to go all ham on that. Aluminium, yeah, come on. Aluminium, it's good.

Aluminium. Aluminium.

Aluminium.

Oh good, I didn't know what you were talking about before.

This is a safe place. [chuckle]

Be as British as you want.

When they switched to aluminum, the form of the creations changed. They used different angles, they used different methods of cutting and they could have different tolerances, all these difference things. Now that's kind of trite because it's metal versus JavaScript, but to me the metaphor really, really works. I just feel like we do infinitely better work when we really, really intensely understand the materiality of what we're working towards. And that could be things as specific as different rendering engines or different text layout engines, the differences between the web and iOS and Android. These are really technical things but they also impact the fidelity of your work and what you can achieve.

I wonder that all the time. How do you feel about this? Do you think the analogy really, really does work or do you think that's something we tell ourselves to feel better about being good at our jobs?

Well, I've invested 10 years or 15 years in learning to code, so I can't be completely unbiased there, sorry, I couldn't...

Because I feel that way very strongly about working with actual materials, like if we're talking about materiality and we're being literal about it, I think that makes a huge difference and I always felt like... When I first started doing print design professionally, I felt like I was fighting with it until I got a handle of what I can and can't do and then I was kind of working with the medium to make something better as opposed to just yelling at a printer and being like, Why can't we do this?

Yeah, at first Matt was like, Can we just fold this wood? and turn... I can't think of something you can't do with metal. Metal's a very...

Why can't you just print that on gold?

Yeah.

But I think that that's different because like in a physical medium the constraints are pretty much set in stone, and with technology the constraints are changing so much and so quickly.

That's why I wonder because I feel very strongly that my understanding... Like me being bad at coding helps me be good at designing for code, but I don't know if that's true. I don't know if that's something I just tell myself because it's a really good real world analogy, and I might also be as good at designing if I didn't code poorly in the medium. I'm not sure if it's true.

Part of me wonders if it's just one of these things that the idea of it is so beautiful, you just want to believe it's true. Like the idea that somehow being close to the material and the actual physicality of something and the production of it is gonna make you better at it, but the thing I always go back to is, I should say, I adhered to this idea strongly for a long time and then one day I was kind of like, Well, wait a minute. I know how to make websites. I've been writing HTML and CSS for 16 years and I know how to write Ruby On Rails a little bit, I can make my way around a project. I know how websites are made, I understand it. And I design websites. I also design iOS apps and I don't know anything about how iOS apps are made. I know that you use Objective-C in Swift and there's this thing called Xcode and it breaks all the time, but I don't understand anything about that. My depth of knowledge about that is so much lower, so if we're adhering to this idea that understanding of the means of production makes you that much better, am I a terrible designer for iOS apps but passable on the web?

Guys, this is that moment where we all tell Andy he's just terrible at iOS.

Let's take this iOS as an example you understand the relationship between I don't know, UI navigation controllers and UI tab bar controllers and you understand the way that things fit together, you understand the way the pieces fit together, and you could say, Well, that's just the paradigm, that's not close to the metal, but I think it is. If you understand how a navigator layers scenes up or something that, that kind of is that. Or if you're like, Oh, we can use maps now and we can geolocation because there is blah blah blah, that's kind of understanding the medium. You might not have to understand how Objective-C allocates objects or I don't know. But it's understanding the SDKs, it's understanding what tools are available.

Yeah, that's how I feel about it to. I think people oftentimes confuse knowing how to do the production work with an understanding of the constraints in which you're working. And there are certainly situations where you would be helped by trying it out. Like it'd be cool to have an architect to go on the field with some construction company and see what it's like to frame out a building maybe. But I don't think that's essential to doing that job well. I think you can understand the limitations and the constraints. And that is just how I think we should be defining design in all industries and especially on the web is like you don't get to understand the web unless you understand these constraints. And that doesn't mean you have to be able to rattle off a bunch of your favorite Java Script libraries and sit down and build a whole website. It just means that you have to kind of understand the language.

Now I think it's just important for people to understand that they don't have to do everything themselves. I like what you're saying about how you should have a basic knowledge for how this thing works. But if you're not doing it regularly like all the time, I feel like it's really hard to stay up to date and to have a really honed skill in coding. And so, I would end up just using myself is a pretty huge constraint honestly. When I'm figuring out what's possible for a project, I just end up not thinking as wide as I could if I'm working with an engineer who's like, Ooh, have you thought about this? And what about this?

Actually, I was gonna ask a question, almost the opposite of that. Do you ever find that because you know something and you know one thing is easier to do than another, that you choose the easier path? And maybe there's no reason that that easier path is the better path. Maybe it's worse. But you know it's easier to implement, so you think, Well, let's just do this. And maybe if you didn't know, you'd be less constrained and you'd do an objectively better job because you're free of that constraint?

Yeah.

Yeah. Exactly and I think that sometimes designers and engineers need each other because I'll pitch an idea to the engineer and you can kinda see their brain melt a little bit. They're like, Really? We gotta do... Ugh.

Do we have to figure that out?

And you're like, Come on, it'll be great. Please, please, please.

Yeah. And then, I think in the end it makes for a better product.

Was that an argument for understanding less?

I wouldn't say that anyone should ever understand less of anything, but I just think that you should put less pressure on yourself to do it all yourself. If you honestly just want to be a designer, fucking go for it. Be an awesome designer. Don't worry so much about coding just to be able to talk about it with people and sound like you know what you're talking about. [chuckle]

I think that's a pretty important thing to jump on actually and to stress, that no one should feel compelled to have a certain skill set. I think this is one combination of skills that we're discussing, but there are a zillion other combinations of skills out there. And if you don't want to be a programmer that is completely, completely fine and it always will be.

Yeah. And there'll be jobs for you too, believe it or not.

Exactly. It's like where is the argument about should designers illustrate. I think that's a super useful skill to have as a designer. And I don't know...

Absolutely. But it's just a different discussion. I think I talk a lot about designer's coding, but that's just because it's the discussion I tend to be having. A lot of the best designers I know don't write code a lot. The best designers I know are incredible business people or illustrators and/or photographers and/or whatever else. It's coming up with stuff that's exciting to you and stuff that gets you motivated so you could work.

It's funny the argument... I feel like we never see the argument on Twitter like, Should designers learn to business?

But that would probably be a much better skill to have than should designers learn to code, but it doesn't come up because like you said Jon, it's just not the conversation we're having.

Also because learning to business is gross.

This came up through the day on Twitter actually. Caylee Betts from DigitalOcean was asking about it. She was like, Is it more beneficial for designers to learn to code or learn to business? And opening that massive, massive can of worms. One, I don't like wearing suits. And two, yes, designers should learn anything. But I think one of the reasons, one of the many reasons that I like programming is it's like a feedback loop thing. So you could be like a good designer and a good developer or, a good designer and a good business person; your feedback loop is gonna be shortened immensely by being a good designer and a good engineer and then, collaborate, having a good business person working with you, versus what it would be like if you're a good designer and a good business person working with a good engineer. I think business is useful, but it doesn't affect the design process as much as engineering does.

Well...

That's interesting.

I don't know about that actually.

Interesting Jon, I'm not sure.

I think I disagree with you.

You ever heard of a budget Jon?

Especially depending on what kind of designer you are, if you can negotiate the job the way you wanted to from the beginning, I think that has a much greater effect on it than how close you are. It's all degrees. There's so many variables involved. But like...

It's a matter of scale. On the details of how the thing actually comes out, yes, absolutely, the tight loop between implementation and design or vision is super important. But when it comes to, What is the thing? Does it get made at all? Those questions are answered by business, for lack of a better word, which is just...

But I feel like the designing code thing is like, Ah, you can finesse the details. But the designing business thing it's like, Oh, well, will we either build the system or even make a useful system at all?

Exactly.

Or not. It just won't happen. [chuckle]

Yeah. But this is why I said that I very passionately don't think that everyone should code. I think that people who find code interesting should code. People should learn about things that they like learning about. If people don't like learning and they like watching TV, that's also fine. Everything is fine.

I really don't like business. So, no one's gonna make me do it.

Everything is fine. It's solved.

Don't make me do business.

I was hoping Jon would come in here gun-slinging, talking about how people that didn't write code were gonna be dinosaurs.

You're dead.

That would have make for such a more interesting podcast. But here he is being all measured.

Give us something real quotable Jon.

Oh. There's two ways we can do that; either I can be like, Oh my God, every designer should learn how to do React because he had to blah, blah, blah, or I could be like actually in 10 years time, I don't know if design tools will have code in them at all. I think it's a good bridge layer for now to enable us to figure out what the future of design is, but I...

Yeah, and React definitely won't exist in 10 years either because technology...

No, no, for sure. But I think a lot of where we're evolving to with design tools these days is actually designers won't have to code again in a couple years time if we do our job right today.

I don't know. I just think that we need to work on our relationships. I think that the whole should designer's code thing, it's like I think for some designers, yes, there might be people who are trying to build their own portfolio site for the first time or they're trying to work in a small company and yeah, that will be very beneficial to you. But if you're working with a larger team, I think it's then more a question of relationship building, you need to have a really good relationship with the person building the thing you're designing. And I think that's a little bit more important to me and talking to those people at the start of a project and figuring out what their constraints are and trying to get their feedback often.

Should the question just be, Should designers be introverts or extroverts?

Yes.

Is that...

Unrelated. Unrelated. It doesn't matter if you're introverted or extroverted. It's a matter of communication skills.

No. I mean like if you wanna make everything yourself and be able to do that without communicating with other people, well then learning code might be very valuable, but if you...

Yeah. Because you never have to talk to anybody else to code something. That's not how that works at all. Except it is.

Guys, I think you may have just completely psychoanalyzed me. Let me just lie down on this couch like, Wow. That's... Yeah.

Jon, let's talk about your relationships.

No. But I'm just saying that coming from why I like to make things by myself completely sometimes is that I don't wanna communicate...

It's because everyone else is asleep Matt and you're the only one awake and so who are you gonna work with?

Everyone else is dumb.

But sometimes I don't wanna communicate with other people, sometimes I like it a lot when it's a bigger project and it's the best way to get it done, but sometimes I just wanna make a stupid little thing on my own, and the best part is not having to talk to anybody about it.

Yeah, until you run out of time.

That's usually why I do that.

And then you're an artist, Matt. Look at you. No, yeah. And the thing that... My personal experience with this has been that as somebody that... I would say my time is probably split, actually almost perfectly into thirds between doing design work, doing what I guess you could loosely call business work. Taking meetings, writing proposals, talking to people about their ideas, sales, whatever you wanna call it. And then, a third doing software development, writing CSS and HTML for projects that are active. My experience has been that I have definitely felt my design work become lazy in the sense that I know what is very easy to build and I'm very likely to favor that over something that is more difficult to build in a way that I have to force myself to say, Let's actually try a little harder on this, because I know this would take 45 minutes and that's really appealing because it's probably 85% as good as the best thing we'll ever come up with and it takes so little time. But I've to actually force myself to say, No, let's keep pushing, even though this is a totally satisfactory, efficient solution because efficiency is not always the best thing.

And the other thing I'll say is that I don't think... Again, from the most bias position ever. I am me. I can't really tell in any sense of objectivity what I'm actually doing. But it doesn't feel like my design work has been as positively influenced by my awareness of how things are built, but I will say my development work has been extremely, positively influenced by understanding the design that I'm building. And a practical example of that is if you hand off some still image of a website you designed to a developer and asked them to build it, most of them will look at it and say, Okay, great. This is 35 pixels. This text is this big. This thing is this hex color. But if you're the person that designed it, you know that, Yeah sure, that's 35 pixels, but it's actually twice as big as this thing over here, and yeah sure, that's this particular hex code but it's actually a mixture of these two other colors that are used elsewhere.

And the way these things break down, the way these elements behave is actually all system and when you're writing CSS, you can build that system instead of just building the results of it, which is why I think a lot of engineers that don't understand the design process or having communicated with their design teams end up doing and then the designers are like, Oh, can we just change this one little simple thing and then Dev is like, No, but that's a million little changes because everything breaks when you break that little thing. And they didn't realize that the system was designed with some degree of variability in it. So, take that with a grain of salt because... But that's my experience. I feel like my development work is better.

Yeah. I think that's completely valid. I think that's a pretty decent analysis of why design and code aren't silos. We have these job titles right now, but they're just doing the design... Making the Internet. If you're finding that there are barriers between two people's job titles, well, maybe that barrier just shouldn't be there and there should just be a new job called Internet makerer. I think I used that for awhile. That's a dumb name.

Yeah. So, let's get away from just the code thing. I don't want this to be the Should Designer's Code podcast because that's been...

Oh, thank God.

We've already asked Designer News about that.

Drawn out a little bit. Matt, I have a question for you actually.

Yeah.

I feel like amongst the four of us, you probably have had the most experience talking to architects working on projects that are related to architecture. I know you did a lot of environmental signage and stuff at your previous job. From what I've observed... I'm always curious about the relationship between an architect and the people that are actually gonna build the building that is designed by the architect and how much that engineering comes into play in architecture versus we're gonna come up with the vision, then the engineers will figure out how to make it actually stand and not blow over. Recognizing that you are not an architect and have not worked in the industry, do you have any insight into that relationship? And the broader question is, what other examples of the relationship between design and production can we, in our industry, possibly learn from?

Man, I definitely haven't been the architect, as you said, but I've seen some architects who just, clearly, make a form, and then work with engineers to make that possible, which I feel is the approach of, whether I understand the constraints of the material or not, I don't care. I want to make a form and we're gonna work as hard as we can to make that form possible. I think the famous example is the Frank Gehry using software to make airplanes to make a building, because AutoCAD just can't do that. I don't care if AutoCAD can't do that, we're gonna find another way to do it. And some architects as engineers only make things that are structurally possible because that's their training, and then they can make beautiful things from that, but I feel like they wouldn't go outside that constraint, because it's not part of their ethos.

Linda, you were gonna say something.

I know nothing about what you do. Does the architect then have to just have a basic understanding for how physics and the universe works? [chuckle] How much does that come into play? It seems like they must have to know something about what is structurally sound.

Oh, yeah.

It sounds like you're saying that...

I think, absolutely, they do, but I think there are some architects... I think Frank Gehry is a great example of somebody who will definitely pick form first, create a sculpture, and then it's not like he's gonna build something that will fall apart, but he will work with engineers to make it possible, and ignore the constraints of current technology, and maybe push forward and create new technology for that reason, but I think a lot of architects probably would see that as unreasonable and just go with, I'm gonna build something that is both the thing I wanna make and structurally sound and possible. And I think you're gonna find most architects have a very sound understanding of construction and physics and whether a building falls over.

I just think that this is something that doesn't get talked about very much, that I didn't really know about until I got out here, is just how important internal tools teams are. And maybe you could speak about that and what that's like in architecture a little bit, because I know some people who work at Pixar and they're just creating internal tools for artists to use.

I can't speak to that too much for architecture. The thing I've done is worked with architects to do graphics inside their buildings. The things I'm more worried about would be... Oftentimes, you will work with a structural engineer or you'll work with a production team that is gonna do the engineering to build it, and you're worried about, Will the sign fall off the building and kill somebody?

Yeah. [chuckle]

Which is bad. That makes it a bad sign design.

That's always my number one concern. There aren't that many things that a graphic designer can do to murder somebody, but that's one, [chuckle] so that was the one I took seriously. I don't do that at all anymore, really, but that was a thing I did for a period of time, or worked with other people who were better at it, and I learned a little bit of how to do that.

And what's interesting to me about there's two different ways to think about what design is, and one way is this is the flag post in the distance. This is the ideal. This is what we're shooting for. Now let's put all of our resources to the test to see if we can get as close to this, and I think of concept cars. You go to some auto show, and they have these concept cars that look crazy and otherworldly, and then they get put through the normalization of, well actually, aerodynamics, well actually, how these parts are made, well actually, how much it costs to make a fender look like that, and they pop out looking like Camrys every time.

There's that idea of, we're using this as the meter. This is the goal, it's ambitious, and we're gonna try and use production as a means to produce this amazing thing that might have been designed almost in a vacuum without an awareness of that. It's a goal, realizing we might have to change some things to make it actually happen, but the idea is that it's something in the distance versus the idea of we know what's possible, we're going to work within those constraints, and we're going to figure out practical, efficient, beautiful as well, solutions that are part of that conversation. I, as the person, designing this building would never draw something on a piece of paper or in a computer program that could not be built, because I know it can be built and I'm gonna be aware of those limitations.

Actually, this is where I got this idea that maybe knowing everything about the constraints of the material, or about construction, or just building actually can be detrimental sometimes. The most exciting stuff I've seen end up get built was an insane idea that at the beginning started with a meeting with the production team going, This is crazy. There's no way this can happen. And then eventually working towards, Oh, okay. Here's how we're gonna make it work. But it needed that crazy idea to start with in order for it to ever happen, because if you just said, Nope, not gonna happen, and then started with the one that we know works, the wild thing's not gonna get built. That hurts my brain, because I don't like thinking about design that way. I like thinking about design as, you know your materials, you know what you're doing.

It's a lot more comfortable.

It is more comfortable, but...

Is design supposed to be crazy? Or at least digital product design, is it supposed to be wild and innovative and mind blowing, or is it just supposed to be communicative and let people get the job done efficiently?

There's so many products though. How can you say? I think some things do need to be wild and mind blowing, because they are representing something different than... I think of it in the way I might think of... I'm trying to think of an analogy.

It's tough, because I want people out there pushing the limits and trying to make things that are new and interesting, but also I wish less people would stop trying to push the limits and make things new and interesting. And would just make things that everyone knows works because sometimes I feel like every time I go to a website, everything scrolls all wrong and wonky and I'm like, Great! Super duper! This is the worst! I live in the weird internet hell.

I feel like we complain when people do new and crazy things and we also complain when people put gray rectangles and green rectangles together, like those...

Well, yeah. That's what I'm saying, I'm being hypocritical. In that I want people out there pushing the limits but then, I see it sometimes and I'm like, Why did you push the limits? We knew this thing already worked, why didn't you do that? So, I have this conflicting battle inside of me.

There's another level of pushing the limits that we haven't talked about yet. So, we've talked about designers or architects without a knowledge of the form doing crazy, wild things and that's fair, we see that in graphic design, especially we see that at ad agencies and stuff. And then we've talked about designers, architects knowing the material producing... I don't know what you... How would you say it? Like stale or sensible designs? Because they... How do you know it's achievable and they don't push it. But what about technologically enabled designers producing crazy things that would never ever have been possible without the machines? And I'm thinking about AI, in this sense, I'm thinking about... Did you see that industrial design thing the other... Maybe that's a couple of months ago where it was like a structural optimization thing where the machine designed a crazy, crazy 3D form that a human would just never, ever think of. And I'm thinking about machine-aided creativity being more exciting than human initiated or human driven creativity.

Well, that's the thing, there is a really important balance because anytime you get that concept design for something that is not at all rooted in any sense of reality, it's just fluff. It's not even a thing. Somebody draws like, What if your phone was inside of your hand and it just shot laser beams out and that's how you can make phone calls? Like cool, super. You're not being a visionary interesting designer, you're just inventing things, which that's a valuable thing in its own right but there's a difference between science fiction and making things up and actually being somewhat aware of the limitations but pushing them. And to bring it back to your original Jony Ive reference.

I think you could make the argument that Apple is largely dictated by the materials, but I think you could also make the argument that it's the exact opposite that they're like, We have this paradigm shape. Steve Jobs was like, Put my computer in my palm, and they were like, It can't be done, and he was like, I don't give a shit, do it. I'm a mean guy. And there's all at once this somewhat reasonable like, We have to actually build this thing, but also this willingness to say, We're gonna try for something that may not be conventionally considered possible. And then, that's that sweet spot where, you do actually get to make unique and interesting work because you're not just dreaming of nonsense. I don't mean to sound so harsh on fiction because fiction is valuable too, but not in this particular context I would argue. There's a sweet spot there and I don't know how to put boundaries around it.

I was gonna say I generally, I agree with the frowning upon the nonsense concept idea that's just like, All right, you're just being novel, but I can't say I'm not fascinated about the idea of using something random to come up with a new idea or using a computer trying to tap into something about the randomness a computer can generate that a human just couldn't. And what do we call creativity? Is creativity connecting ideas or is creativity seeing something totally brand new and it gets even more exciting when you let a computer do it too, or you can create a computer that can do it too?

I definitely subscribe to the everything is a remix theory, creativity is combining two or more existing things into something new. Computers are pretty good at combining lots and lots and lots of permutations of things and... I got pretty cynical of generative design or algorithmic design a couple of years ago when it was like, This is a random design generator that just splat circles on the screen.

Everything is a fractal, welcome to fractal town.

If we can use informed design tools to help us, like augment our intellect rather than constrain us, I think that's pretty interesting.

Because the way I think of coming up with an idea is in some sense is very robotic. I don't think coming up with an idea is walking through the park and just hoping it pops in your head. I think it's doing it like 20 times, doing it 100 times, and then picking the best one. And that is very much like what a computer can do. I'd like to think that I'm better than that because I have experience but, doing something many times and then pulling out the one sounds very robotic to me and that's kind of how I like to do design work and come up with new ideas. Do you guys also do the same thing or is that just totally foreign?

I think there's a lot of repetitive stuff that we do day to day that we shouldn't need to do. I think there's a lot of like exciting things about design that get masked because we have lots of road work to do and I think... At least let's use... Let's build better tools to enable designers to do more of the fun stuff. Whether or not that is writing code or not, I think there are better tools that could be created together.

Yeah, and I think that design informs design a little too often. I think a lot of times I'll see people get a project and they'll look to ways that it's been done before instead of looking to the thing that they're actually trying to make. And I don't know, I think it's something that we all need to challenge ourselves on a little bit more. Because it's easy to live in the dream world, where you're designing the iPhone in your hand but I think that there needs to be something between that and the annoying website that scrolls 19 different ways. It's like let's push.

Or the boring website that's been done a million times like, Look, I put a big image in the background and covered it with a semi-opaque black rectangle, and put big white text over top of it, and everything's centered. Yeah, we've all seen that. So I have a proposal; I think maybe here's what it comes down to. I always like to try and figure out... This is probably a situation where there is not obviously one way that is better to do it. I suspect that there's probably just a certain nature to the work that is made in either way. There's probably value to the, We're gonna sit down, we're gonna dream big. If we're not ignorant of limitations of production already, we're going to free ourselves of them, we're gonna ignore them for now. We're gonna design in a way that is ambitious. There's value to that, there's probably certain projects that are suited to that, and there's probably a certain nature to that work, in the same way there's probably a certain nature to the work that says, Alright, well, we have a practical problem to solve. Let's sit down with the tools we know we have available to us, we know we have dominion over, and let's just make it happen.

I'd be remiss not to mention, for listeners that aren't familiar, this was tried very much in architecture. Samuel Mockbee was the architect who ran something called the Rural Studio, which basically took architecture students that were in architecture programs, and put them into situations where they were designing and manufacturing and building small buildings for people in need. And we'll ignore the social whatever aspect of it because that's not what I'm interested in at this point. What I'm interested in right now is the idea of a big thesis of that program was you, as an architect, should touch the building. You should be physically involved, you should be close to the material. And you look at those projects, and I don't know how successful, long-term any of them are, how actually practical they are, I don't know if they leak, but they're beautiful. They're beautiful experiments and simple architecture that's made relatively easily. And so, I have to just assume that there are projects that are suited to both of these approaches, and there's a time and a place for each. And so, I'm just curious what is that time and place? What is the context? When should you not be ambitious and reinvent the wheel, and ignore production? And when should you pay close attention to those things?

Well, I think if you have a client, and a budget, and a time constraint, sometimes, that's not the best time to completely reinvent how the Internet works.

Make sure you're getting paid is number one. Once you got that paper, then you can decide what you wanna invent.

Let's be reasonable.

I agree with that. So we're drawing this dichotomy between the things you do for play and things you do when the time is ticking. You wanna be as efficient as possible, and have a good grasp of the technology when you're doing things on someone else's dime. Then I also feel like the projects that I've done that I'm the most happiest with is things that I've done on my own time when there is no budget. And those are the things where I've not quite reinvented the wheel, gone somewhere to do that. And those are things where I've coded stuff as well. I think I'm more creative when I code rather than less.

For me, I think... The thing I always say in the office when we're talking about these things is I always say that you can justify a new design if we're talking about a new thing. This is not a new thing. Don't try and make a new design for it. If we're just making a contact form, don't try and reinvent the contact form, probably. But if we're talking about an actually new thing, here is a unique aspect of whatever entity we're designing for, we're trying to represent that is somewhat special, or at least, you wanna draw attention to, then yes, let's let the reins go a little bit, let's maybe do something that takes a little more time to implement, that's a little bit less aware of, limitations, because that's where energy should be focused. And that's, I guess, where my frustration comes from when I see somebody that's totally reinvented the one-page restaurant website where everyone just wants the hours and the stupid address. It's like, Great! Cool! Glad you poured your totally reinventing juice into this problem, and not something that maybe you could've actually used to be totally reinvented. And I don't know if that's just jaded...

But what are you so frustrated about? What are you so frustrated about? Because where were they gonna pour that? Did you think they were gonna get... Maybe the one job they got was the restaurant page, and they tried to make the best goddamn restaurant page they could make.

Aww. I like that. That's sweet.

Is that bad?

I like the guy that designed that restaurant page. [chuckle]

I feel it's that way sometimes where sometimes I'm working on something and it needs to be efficient, it needs to be done in a certain period of time, it needs to be done on budget. I'm like, Okay, I could do that. And then, I see something where there's an opportunity where I go, I could go the extra mile. I could make something a little bit wild. I think that the client's gonna like it, or, Maybe I'm just making something for myself. Maybe it's a little bit silly to put this much time in, but I have an opportunity here.

I do think there's a difference between putting the extra time in, going the extra mile, and being ambitious or experimental. You can go the extra mile and not reinvent something. You can just do a really extra good job of all the things that are the aspects of even a simple project. So I don't know how to draw the distinction.

You can be a professional and communicate with people, and deliver things on time, and manage expectations, and all these crazy things that you don't need to be some virtuoso dude wearing a turtleneck in the corner.

You're the da Vinci of web design.

Yeah. Lots of beautiful websites that don't fly even a little bit. Don't even bother trying to build those websites, they don't fly. Yeah, I don't wanna be that guy that's just being salty about, What the young kids are doing on the Internet, but there is something about, I think, to the idea of focusing your effort on the things that are deserving of being rethought. And that's where I draw the ledge for myself in my own work is like, Am I gonna spend a bunch of time trying to do this thing that's been done over and over again way differently? If I think it's working okay, probably not. But I am gonna focus that time on trying to do something that maybe is unique or special in a different way. But I think we should go to our final thoughts, last segment. Whatever are we gonna call this? Gosh! We need better names for things.

Yeah, you've wondered what we're gonna call this for five episodes, so I think it's just gonna be the...

I'll have to... This is a job for me; I have to come up with a better name for this segment.

Call it dessert.

So, yeah, my closing thing is just that I'm always interested in reading about, or hearing about, or learning about the process of other creative industries, because the same relationship between vision and production, to use it more abstractly, exists in music, it exists in filmmaking, like there's something you want to make, and you've got some idea of it, you figure out some way to communicate it to people, and then sometimes other people will have to be the ones that make it. And I'm not an expert in any of those things, but I always find some little nugget of truth or universality when I'm listening to somebody talk about how they're working with whatever production studio to make something. So I always value looking outside of whatever little bubble we're in to try and figure out what this relationship actually might mean on a bigger level. Matt, closing thoughts?

I think my work has gotten better in a functional way, as I've learn more about...

Matt's closing thoughts, I think I'm good.

I think I'm fantastic at this thing.

I do a good job.

No, I just think the concept of understanding leading to a better final piece, I do think that's true in a functional way, but I always have to wonder if I'm doing the most interesting work I can by knowing that there's a more efficient way to implement something. And so, I don't have an answer but I'm gonna continue to struggle with that of, I think I can do a better job in a business way if I understand better, but I don't know that that translates to a more interesting or groundbreaking design.

I think that's a great point. That's what gets selected for in consulting work. It doesn't really matter.

Unfortunately, design just means art and business, so maybe I just defined it right there like, Yeah, exactly Matt, you're supposed to do good at business, that's what design is. But part of me sometimes just wants to make a weird thing and an interesting and a new thing and I don't know that that's helping.

It's hard to do that in the consulting world. Jon do you have any closing thoughts for us? Any dessert?

I've had several good conversations with architect friends recently. We are coming back to architecture here, where they've been like, Oh my God, I've just been reading all these articles about UX and UI design and blah blah blah, on Medium and one, oh my God, your industry is so cool and open in its sharing of information. I think architecture is a very confined, very siloed thing where people keep their cards close to their chest. And the other thing they say to me after that is, It's so cool that you have this insane feedback loop where you can think of something and you can build it that afternoon, whereas they might be designing a bathroom unit for a skyscraper that will get built in 20 years time. And I think, if anything, we should just be tending towards the strengths of our industry. If people are looking out from industries we aspire to be in, and we're like design nerds, we love architecture, and the architects are being like, Oh my God, digital product design has these traits that we love, I'm just like, Dude, let's just keep pushing for that as far as it goes because it seems like we're on to a good thing.

Grass is always greener.

Grass is green right here.

My first job at a design studio was run by two architects that started a graphic design studio because they were like, We want to be able to design something, and then print it out and put it on the wall, and have it be done because that never happens in architecture, we never get to do that, and we just want some kind of sense of conclusion to something in a reasonable amount of time frame.

That's awesome.

There are things that I designed as an intern in my very first job that I think are still not built.

Wow.

Yeah, well.

That's sad.

Linda put that cherry on top.

Maybe I'm just the sensitive one in the room, I don't know. But [chuckle] I think that it's all about people. I think that if you're interested in things you should follow those interests and learn as much as you can about everything that you're excited about. But I also think you don't have to feel guilty or ashamed if you're more into lettering, or illustration, or whatever than you are into coding. And I just think that as long as you follow those things, and really pursue them then that's great. But then, if you are ignoring learning how to code, then you need to develop a really good relationship with the person who is coding it, even if you have to set up a list of guidelines and just talk to each other, come out of your hole and talk to each other and figure out the best way to work with each other. And, I don't know, I'm always surprised at the ideas that come up when you're actually working with somebody else. It's always, I don't know, it makes me happy, it's always better.

That's the thing I feel like at our company, design and project management are synonymous. We don't have project managers, it's just the designers because they're the only people that are touching every piece of it. And so, that communication is, I feel like that is design in so many ways, like your job is to communicate what this thing should be, you can use words, you can draw pictures, you can use mock-ups and prototypes, it doesn't matter what you use, but your job is to communicate that to all parties involved.

Totally, and some developers are different than others. Some prefer it to be written out, some prefer a sketch file with every tiny little thing written out, but yeah, just talk to the people.

Linda and Jon, thank you for joining us from different rooms in San Francisco, it was a real pleasure.

Aww, thank you for having us.

Thanks for having us.

What is each of your respective favorite social media platform where listeners can find you?

Twitter.

On Twitter?

Yeah, I'm on @littlenono. I think that's what happens when you choose a name and just stick with it for nine years.

We're gonna make a good compilation of all of the contributors saying they're internet handles and websites out loud. We have you saying little no no, we have Meg saying her website is butts.guru.

We've got all kinds of good stuff.

And that is why I love Meg.

When you bought that domain or you registered that name, you probably didn't think you'd be saying it out loud but there it is, littlenono on Twitter, Linda is the best. Jon, where should people find you?

I feel like my personal brand is also strongest on Twitter so @jongold, J-O-N.

Personal brand. Can we talk for an hour about personal brands?

Really strong last name, by the way, Jon.

I feel like we, Andy, I feel like we rocked the web domain thing as well. Jon.gold.

Oh yeah, you probably both have dot gold in the...

Yeah.

Dot golds, right?

Yeah. I just got the renewal notification. It's been one year since I bought man.gold...

Wow.

And I have done nothing with it so...

And it costs about $7,000 a year but it's so worth it.

It's like $130 a year but you know what? It's worth it, except it's not worth it because I've done nothing with it yet so...

Who had the idea first?

There's another year to light a fire under my butt.

Was it Andy or Jon who had the idea first?

Me, me, me.

Who copied who?

I don't remember. Jon probably did it first.

So everything is a remix?

Jon probably registered it first.

But it was just Andy remixing Jon's brilliant idea.

This has been Working File. As always, you can follow us on Twitter: @workingfile, pretty easy to remember.

This week I'm gonna issue a challenge too. I want everybody out there to go on Twitter and tweet at somebody and tell them what you thought about this show. Maybe it's me or Matt, maybe it's a contributor, maybe it's some random person that has never heard it before. Just say something to somebody about it.

Prove your existence to us, please.