What is design? What makes a designer? Big questions require big answers and Thomas and Jerome found the most overqualified person they could: Jon Wettersten, Head of Design at 8th Light. In the inaugural episode of Collaborative Craft, Thomas, Jerome, and Jon discuss design, creativity, and the Human Centered Design approach that guides most of his work. Jon also makes the case that anyone can be a designer. Listen to the full episode below, or wherever you get your podcasts.
If you'd like to receive new episodes as they're published, please subscribe to Collaborative Craft in Apple Podcasts, Google Podcasts, Spotify, or wherever you get your podcasts. If you enjoyed this episode, please consider leaving a review in Apple Podcasts. It really helps others find the show.
This podcast was produced by Dante32.
Episode Transcript
How Design Works with Jon Wettersten
[00:00:00] Jon: If you like math jokes, here’s a question. Why did the math book look so sad?
[00:00:09] Thomas: I don't know, Jon, why?
[00:00:10] Jon: Because it was full of problems.
[00:00:12] Thomas: (laughing)
[00:00:15] Jerome: Hi everyone. I'm Jerome Goodrich.
[00:00:17] Thomas: And Thomas Countz.
[00:00:18] Jerome: And you're listening to Collaborative Craft.
[00:00:21] Thomas: A podcast brought to you by 8th Light.
[00:00:23] Jerome: Thomas, who's our guest today?
[00:00:26] Thomas: Oh, my gosh. I'm so excited in case you can't tell, our guest is Jon Wettersten. He worked at IDEO for 13 years, learned a ton, did a ton. He became their Executive Design Director by the time he finished up there. Now he works for us here at 8th Light as our Head of Design. So he is in charge of all of our design capabilities, all of the multidisciplinary approaches that we take. Everything. And he agreed... actually it didn't take a lot, he's very generous; but he generously agreed to be our first guest today.
[00:01:15] Jerome: Woo hoo!
[00:01:16] Thomas: You're excited too, I love it.
[00:01:18] Jerome: I'm super excited.
[00:01:20] Thomas: What are you most excited about?
[00:01:23] Jerome: Oh, that's a great question. I've so far had limited interaction with Jon. He's pretty new to the company and, you know, we both have our day jobs and whatnot. But he seems to me like just an incredibly thoughtful person. And selfishly, I really want to talk to him because I want to understand a little bit more about what he does as a designer and what design actually is, because I...
[00:01:57] Thomas: you're just a lowly...
[00:01:58] Jerome: And this is hard to admit, I don't really know.
[00:01:59] Thomas: You're just a lowly software developer.
[00:02:01] Jerome: I'm just a lowly software developer. I've worked with designers before and I've implemented designs, but I've also in a previous life run workshops on design thinking.
[00:02:14] Thomas: Oh yeah, you did.
[00:02:16] Jerome: Yes I did, with entrepreneurs and, helping them kind of validate or invalidate, some of their entrepreneurial ideas using the design thinking methodology.
[00:02:27] Thomas: See, that's crazy. I don't think I would have thought of that as design.
[00:02:31] Jerome: Yeah, exactly. And so, I think that's the point. It’s like, I have these two different contexts. You have your own contexts and all of it is design. So what is, like, what is a designer?
[00:02:44] Thomas: Yeah. I just finished reading The Design of Everyday Things and it was recommended a few times, but then I read it and then I'm like, I actually don't know how this... How does this happen for like a tech product? The book is a lot about, like, you know, physical products and doors and appliances and kind of, I guess, industrial or commercial design. I actually don't even know. But, um, how does a designer do their work for a software product?
[00:03:15] Jerome: Yeah. Is there some kind of like unifying principle or something that makes a furniture designer the same as an interaction designer or like, are those completely different disciplines? Like if somebody was a JavaScript developer and didn't know anything about Python or something like that, like, you know, is that a fair analogy? I have no clue. And so that's why I'm super excited to talk to John.
[00:03:42] Thomas: Yeah, basically we know nothing about design, and we found the most overqualified person possible to answer very basic question for us. So, why don't head on over to our conversation and see what we can learn?
[00:03:57] Jerome: Let's do it. Let's do it. So excited!
[00:04:01] Thomas: Here we go.
[00:04:02] Thomas: Hello and welcome to Collaborative Craft, Jon.
[00:04:11] Jon: Thank you, it's great to be with you. Also, sorry, Thomas, I'm going to call you out for having a few technical difficulties before we were getting started. So by the way, I just want you to know there's nothing but empathy and compassion, just love and kindness that I was showering you with while you were working through that.
[00:04:29] That being said, it reminded me when Thomas came back, he mentioned how many design opportunities there would be to fix, you know, the interface that he was working with. And it made me think of the, I think it was the first week that I had started at IDEO back in 2007 and I was working with a very talented interaction designer, and we were working on a design together. And there's a certain behavior that was happening in the prototype that she was really frustrated with. And she was blaming the design of the prototype. And while I was watching her, trying to use it, I noticed that she was making a very obvious mistake in trying to use the prototype.
[00:05:10] And so I just made a comment and said, you know, sometimes it's pilot error. And I said it in a very deadpan way, and she just about spit out her lunch and she got pretty annoyed saying, no, there's no such thing as pilot error, it's actually a design flaw. And then she realized that I was just, you know, making a little bit of a sarcastic comment and it actually ended in laughs. But I think it could have gone to blows if I had continued that line of questioning.
[00:05:38] Thomas: Oh, so do you subscribe to that? That there's no such thing as pilot error.
[00:05:43] Jon: I'm going to plead the case of, I think moderation. And I think there's behavior that should be expected and there's behavior that should be unexpected. And we need to factor that in as designers. This might get a lot of responses, what I just said, but I think there's an investment on both parts: users of the design and designers for the users.
[00:06:04] Thomas: I think that's great. And only someone with your experience could have such an eloquent point of view. I just read, Design of Everyday Things. And I'm forgetting the author off the top of my head. But that was something that was really striking with human-centered design is just how many examples that the author could come up with a bad design, everything from doors to, you know, washing machines.
[00:06:29] And it really made me look at the world very differently because I think I was one of those people that I constantly blame myself for what might be bad design. But I'm not a designer. So I'm really curious about where that line is and balancing innovation and pushing the envelope and introducing new interfaces with the expectations of users and the capabilities of users.
[00:06:56] Jon: Hmm, it's interesting. You bring up that book and the author was Don Norman and he's been very influential in human-centered design. There might be times in which I use language that might be influenced by Don Norman, as well. So happy to talk more about it.
[00:07:10] Jerome: I think that this provides, a nice little segue into what exactly is human-centered design. And you know, what is a designer who focuses on human-centered design? At least, your take on that.
[00:07:24] Jon: Human-centered design, in my experience, has largely been an approach to create some sort of experience. It could be with a product. It could be with a service. Or as an experience, more broadly. And the key bit is that the work is centered around the needs of the people that it's intended for and needs in this case is quite an overloaded term.
[00:07:52] It means many things, so it can encompass physical, emotional, psychological needs and variables that should constantly be influencing the designer on how we're creating something that is useful. That's meeting those needs. It could be intuitive. It also needs to be engaging, which can also mean it needs to aesthetically appeal to the people that you're designing for. During my time, at my previous tenure at IDEO, design thinking was a significant creative approach that I've often seen used interchangeably with human-centered design. However, the distinction from my experience is that in addition to leading and being centered on those needs of people. It equally emphasizes the importance of considering the economic implications of the design.
[00:08:49] So you can imagine the cost of the material and making the design as well as what sort of return on investment it might have once in market. And then also equally paying attention to the technical feasibility. Whether that concept can be created with the intended materials versus just strictly being something that could exist, theoretically. Like you could never fabricate it, but it really is a great idea, theoretically.
[00:09:16] I guess one more piece to that feasibility, another facet to that, that I've really been interested in, probably within the last several years has been... well few years... has been that feasibility should also be extended to factor in the capabilities of the organizations that we’re tasked to design for, but also to design with, because oftentimes those organizations are going to need to own and maintain that outcome.
[00:09:42] And so is it not only feasible for us, let's say to create this innovative software, is it feasible for our client organization to be able to pick it up and own it and evolve it themselves? Which we do want them to do so that they can be empowered in their business.
[00:09:59] Thomas: I'd love to talk more about that. I hear a lot about design kind of holistically. Like you said, a physical object, or otherwise, or software. And how it all is kind of based in the same interaction, at least in terms of human-centered design, around designing for the end user. So I'd love to keep talking about how you approach interacting with clients with the same design thinking as you approach a design for a product.
[00:10:30] Jon: It's interdisciplinary teams working with the design consultancy, working with a design and delivery consultancy, like 8th Light. As well as working with a variety of different client organizations across different domains and different contexts. I think the shared scenario in all of those cases, whether we're partnering with another company or we're partnering with our actual client, is the benefits of having an interdisciplinary approach, which is having people from multiple backgrounds, multiple disciplines that would benefit the creation of the appropriate solution all working together as an integrated.
[00:11:14] As opposed to having those different disciplines working on the same outcome, but doing it separately from one another, which put bluntly, that's typically describes a siloed approach. So being able to integrate all the types of skillsets and mindsets and experiences that you need. And that can be from another partner organization.
[00:11:36] It could be from the client organizations within our own teams at 8th Light. We're able to work together with the same continuity of experiences, same mindset to actually deliver the outcome, as opposed to having the researchers do work over here. They throw it over the wall and give it to the designers who do have expertise in their discipline, but they're not actually working in an integrated way.
[00:11:58] And I think that has been an incredibly successful experiment that we've run between organizations and with our clients to help them as we not only design for them, but we also design with them so that they are empowered within the solution.
[00:12:14] Jerome: We talked about in a previous conversation, this violin metaphor, that you eloquently came up with on the spot. I feel like that would be a really great introduction to this idea of feasibility and designing an engagement as opposed to designing like a product.
[00:12:33] Jon: Well, it just so happens that at a very young age, I was enrolled in a violin academy. And really music became my second language. And it tends to influence how I think about experiences in general. So therefore, I use it as an analogy many times, for better or for worse. There are moments in which you're designing for clients with an intent to do it with them.
[00:12:58] And I think that speaks to, how we need to, when we think about feasibility of our work, we need to think about not only the feasibility of ‘can we accomplish this design?’, but ‘can our client organizations also own it moving forward?’. Some of the experiences that I've observed is at the end of some significant work as part of the deliverable, an incredibly dense manual or presentation deck is provided to a client.
[00:13:30] They get the brand new shiny cutting edge software solution, let's say. And then they're given a deck that is attempting to articulate in words and in visuals, how you need to go about doing this work, picking up and owning it. I think some folks would similarly describe it as trying to assemble Ikea furniture.
[00:13:57] Now I haven't had any trouble assembling Ikea furniture. If Ikea is listening. But I've heard rumors that it can be difficult. So I'm seeing some of the clients struggle with these dense manuals and how to set up high-performing, multi-disciplinary product teams. Makes me consider what it would be like for a person who's interested in learning how to play the violin.
[00:14:21] And they received a presentation deck that I created with painstaking detail of writing out the copy, creating all these visuals. Trying to communicate what I believe is very important for them to know before they actually go about playing the violin and/or playing it. I might even add a supporting website with videos for the clients to watch, and they would watch me play, you know, which is very helpful.
[00:14:46] So then imagine, great, they got this deck on how to learn the violin from me. And they looked at the website. And imagine the moment in which they pick up the violin and the bow. So there's two pieces to this instrument. You can only imagine the amount of struggle they're going to have to hold it and balance those two key components.
[00:15:05] And if they don't drop it, when attempting to move the bow across the strings, you can imagine that the sounds that they're going to create are going to likely eliminate any or all confidence and motivation to continue. So, in these moments, I think about clients, and they get this very expensive and very informative material, but what they don't have, they're missing critical tools.
[00:15:30] And those are the behaviors learned from experience to be able to put them into action and be successful. And it really is only through practice that they will actually be able to own these outcomes. And in these moments, it's when designers see firsthand, how important it is for them to be influential and inspiring teachers, not just makers.
[00:15:51] Thomas: I love that metaphor. I played violin when I was a very young kid. But it doesn't matter, you could give me any presentation and I would probably also be de-motivated by the sounds that would come out of that instrument.
[00:16:04] Jon: Yes. Well, I don't think one ever learns to play the violin as well as they want to. And I think it's a lifelong learning process, which you don't realize how much humility you learn as part of learning to play an instrument. So that's been a very helpful life lesson.
[00:16:20] Thomas: I love this conversation because Jerome and I are both software developers, not designers. And before our initial conversation, and before reading a bit, I knew very little about what design and designers do. But it's striking how many parallels there are to development. And when we say software architecture design, or the design of the code, or the shape of the code, object-oriented design. I think a lot of the principles are kind of the same, which I find really, really compelling.
[00:16:55] Jon: Hmm. Thomas, I think you're right on. It's really funny to hear you say software design, because previously at IDEO, that was a discipline that I identified that needed to be brought into the organization. And I do have software development experience, and I saw some of that experience of being great importance at IDEO. But in addition to the development expertise, I was adding quite a bit of nuance to the type of software development that IDEO would really benefit from at the time. And the way I describe software design is that which is done by designers that use software as their primary means of creative expression.
[00:17:44] So let's hold onto that, because you're getting to it - to something that I wanted to share with you in this conversation that I believe, and I continue to learn, that the term designer can be applied to so many different people and so many different experiences. And there's some folks that I worked with that never consider themselves a designer until we actually collaborated together.
[00:18:09] And I actually think that's a wonderful thing that organizations like IDEO is doing and is really highlighting just how creative people are and how creative people inherently are. So now let me wind us back a little bit. I'll wind us back a little bit to kind of a grounding on what a designer is and knowing that we were going to talk about this - I go to my go-to resource, which is the dictionary.
[00:18:34] Thomas: Yeah, it's a good one.
[00:18:35] Jon: And it's right at our fingertips. For those of us who sit in front of screens all day. And looking at the new Oxford American dictionary that I have installed on my, on my Mac. And a designer is defined as a person who plans the form, look, or workings of something before it's being made or built and typically by drawing it in detail. I find this dictionary definition most relatable to my own experience. However, where I take some issue with it is the last bit, which says 'before it's being made or built.' As I believe the craft of making something that you are also responsible for conceiving, is critically important for the designer or individual to understand how to build the solution, which informs the feasibility of the plans as defined, which we talked about feasibility earlier. And also, the participation of that individual through that process helps ensure that that final outcome is staying true to the established design direction that was set forth at the beginning.
[00:19:51] And as you guys know as software developers, how many times do things go to plan? How many times do you not run into exceptions that haven't been accounted for? Which gets to, I think the observation that you're making, Thomas, is that if you think about this definition, you forget about the term designer.
[00:20:10] But if you just look at, you know, a person who plans the form, look, or workings of something, my goodness that opens up the possibilities, doesn't it? So think about the functions and methods and services that you create. That takes design. You're planning it. You're creating the form of it, the look of it, how it works.
[00:20:31] And I bet the work that you do is incredibly desirable to leverage by other people. This also applies to, I discovered, MBA colleagues who are helping design business models to support some of the new ventures that we end up creating as part of the work that we do, data scientists designing algorithms to train data models.
[00:20:54] And I think you can just start adding your own list of folks from different expertise that create. So I guess the challenge is it's hard not to apply the title to anyone engaged in a creative act.
[00:21:06] Jerome: You're saying something that's really resonating with me. And I want to, I want to just throw it out there and kind of get your take on it, which is, we talked earlier about this idea of multidisciplinary or cross-disciplinary teams. Is it safe to say that those are actually design teams? Because everybody that is on that team has a part in designing.
[00:21:27] It's not just the person, that's the designer that is designing. It's the entire team in cooperation and collaboration. And I guess if that is true, you've also mentioned to us previously that it's incredibly rare to find that in the wild. And I'm curious why that is. And in your experience, like how do you empower everybody to feel like they are a designer? How do you build that team?
[00:21:53] Jon: Well, I think it's both a question and an observation that really resonate with me. So as I listened to you share that, I think, oh, well, you’re articulating that very well. How might I build upon it? How might I reinforce or underscore certain aspects of what you just said? I think it's through the act of the creative process that you're in.
[00:22:18] And by the way, development is a creative process. And through that experience, people realize how involved they are in the creative process. And why not allow them to consider themselves designers? And I think that's a very inclusive way of talking about design. I think there can also be an important conversation on the specialized skills of certain types of roles and design roles in particular, that we should also respect. But if we generalize by saying team members who are engaged in researching and conceiving, identifying opportunities for design, taking that design through that process through development into market. If you're a part of that effort, you are part of the design team. And as I talk through those different phases, if you will, you could also refer to certain people in those phases as the name of the phase, which I've also experienced. Oh, we're in the research and discovery phase. So am I a researcher? We're now in the design and prototyping phase? So am I a designer or a prototyper?
[00:23:33] Oh, and now we're in the delivery, or the development, or the engineering phase. Oh, does that mean I'm an engineer? Maybe. Possibly. I think in the inclusive way of representing the team, absolutely. But let's not overlook the specialties that are also engaged together in that interdisciplinary team to respect that as well. But I'm very much a proponent of the inclusive way in which we use the term 'designer'.
[00:24:00] Thomas: A lot of what we were talking about so far today is, first of all, really inspiring, I think, just to shift the perspective of, oh, am I a designer and what possibilities does that open up? That's really exciting to me, but what I want to chat about now is kind of the practicalities of this. I think a lot of our clients at 8th Light, they kind of know that they're buying into these philosophies and the humanity that 8th Light brings, and they create affordances for that. But I'm wondering in other institutions or other organizations, how do we marry this perspective around design and the consciousness and rigor around design with these business incentives that often can mean deadlines and budgets, and we don't have time for, we can't afford to, or et cetera, et cetera? I'm wondering how we marry those two sometimes competing forces.
[00:25:05] Jon: The competing forces resonates with me because I try to look at those as not competing forces against, but actually helpful constraints that provide boundaries in which we can work within and which we can create within. And I think that's a real perspective shift. It also requires that type of perspective, I think you get for free when, as a designer or as a company working with a client, you approach the work in saying not only do we need to design and develop a product that is useful and engaging for that end user, also needs to factor in the needs of our clients.
[00:25:53] And that's where we're not just designing for the end users. We're also designing for our clients and what their needs are. And some of those needs might be seen as competitive pressure, but at the same time, there are some real constraints and there are some real needs and some real guidelines that I like to embrace.
[00:26:15] And I think that can be very productive in those moments. If you have a contentious relationship, even at the outset and looking at the needs of our clients as competing against what we want to accomplish, I think we're not practicing part of that human-centered design approach, which is understanding the people that we're designing this for. Because ultimately our clients are part of the end users.
[00:26:39] Jerome: I think I'm sold on the idea of human-centered design as a methodology for structuring engagements and as a methodology for actually carrying something through from idea to implementation. Part of the idea behind this podcast is really challenging these like mores of design and development and, software architecture and getting the firsthand experience from people that have seen it not work or have experience of understanding where it falls apart.
[00:27:19] And I'm curious if you have an experience that comes to mind that highlights that? Where human-centered design might not apply or, how it could be misapplied to deliver something that, you know, isn't exactly what was demanded or what we were trying to do in the first place.
[00:27:37] Jon: Hmm. Yeah, there are so many examples that come to the top of my head. So much of the creative process is about making mistakes and failing. But the important bit is making sure that you learned from it. If you don't learn that you're not growing and you're not benefiting. So the devil is in the details. And let's, let's talk about when the rubber meets the road.
[00:27:58] There have been real challenges. Where I've seen teams that are under great amount of pressure to deliver very specific features that, despite our best efforts in estimating what it's going to take in order to create them, maybe we run into some feasibility issues with the technology that we're using. Maybe we start to completely burn through a budget on trying to get this one feature working. And we're under a lot of pressure to deliver. There are many different levers that we can pull, but oftentimes in the heat of that moment, we're constantly under pressure, a lot of times under the client saying, you promised to get this done, you're going to do it at whatever cost. And this is when you start to significantly set that team up for failure. I think you probably all right now are thinking of cases where you felt the pressure to deliver a feature that you don't know if you can do or not and you promised it, what are we going to do?
[00:29:06] I think a significant part of that is going in as a team with the right intentions. And we say, look, we did do our best efforts to try to get this developed. And oh, let's bring in human-centered design. Let's say we know that this feature tested incredibly well when we were prototyping it.
[00:29:23] This meets the needs of the people, the end users, but we just can't pull it off. And the amount it's going to cost is actually not viable now. It actually is blowing the budget. It doesn't make sense to do it. And so, in those cases, and in this case, I'm throwing in the design thinking lens as well, we need to stay true to that.
[00:29:43] We also need to have that alignment with our client team in particular. And they can say, oh yeah, you're right. We know it would be desirable. We are struggling on the feasible. We thought you could do it, but we understand that despite our best efforts we're not going to pull it off in this release, but we might be able to do it in the next release.
[00:30:01] But see what I just said, this release becomes a lever. We could remove that pressure. Oh, and I mean, we can go into communication challenges. We can go into, do some of our team members have an open mindset or are they just really stuck on one way of doing things and that they can't adjust. We have to be adaptable.
[00:30:18] We have to be flexible. We need to look at things from different perspectives. It's easy to talk about this. These words really seem to be easy for me to say, but when you're in that pressured moment, it's exponentially harder to deal with. It's harder to have that objectivity. And I spent a lot of time trying to create that capacity, create that space, create that objectivity for our team. Being somebody who's been in that situation, being close to the metal, feeling it, when things blow up, there's ways to manage it.
[00:30:51] That requires quite a bit of presence of mind, a certain objectivity and emotional detachment in what can be an incredibly emotional engagement. So does that help provide some examples of how human-centered design, kind of plays a role when the rubber meets the road. I mean, we haven't even gotten into agile discussions and different approaches to that, but I think there's so much of agile methodologies that fit within the practices of human-centered design. I think that could be also a really rich conversation to talk about, you know, when things work and when things go wrong. And is it a process, you know, or is it a practice issue?
[00:31:34] Jerome: What I'm hearing, it's really kind of like the same distinction between like little-a agile and big-A agile, right? Like when you have human-centered design as your directive and you adhere to it to the T without kind of thinking of the consequences or the context in which you're applying it, it's not going to work. You have to be adaptive. You have to be open, honest, you know, all the things that lead a project to success.
[00:32:03] Jon: Exactly. That's exactly right.
[00:32:06] Thomas: I think it's just about time to wrap up here. This has been such an eye-opening conversation. Thank you so much, Jon. Like I was saying earlier, I think I understand more of what being a designer is and maybe I have a little bit of designer in me.
[00:32:23] Jon: I think you do. I think you both do. Thanks so much for having me. I just, I enjoyed this conversation very much.
[00:32:28] Jerome: Yeah, us too. And I think we're definitely going to have to have you back for a part two.
[00:32:32] Jon: Careful what you wish for. That’d be an honor.
[00:32:43] Jerome: Okay. So that was amazing.
[00:32:45] Thomas: [Oh, my god, so amazing.
[00:32:48] Jerome: I am awestruck by John's wealth of experience, his wisdom, his stories, his generosity.
[00:32:59] Thomas: His smooth radio voice.
[00:33:01] Jerome: Exactly. But I am curious how that hit for you. Is there something that his words sparked? You feel like "yes!" Something that you can identify with in your own experience?
[00:33:15] Thomas: Yes. The first thing I thought of when Jon mentioned the pilot error story, I had an experience where I was told that it was pilot error, but it wasn't a joke. I was on a team, and we were working with this service that was really difficult to use. It just had an API, but it was unpredictable, and it was just very cumbersome and when we approached the individual who owned the service or designed the service, their response was, this is a tool built for professionals, built by professionals.
[00:33:54] Implying that if we didn't understand it or enjoy using it, that we weren't professionals. And while Jon was talking, I was thinking if I were that individual, if I had this human-centered design mindset, how might A: the product turn out different, but also B: how might that bit of feedback been able to be used to improve the service? That was a moment where I was like, oh, maybe this engineer could have used some of the principles of human-centered design. How about you? Have you worked on a team with designers where things went really well and maybe they employed some of the techniques and tools that Jon was talking about? Or maybe you have some horror stories?
[00:34:44] Jerome: Interestingly, the thing that pops into my head is not necessarily about a designer, but about a PM I worked with who I think was a designer in his own right. Probably one of the most capable people I've ever worked with. And the reason why is that I don't know if he just had an intuitive understanding or really just cared about how to drive a project forward. So he maintained this gigantic Google doc, which was the source of truth. And typically, on projects where I hear 'gigantic Google doc source of truth', I'm like, you know...
[00:35:34] Thomas: It's a bit scary.
[00:35:35] Jerome: It gets scary. But this person's dedication to keeping it the source of truth and to making sure that everybody understood how to use it, making sure that it was easy to use, you know, rectifying any errors. Like you talk about everybody being designer – that care for the end-user and that thinking about ‘how can I make the job of the people on my team, just that much easier, because they all know what they're supposed to be working on’. They all know what to do in the case of a conflict. They all know how to manage bugs and how to triage and what the expectations are there. To me that speaks to what John was talking about.
[00:36:24] Thomas: Yeah. What about you listener? Are you a designer or an engineer? Have you worked on a team that had a really awesome and amazing design sensibility? Or maybe, like me, you have some not so good horror stories where design perhaps was absent from the process. We'd love to hear from you.
[00:36:51] Jerome: Thank you so much listening to this episode of Collaborative Craft
[00:36:55] Thomas: Check out the show notes for a link to this episode's transcript, and to learn more about our guest.
[00:36:59] Jerome: Collaborative Craft is brought to you by 8th Light and produced by our friends at Dante32.
[00:37:05] Thomas: 8th Light is a software consultancy dedicated to increasing the quality of software in the world by partnering with our clients to deliver custom solutions to ambitious projects.
[00:37:15] Jerome: To learn more about 8th Light, how we can help grow your software development and design capabilities, visit our website at 8thlight.com
[00:37:22] Thomas: Thanks again for listening, and don't forget to subscribe to collaborative craft wherever you get your podcasts.
[00:37:28] Jerome: You can also follow us on Twitter at @CollabCraftPod to join in on the conversations let us know who you'd love to hear from next
[00:37:36] Thomas: We'd love to hear from you.
