How Designers can be Better Partners
This week I'm lucky enough to chat to Dan Mall, designer, CEO and founder of SuperFriendly and Arcade, author and all-round nice guy. It's another one that I could've spent hours talking to Dan, but we managed to keep it to a tight 40 minutes, chatting about how designers can improve their workflow and worldview to be better partners to those who work with, especially engineers. We talk about the concept of hot-potatoing, what an agile designer actually is, and how being a building a better design team usually means focussing on the human element of your designers.
- Dan on Twitter
- Stand By Me, Ben E. King
- The Count of Monte Cristo , Alexandre Dumas
Luke: So I suppose to get started a good place to always start is the beginning. So Dan, what was your path into design?
Dan: I went to design school but before that even, I used to draw a lot as a kid. When I saw Toy Story come out, I was like, I want to be an animator cause that movie blew my mind and I knew I wanted to do something with computers, I knew I wanted to do something with art, I didn't know graphic design existed. So the natural path seemed to be like, oh, movie-making and animation and things like that. So I always loved that and then through going to school for animation I discovered graphic design. And at the time I discovered interactive design which at that time was Flash and Director and HTML and DHTML, and all that kind of stuff. And I just fell into doing that stuff because as I think a lot of people in this industry, when you're the person who like, Oh, you know, computers and you're around at that time, people like, can you build websites? Can you fix my printer? And you just go like, yeah, I'll do all that stuff. And so I just kind of fell into all that.
Luke: It feels like that is, especially for people of a certain age, which I think we both are, it seems to me the really common way of getting in, is just kind of like falling in through starting to use random suites and products because you're interested in it and then go, oh, wait, people are going to pay me to do this.
Dan: Yeah. And because they're available too, right? Cause I remember my cousin coming up, my cousin worked in IT and I think I was in seventh grade or something like that. And he came over one day and he said like, here's this piece of software, install it and then use it. I was like, okay, I didn't even know what it was and it turned out to be Photoshop Two. And I'm like, all right, great. And then just you tinker around and you figure some stuff out. And then he did the same thing a year or two later with Flash, you know, here, use this thing. All right. Great. And it's all pirated stuff, all illegal software, but you just, you figure it out and I'm sure we'll get into this a little bit. Yeah. Like I have a lot of nostalgia for that style of working. And I actually try to do a lot of that nowadays in figuring out and teaching designers and developers, how to collaborate. I think there's a lot of good things that came from that style of working a lot of bad things too. But I think there's a lot of good that can be brought into the way that we work now
Luke: That is it though it's like, I feel like that way of working is born out of curiosity, right. And it's born out of just trying to figure things out and figure if things work and whether they feel right and, I dunno, I do feel like even if they don't feel right, I know I spent a good three years pretending that I was a front end developer, before realizing that those skills aren't really in my skillset. Now I have a great understanding of how they work or what their problems that they face that.
Dan: Totally. I think there's a lot of value in reducing the rigidity. I mean, I think like that was one of the nice things about, you know, I'm at the risk. back in my day, you know, so I'm going to try to temper that a little bit, but I think there's a lot of value in, back in my day, there wasn't clear lines between what was a developer and a designer and a front end developer and at that time when you were building websites, you built the website, you know, you did the design, you sliced it up in image ready. You pulled them together in tables and you know, you wrote the CGI scripts and the Perl scripts and all that stuff. And you made it work and you made it happen. And I think now we have cleaned that up so much that you just lose the serendipity. Like I think at that time, you did a lot just by happy accidents. And I think we have tuned our software so much to this point where you can no longer have accidents in it. And that's, you know, there's a lot of value that comes from that. A lot of good things that come from that, but there's also bad too. Like you can't have an accident in the tools that we have now it's just harder to do that. And I think we've lost that. I think that is a loss.
Luke: I know that you've been talking a lot about, and you mentioned it earlier, but a lot about how designers and developers collaborate and work better together. And I think that, I suppose what you're getting to there is, the fact that it's, that kind of like messy state of being of just, you know, testing things out and seeing what works is where those happy accidents and the creativity really comes from. So in terms of like, what are the problems at the moment? Cause I think a lot of it, you know, it seems to be that it is this big delineations between the two, parts. It's usually there's very little actual collaboration, people like to talk about working in agile, but it's actually just faster waterfall. Is there actually a problem with this? Like what are the, what are the pros of doing it this way?
Dan: So there are obvious problems with it. I think you could look at the state of the world and the role that digital products have played in that. And if you look at the world now and you go like, yeah, everything's fine. I mean good on you, you know, but, but I think everything is not fine. And I think that the digital tools and products have a lot to do with that, like social networks, social media, work culture, tech culture, all of that stuff is broken. And I think there's a lot of things that are not optimal there, right. So, if we look at that and we go, okay, how are things going? I'm a big fan, you know, my wife says this a lot to me, like we're big fans of the Dr. Phil approach of like, well, how's that working for? You know, if everything's good, then you should, everything should be good, right. But if everything's not good, then we got to change something. Something has to change. And I think that if you look at how it's going right now, it's not going great. People are burning out. People are exhausted at their jobs. they're depressed. They're overworked. All of that stuff is because of the culture of work that we have. And I think the culture of work that we have is because if you look at the incentives while we have to ship, ship, ship, everything has ship at the expense of people generally. And you know, that's why I like design systems work so much is because of highlights people again, you know, and design has stopped doing that, development, engineering has stopped doing that product to stop doing that and I'm overgeneralizing a bit. But I think that the people side has gotten lost in all of it. And so we have to highlight that stuff again. So that's, that's my overall take. But things are broken and I think that one thing that helps that is to highlight people and to focus on people working together again and more closely, more collaboratively, more fun, more looseness, you know, all of that stuff is lost in our culture of work.
Luke: Well, I think this is the thing, cause it's like, having worked in a bunch of product design teams in the past is you do is really tempting to get into strict processes, that don't have much room for play or, pragmatism or like actually not every problem requires the exact same process, right. And requires the exact same rigor. I suppose this goes back to the collaboration thing there quite often really internally focused on like one team and you end up with this beautiful idyllic process that just breaks down in reality. Cause I know that you were just at Clarity Conf you were just running a workshop on like how to do this true agile approach and sort of work collaboratively. I mean, I know you are a scrum master, so.
Dan: It's true. I am. Yeah, I am maybe the only creative director on the planet that is also a certified scrum master. Yes,
Luke: I mean most creative directors I know, would usually run away from that as fast as possible. I’m really interested in your approach to what do you think could be better? Cause I've definitely got some ideas. I want to hear what yours are and then bounce off them.
Dan: Yeah, sure. So I spent a lot of time talking to designers and engineers specifically, product folks a little bit less, but they're the other leg of the stool, the three-legged stool product and engineering and design. So, certainly not excluding product folks. But designers and engineers are generally the makers in that group. So I tend to focus on the makers partially because that's where my background is. I'm a maker, I was a maker, I was trained as a maker. So I spent a lot of time with designers and engineers trying to show them and expose to them that they're not actually listening. The process of them working together, isn't actually working together. And so, you know, that comes through the form of workshops and writing and the coaching that I do with my clients. And a lot of that is just to go the processes are so separate, you mentioned it earlier, Agile is generally an engineering thing and I don't think it has to be, if you look at the Agile Manifesto, right, there are four big principles. I forget what they are off the top of my head, but only one of them actually has something to do with the output, right. All of the rest apply equally to design as they do to engineering. The one that doesn't is the one that says working software over comprehensive documentation. And that specifically then calls out designers, which is why I love the Agile Manifesto as a designer who was always like, want to improve my skills or learn something or learn something new or try something new. I'm like, oh, shoot, as a designer, I actually don't work on anything that is working software. Like, if I'm working in Figma or Sketch or Photoshop or Illustrator or whatever, I'm not making software, I'm making other things that are cool and valuable, but I'm not working on software. And so how do I, as a designer actually start to work on software. If I'm in Figma, I'm painting pictures of software, like I'm literally painting. And that's how I describe it. When I talk to teams, I go like, all right, let's paint and you know, some people are like, yeah, cool and some people were really offended by that, but It's accurate, you know. It’s true, we’ll paint for awhile and then we'll make software. And that's why Agile generally doesn't work because it doesn't take into account, well, where does the painting come in? Because the painting is valuable, but we have to know where to put it. So a lot of the work that I do in the workshops and in the training is, where do you put that? Where does it go in the process? And I think a lot of people, you know, I very rarely do I find someone who is like, I don't want that to be part of the process. It's like, Yeah, I want it to be part of the process. I just don't know where it goes, which is why we don't do it. So if we could just show people where it goes, all right, well, it goes right here and then you do this other thing and then you do that thing and then you do this thing again. And, you know, that's the thing that I know you had Brad Frost on the show a few weeks ago and like, he and I teach the same thing and we teach together often, which is this hot potato process. The idea that like, it goes back and forth, you know, and that's certainly different from waterfall. And it's certainly different than Agile in a very particular way. In Agile, it does go back and forth, but it generally goes back and forth between product and engineering or engineering and engineering. And they don't know where to put designers in that and so designers go like, well we'll just do our thing. And engineers go you've already been doing your own thing, right? So it just perpetuates that divide and instead if we can bring people closer together and saying like, how about you take this for the next five minutes? And then we'll take it for the next five minutes or the next five hours, but not the next five weeks. Or even worse, not the next five months. Cause that's what our silos set us up to do is designers spend six months designing and making perfect and 78 art boards and you know, all that stuff. And then designers go like, all right, we figured out every well of all the states, all of this, like everything is figured out. It's specked and then engineers get it and they go, what about this. Designers go, like gahh, I missed that. So why’d you just spend six months doing something, If you, if you miss stuff anyway, you might as well spend six days doing it, if you're going to miss stuff and then share it. So, anyway, I'm getting ahead of myself here, but that's the general gist of it.
Luke: I love the concept of hot potatoing by the way, I think it's like, I've heard it before people talk about, stop talking about handoff, it's a handshake because it's continual and it keeps going and it's like, same concept, cause it's one of the things I’ve struggled with in the past, because, you know, having been in both the sort of developments spheres, well, a little bit in the devs spheres and the PM sphere, and then going into product design, basically seeing all the parts of the pie and seeing all of the problems that exist in the communication between these teams and also all the overlap of what these people's jobs are. But, if you look at it in the concept of, okay, so we're designers, we design things, what does that actually mean? It's designing solutions to problems, right.
Dan: That's right.
Luke: Engineers do the exact same thing.
Dan: Exactly. Yes.
Luke: Yeah. And more people helping on design problems will usually make the end output better, especially if those opinions are diverse, right?
Dan: That's the thing that we've lost, we've lost sight of the fact that designers and engineers actually do the same thing. They do it in different ways and there's room for that. But I think once we started accepting and cementing and working like, oh no, no designers do this thing. And then engineers do this other thing, then they became separate tracks. And I think that they're not, you know, as you said, they're not separate tracks, they're the same track, they're just different ways of accomplishing that, which is the point, which is like, there are some things that are incredibly hard to do in a design tool that are so easy in an IDE and vice versa, right. The example that I always give is, I remember designing stuff in Sketch, and it's a little bit easier with Figma now, but even still it's still difficult where you have a grid of 60 cards and you have avatars in those cards and buttons and then some stakeholders says like, can we change the text size in those cards? And you're like eff! like, cause I didn't set it up that way. So now I have to go and 60 cards and adjust the text size, Oh, and now I have to adjust the bounding box and like all this up and for a developer, that's one line of CSS.
Dan: Because the tools are meant for it. You know, HTML as a tool, the browser as a tool has this concept of flow, which we have to build into Figma. We have to set it up to, but the browser doesn't have to be set up to do that. So why not take advantage of that tool? And so if we see them all, as we're trying to do the same thing, we each have proficiency in different tools, let's work together, you know, to try and do the same thing. That idea is buried, it gets buried more and more as we, deepen our silos of design and engineering and product.
Luke: I think it's one of those things where I think it's also, it's like more accepted for, I don't know, every design team I've been in, there's always been that, let's get the engineers involved as early as possible. There's always that nice belief, right and obviously, it doesn't need to happen but also it's like, I liked the idea, I know Brad was talking about it with like front end engineers talking about them as like UX engineers or they're part of the design team and they're part of the design process, similarly, designers should be taking an interest in how they do their architecture design and how they do their software design, because they may actually bring some insight that will help them down the line. Because even though, you know, I think that's the thing, it's like a lot of people they have to have good ideas and they have good things to contribute to the entire problem space. But in their silos, they're just then not encouraged or rewarded for actually getting involved.
Dan: Even further, they are discouraged from it, right? Like the incentives that are there, basically say, if you don't ship product at this clip that we have all agreed on, you’re fired. Or something else, you know, equivalent to that, like, we will look down on you, we will think that you're not as good as you are, as we want you to be like, there's all these factors that just weigh down on people, then that makes them feel like, ah, I gotta work extra hours outside of work. I was just talking to a friend the other day who was talking to me about, he just got a job at an agency and he's like, I think the culture of the agency is that everyone has to do work at work and then do work at home. And he's like, is that weird? I'm like, yes. He's like, is that normal? I'm like, yes. Like, that sucks. You know that in order to keep up your job, you have to do work outside of your job. Like some people like that, which, cool, but some people don't and why would we have a culture that forces them to do that in order to just keep up with everything? It's such a sad state. And I think a lot of that is the pressure that goes on engineers to go like, you have to be good at engineering for designers, you have to be really good at design. And so you don't have time, you know, if you're a designer, you don't have time to learn JSON, if you're an engineer, you don't have time to be part of the design process, cause you still got to ship your stuff and if you don't there's penalties. So would I try something new in that environment? No, thank you. There is no psychological safety there at all, I would rather not do that, I'll collect my paycheck, I'll do my job, I'll go home. If that is already too much pressure, why would I add more to that? And like, that's the context that designers and engineers and product folks are in now. And we have to change that dynamic before we can expect people to change their behaviours.
Luke: Yeah, I mean, this is also why I'm getting excited about the fact that you know, DesignOps as a concept is coming up as well, because I feel like it's putting a renewed focus on things like good org design. Because you're right, a lot of these are systemic issues within company culture that it's just taught as, this is how you run a good product which is bullshit. It’s how you ship something fast and then probably fail a little bit down the line, because everybody gets burnt out and leaves. For anybody listening who's interested in this, I definitely advise going back to season one and listening to the episode with Peter Merholz about good org design, because it's one of those things. If you don't set your org up in the right way and have your leadership at the right sort of level and all the rest of it, you're screwed from the start.
Dan: Totally. And that's what I love about, you know, that book that he and Kristen wrote really exposed the idea that you have to create the environment for success for teams. Like if the environment's not there, it doesn't matter how good of a designer, or an engineer or a product person you have, they just can't be successful in that environment. So the environment has to be conducive to good work and that's not just, you know, I have sort of a love, hate relationship with DesignOps. What I love about it is the fact that now there is a dedicated role to supporting the things that designers need to be successful. And I think, you know, that's tooling, that's training, that's support, that's comradery, that's an environment of critique, that's all that stuff, but it's also being able to say like, you can try stuff, it's fine if you mess up, it's that stuff that to me is just as important as the tactical support and the tangible support. And so some DesignOps teams do great at that. And some have a lot to be desired still, you know, at that. So I like where that is moving and I think that's a great thing, but that environment has to be there, otherwise, people aren't going to venture outside of their lanes and the lanes right now are very rigid.
Luke: I hear you on the DesignOps piece as well, because I think it's like DesignOps as a concept is amazing. I think part of the problem is a lot of the time DesignOps as a function or as a role is usually only reserved for the big organizations who have and a lot of them, not all of them, a lot of them have very entrenched, pretty bad culture.
Dan: Totally. Yeah. That's one of those like, blame the implementation, not the technique thing, which is like, it's not the DesignOps as a concept is flawed. It's just that some people don't implement it well, you know, not out of ignorance or malice or anything to that, but just because like maybe, you know, maybe it's the first go at it. So I think that is what's really great about DesignOps. I think the beef that I have with certain implementations of DesignOps is that it tends to support the current way of designers to work. And as we've just talked about, I believe that that way is flawed. So I'm like, well, why would we continue to support a flawed way of working and naturally the DesignOps organizations that are actually changing the way designers work and then supporting that new way, I'm like, yes, I'm all for that as opposed to like, let's help designers continue to do what they're doing right now. But what if that's bad though, what if that's actually leading to, you know, it's furthering some of the problems that we have. So that's why I think the more progressive DesignOps organizations are ones that are going like, but we have to change it first and then support that change and I think that's hard work.
Luke: Yeah. I mean, to be honest, it's what, whenever anybody says, how do you do it when you get in there? And it's like, treat it like a product, you figure out what the problems are, you try and solve the problems and you iterate on that and do it until you've got markers of, I mean, you know, we've got great metrics in DesignOps. Are your people happy and sticking around and still producing quality work?
Dan: Exactly right. It's like our industry has internalized the fail faster culture, you know, I think it would be interesting to visualize what are the companies that go hard on fail fast culture and then what is their firing rate? Because if you fire anybody, I mean, are you really allowed to fail then? If you fire anybody for anything other than like insubordination, I guess like there are those kinds of things, but if you fire anybody for, not knowing enough or not shipping this thing fast enough, didn't they just do what you encourage them to do. So, you know, I would be curious to see what that visualization actually looks like.
Luke: Oh, yeah. I want to get that data.
Dan: Yeah, me too.
Luke: Okay, so I suppose, cause I'm really interested in this idea still of this like collaboration, especially between designers and engineers. Because I think you're right, it's one of the places that somehow worked in the early days and is now just becoming this wider and wider gulf. And I think part of this is, I don't know whether you agree or not, but I feel part of it is because design teams are still relatively immature, maybe that's a harsh word, but there is this lack of maturity in that design teams have only really started to get to a point where in the last eight or nine years we've got there, whereas engineering teams has been set up for 20, 30 years at least. And I feel that there's this fear that people aren't creating enough and justifying their worth. And we end up with loads of bullshit artifacts, forgive my french, that almost make them feel more secure and you've talked about the fact that we need to get away from this artifact producing culture and cause I dunno if this is something that's taught in schools, I have no idea where it comes from, but I mean, do you think there's an easy way to shift the mental model away from an artifact creating culture and what do you think we need to do to actually get away from that? Do you have any practical advice for somebody trying to sort of shift their org away from that?
Dan: Yeah. I mean, I'll say, I don't think there's an easy way. I think there are ways and I think there are practical ways and the thing that I can share are baby steps, how do you start that? But it's certainly, it's easier said than done. I think the steps are simple, but I think they're very hard to implement because of the culture that we have. In just talking about that, I think what makes designers good at being design, at least generally is that we are known for output, right? That's how we got good at design, whether it's design school, formal training, or that's just like, I followed a bunch of YouTube videos for years and I just started making a bunch of comps and design. We get good by output, it follows a lot of psychological trends and things like the 10,000 hours rule, which is like to have mastery over something you have to be able to put in the time. And that time for designers is producing, producing, producing, producing. And honestly, that's the way that I train designers is, all right, make a lot of stuff, so make a lot of stuff. And so it's weird to say, so make a lot of stuff and that's how you get good. But then once you get good, stop making a lot of stuff, it's like, whoa, it's a whole culture shift now. It doesn't take a lot because when you say to designers, stop doing the thing that made you good in the first place, they're like, wait, what? So like now it's an identity shift and that's, really tough to deal with. So that's one of the hurdles in the way of that. Another hurdle in the way of that is, trying something new is generally hard for humans because there's always risks. So, we are constantly, maybe now more than ever. We're constantly weighing the risks that we take against what is safe against, what is inbounds and what is out of bounds. So trying something new is generally risky if there's penalty to it. So I think part of what we have to do from a leadership standpoint is remove penalty. So, those are some of the factors I think that go into creating that culture. Once those factors are there, then you can start doing things and this is the way that I tend to coach teams and work with teams is we shorten the cycle because I think one of the things that there's, I don't know where it came from, but there's this accepted amount of time before something can be good. So for example, if I was designing a homepage, if you gave me five minutes to design a homepage, would you expect it to be good? The answer is almost inevitably, no, like, nah, five minutes, I mean, nobody would make a good homepage then, but if you gave me five days, there would be some expectation that that would be some level of good and that's where pressure comes in. So what I found is there's this time limit that if you go below that time limit, the pressure is off. But if you go over the time limit, the pressure is on. So what I do to train is I go way below the timeline, Hey, everybody, we're going to do five minutes of work. And everybody's like, oh, okay. Because now the pressure's off, everyone design a homepage. Everyone build a homepage, everyone built a header. Right? So, and actually, when Brad and I teach our workshop and our collaboration workshop, that's the first thing we do is we say hello and in the first minute before introducing any concepts or teaching anything, we go, okay, we're going to do an assignment, build a header go, and that's it. There's no other qualifications, there's no other instructions. And we say like, we won't answer any questions about the assignment, like five minutes go. And what we find in that assignment is everybody does it a little bit different. And we give everybody, both designers and engineers, some people will code it in CodePen, some people will stand up their own React builds, some people will open Figma, some people will get a pen and paper. So all these different ways of doing things, kind of like we talked about it earlier, very different ways of doing things, but still commonalities. Almost everybody has a logo I'm like, and so what we ask is, well, where'd you get that, where'd you get the requirement that you need to have a logo. And it's like, oh, well that's just a, just an accepted thing. Where'd you get the requirement that there should be a navigation, cause most people had a navigation in there. Most people had a background color behind their editor. Most people made it horizontal. There are all these conventions that we have adopted intrinsically that people don't realize that they actually share those opinions across silos. So we try to set the foundation very early that there is a shared foundation that exists already. Design is not separate from engineering, we make the same thing just in different ways. And then we start to teach some concepts on top of that like start to unlock some of those things it's like, if we can accept. And now we're in the product design cycle because now we can do V2 and V3 and V4 and we make things better over time, it doesn't have to be good right now, but it can be better than the last version, that's product design, there's how many apps that we have that we use in this industry that are on version 68? They've been around for decades and you could still look at them and go, like, I'm not sure that this is good. Like, is Facebook a good product? I don't know. Like for some people, I guess, how many iterations?
Luke: That's a very deep question there.
Dan: Fair enough. Fair enough. I should use a Gmail, right? Is Gmail a good product? You know, like, but the Gmail team doesn't stop working on Gmail. How many iterations have been released at Gmail? Probably hundreds of thousands, you know, like we don't know and they still keep working on it. So they're making it better over time. The question of whether it's good is a weird question. Is it better than the last version is a much easier question to answer. So that's what we try to train designers and engineers to do is, together just make it better than the last version. And that could be incremental, that could be monumental, that could be all of those things. So like that's the kind of stuff that I try to break down when I'm teaching this is, let's relieve the pressure, let's do shorter bursts of work because in shorter bursts of work it doesn't have to be good. And everyone agrees that it doesn't have to be good. But if, I go away for five days and I'm supposed to come back with something. Everyone expects it to be pretty good. And now the pressure's on me and now I'm by myself and the pressure's on me, so we have to unlock and decouple all of those things. I think in order to start to create a culture where like, oh, it doesn't have to be good at first. We can make it better together over time. And I think that's a fundamental concept in how we can collaborate better.
Luke: I absolutely love that idea. It’s funny, cause it would feel weird if you're in an organization and you're actively working to be like, let's sit down and figure out what our, you know, shared commonalities are in design. I'm a big supporter of design pairing, especially design pairing between designers and engineers. Because in just sitting down and working on a problem together and it's funny actually because I didn't realize it has the exact same constraints as what you're talking about. You've usually got an hour, two hours, you've got a problem, you're working on it together, you're figuring out what your shared commonality, like what your common ground is. And yeah. It's I don't know. Do you use design pairing?
Dan: I want to point out something about that. So I'm going to Dodge your question for a minute, then I'll come back to it. What I want to point out is that what I want to call that is working. It surfaces how backwards it is that we have to come up with a term that we could market around, like, well, we're not okay, so this is not work, but this is pairing, we're going to pair. And everybody's like, Ooh, pairing, that sounds fun and that sounds like a fruit. We have to brand it but that should be called working, so to your question, to come back around to your question totally, yes I use that. I like to call it working and to me, one of my favorite points in project and product work is when we get to the point where people just consider that working. All right. Hey look, Hey, you all wanna work? And that means let's pair, let's get together, let's do a short burst to work together, let's hot potato. Working become shorthand for that until we get to that point, then we have to say, we're going to do something different, which is branding, which is why we call it hot potato, which is why we call it pairing or pair programming or design pairing, or design engineering, or like any of that stuff we have to call it out as separate. And there's a little bit of sadness in me about that, but I think like that's where we got to get back to is, the point where that's working again. So yeah, I do that stuff all the time. Sometimes it's just bumpier because people aren't used to it anymore, so we have to train it back in.
Luke: Have you found any easy ways to, because I know that I've had this in the past where, some of the front end devs that I was working with absolutely loved the concept, they thought it was brilliant, usually ones who had an innate interest in design anyway, in air quotes. There were others who weren't so keen and it's usually because I don't know, it felt like it was fear, but, have you had any experience around, like, how do you convince people, especially engineering like that they should care about this?
Dan: Yes I found that and I've found it a little bit more of the opposite way, which is that generally when I do this kind of work engineers are, especially front end engineers that are into it, they're all into it. And part of it is because I do make personally, I make a big deal about highlighting and valuing specifically the role of front-end design as an important craft, certainly in design systems work, like without front end developers, front end development, you are missing the boat on a lot of good design systems work, because that's where it comes to fruition, right? Like that's what users interact with, they interact with websites, they interact with HTML, if it's not in HTML, they can't interact with it. It doesn't matter how good the Java code is, it doesn't matter how good the react code is. If it doesn't output HTML well, there's nothing on the screen. So whenever I do this, like front end developers are yes, like I want to be more part of the design process and I'm being valued in this process. So yeah, I'm into it because I think that the subtext is now they're getting something that they wanted. I find for designers, designers are always side-eyeing it, you know, some of them are like into it, but oftentimes what I do is, I have the ability to do this as a designer because I'm a designer and so I pull all the designers into a room and I close the door, you know, and this is when we were doing this in person, but if we're doing it virtually, it's a breakout room instead. Cause designers we are, we're a precious bunch. We are a sensitive bunch. So close the door. And I say, what does everybody afraid of? And nobody answers at first. Cause nobody wants to be afraid of anything, but then eventually like once that conversation is facilitated, what generally comes out is that designers are like, well you're asking me to give up something that I spent the last decade of my life doing, like making a bunch of comps, so what do I do instead? That's the part that I think most teams don't do is, they take that away, in this hope of like let's involve engineers in the design process. Okay. So what do the designers do? And we don't replace that part, we have to replace it, we can't just take something away from designers and not put something back. You know, that was the whole premise of that Indiana Jones movie, right. That like, you have to swap it, you know, otherwise, people realize that there's something's missing. And then the rock, you know, a boulder rolls over and crushes it. We have to replace it with something. And so what I often do with designers, I go, okay, if, you give up doing comps for this project, I promise you, you get to do… what? And we make a list, you get to do more motion graphics work that you want to learn. You get to do more art direction on the photography side because you want to do that custom sheet. You get to design the custom icons. You get to put more time into illustration. You get to focus on accessibility a little bit more this time than you had. You get all these things and that's the thing that the designers go like, oh, if I get that, I would be willing to give up this other thing, even though it's uncomfortable, I would be willing to do that. And that starts to address the fear, cause I agree 100% with what you're saying, that the general blocker is fear, I'm afraid of something, so I'm going to keep what I'm doing now because I'm afraid of what the other thing is. That's what anxiety is, it's fear of the future. So if I don't know what that future looks like for me, well, no, thanks I'll just live in the present and that's like, I'm good here, unless the future looks better. If the future looks better and I know I'm getting something better, okay I'll adopt a little bit of risk in order to do that and so we have to give that back to designers. We have to say, okay, we're taking this away from you, but we're giving you custom illustrations, is that a fair trade-off to you? And for some designers are like, yes. And for other designers, they're like, ah, that's not it. So we have to find different incentives for those and that's a personal thing. So I'll work a lot with individual designers to go like you, what do you get? What do you get? What do you get? And that those are different for some designers are like, I would love to spend more time on documentation, great do that, you know? And for others they’re like, I would love to just like, you know, do animation more or do you know, whatever it is and then my job as the leader on, or as the lead on that team is to make sure that each of those people have the environment that they need to do that thing. If somebody comes to them and says like, well, where are your comps? I can be the one to step in to go like, wait, wait, I said they're not going to do comps and like take the rap for that. So I think that culture has to be there. There's some of that on the engineering side too, but I think it's similar to where it's just, it’s risk. Like well, I've never been part of the design process before, so I'm already strapped for time and trying to build this thing because we spent eight extra weeks on design, but my timeline didn't change and now you're asking me to do an extra thing, we have to address that part too, which is like, yes, we're asking you to do an extra thing, but what if we de-scope the product work so that we build one less feature in this time? Ah, okay, cool, now my schedule just freed up, so now I can do it. So we have to address all the parts of that and it's funny that what gets addressed in design is the engineering stuff, what gets addressed in engineering is the product stuff, it's collaboration again, you know, it comes back down to that every time. And I think we have to address that fear in order to actually make it work.
Luke: I think that makes a hundred percent sense. So before we head off, I do need to ask you about the, what are you excited about in like the future of design and DesignOps I know DesignOps is a touchy term for you.
Dan: Sure, what am I excited for? I'm excited for, I mean, tooling is, is great. You know, tooling is getting better and I'm excited for that. I hope that tooling gives us better ways to have accidents. You know, I think that that's slowly getting eliminated and I'm not sure that that's on purpose. I've heard a quote somewhere, I forget who it’s by, I wish I remembered it, It was from a musician and he was talking about how he plays only a certain kind of guitar and he plays a certain kind of guitar because it's slippery because it's like, he has more accidents that way, he's like if I play a guitar that's too nicely designed, I will only be able to play what that guitar allows me to play. Like I can't mess up because the guitar is really technically great, but that technicality actually allows me to only play what that guitar allows me to play. So he seeks out guitars that have, I think he called them like errors in them because it adds a character to it. And I think our design tooling is getting so technically good that it's just harder to have accidents. I hope that we build that kind of stuff in somehow, I don't know how we do that, that's why I don't build tools, but like I’m excited for the state of tooling getting better, generally, especially around design systems as an organizational culture thing, I think that's great. I think that's positive. I hope that that frees up team, I'm excited about design systems in general, maybe that's obvious, because I think they highlight people and I think that they focus on freeing up people, like let's just take the boring stuff away so that people get freed up to do something. And I think that's something is there's a, I think there's a right answer and wrong answer to it, or maybe an answer I like better than others. The answer that I like better is it frees up people to do things that are more fun. I think the answer I like less is like it frees up people to do more work. So I hope that design systems are a thing that frees up people to go, like, what do you want to do instead? Like now that you don't have to do this other stuff, now that you don't have to design tables again. What can you do? What else can you do? Well, I've always wanted to do this and whatever's at the end of that sentence that gets me really excited, whatever somebody says it at the end of that sentence, I'm like, yes, that's what I'm talking about. So those are generally things I like about where our industry is headed and you know, just curious to see what that, brings about.
Luke: I love the idea of freeing up time so that people can basically enjoy their work more. Right. It's, take away the boring bits, make the tooling take away the bits that they don't actually enjoy, or that are tedious. So they can do more enjoyable things.
Dan: And that's why I'm excited about how machine learning and artificial intelligence affect this world. I feel like we are just at the tip of the iceberg on that, but I feel like if we can figure out what's the stuff that we really should be doing and it's stuff that's really not, well let the robots do the stuff that we shouldn't do. Even better as an accelerant, you know, like, so I feel like we have only scratched the surface of that and I'm like, I don't even know what people are going to come up with there, but the little glimpse that I've seen is just really, really, you know, some people find it terrifying, but I find it exhilarating.
Luke: Yeah. Before I get into that topic with you, we're going to send you off to your desert island. You do get to take one piece of music. one piece of literature and one luxury item as comfort. So I suppose to begin with the piece of music.
Dan: Stand By Me by Ben E. King. It’s such a comforting, the first song I ever learned to play on the piano. I was three years old, I love that song. And it's such a comforting song, like the tempo is just right, the arrangements, the musicality of the score, it's just great song. I love that song.
Luke: It's very rare that you have one of those songs that just feels like home. I also love that you just jumped straight in there with that. There's no waiting, no thinking about it.
Dan: Nah, I mean, it's my favorite song. so it's always on the tip of the tongue.
Luke: And then, a piece of literature.
Dan: I think that I'm not sure about this. I'm less sure about this one than I am about the song, but I think it would be The Count of Monte Cristo. I read that book when I was in 10th grade, my girlfriend at the time whose my wife now, she recommended it to me and it's just like an enchanting tale. It's like swashbuckling, especially if I'm on a desert island and I cannot escape, I cannot get off, I want to escape mentally. And I feel like that book always allows me to escape mentally. It's such an interesting tale.
Luke: And then finally, a luxury item.
Dan: So it's impractical, but I would bring a hot tub, cause I like the idea of swimming in the cold ocean and then hopping into a hot, hot tub and like that sensation, you know, is cool. So I play basketball every Monday night and in the winter, it is like one of the things that I love, like coming home after being at the gym and playing basketball cold night, and then jumping in the hot tub, you know, is great. So, and also I just learned to swim this summer. I never knew how to swim, so I just learned to swim. So like I would go and swim in the ocean and then I would happen in the hot tub. And then I would go back and forth until I wanted to fall asleep.
Luke: I think you've just got the best answer so far, so congratulations.
Dan: I hope to keep that bar high and hope to keep that record for a long time.