00:13 SYDNEY JOHNSON, HOST:
Welcome back to Responsible Disruption and Design 101, where we are wrapping up our exploration of the design process and the Double Diamond. I'm Sydney Johnson, your host, and today we're concluding our series with a focus on the delivery phase, featuring Tim Chen, team lead at J5 Design. In the art of design, Tim is a jack of all trades and a master of none—but in the best way possible. His knowledge and experience span interior architecture, product design, user experience design, customer experience, strategy, and service design. And did I mention he's also a DJ on the side? Tim plays many roles, and he approaches problem-solving from a broad lens—zooming out before zooming in—making sure he understands the nuances of different perspectives, scenarios, and environments before diving into the finer details of the question at hand. Tim's creative prowess extends well beyond design. As an accomplished photographer, videomaker, content creator, and co-founder of Service Design NYC (with yours truly!), he brings a unique blend of skills to his role as team lead. His contributions are instrumental in J5's mission to create a more beautiful future, and it makes him the perfect guest for today’s discussion on the delivery phase. Tim, thank you so much for joining me!
01:23 TIM CHEN, GUEST:
Sydney, Thanks for having me.
01:24 SYDNEY: Awesome. So listeners get ready because we are going to, as I mentioned, explore the final phase of the design process today, uncover lessons, learning strategies employed and some challenges faced during the delivery phase. So Tim, just getting started, I'd love to hear for the listeners a little bit more about you and what's your personal approach to design. Like, how do you interpret the design process?
01:47 TIM: That's a great question. I feel like everyone has a unique take on the process, even though, to some extent, if they're a practitioner, they know the process. I think I would say, as much as any designer would, my approach is the same—similar but different to every other designer out there. We understand the processes; it's more of a framework and guidance to how we approach things. But as most of us know, once you get into the work, it's always very much a puzzle piece of a toolkit where things can be interchangeable. Anytime, you guys really just have to know what method and what approaches to use at any given time and know where things fit into the different phases, which probably fits into where this delivery idea comes into play. You just have to know what delivery is and then, about moving through the different phases of work as a designer, it's kind of your ability to decipher what activities to do at any given time to actually deliver those outcomes. I guess my approach would be to really help. Never really put anything in the box of how to do things in one way, but to think of every project as a different, you know, a different opportunity to do something a bit different than new. Yeah. With the tools that you know and the methods I know, so yeah.
03:04 SYDNEY: Yeah, it has to flex to whatever the problem in front of you is. So tell us, what is the delivery phase? How does that show up for you in your work?
03:15 TIM: Well, delivery is interesting in terms of how you might view it in the double diamond, and, you know, as the audience might have already heard, the delivery phase is one of the converging points of, you know, thinking in terms of how do you end up going from something that's a broad understanding of wondering, where do we go from here? Like, what is it that we're trying to achieve? What are the outcomes or impacts that we're trying to, you know, come up with in any given project and given engagement of some sort? Delivery usually comes with the idea of providing that outcome, that clarity that comes out at the end of all the work that's been done. And usually, I think that can be the most confusing point because at what point are the pressures of delivery, you know, felt throughout the design process? And so sometimes in the world of, let's say, agile development and tech UX design, there's this idea of waterfall and agile that comes into play as words that either mean there's, you know, a set date on a project development's lifecycle where, in waterfall, you're building towards that end date without having this room to revisit. And in agile, if you think of this idea of delivery as constant, in which there is a, you know, a deadline, but throughout the entire process there's actually many different delivery points where the teams are delivering incrementally and having the ability to provide feedback loops throughout the process. But again, with the goal of hitting a, you know, a finish line at some point.
04:49 SYDNEY: Right. Yeah, yeah. So again, like, this is where it gets confusing because it can mean so many things. And in some ways, you're always moving towards delivery at some point in the process. It can be a point where you're showing something, or it can be that final outcome, like you say. And I'm interested in, you know, based on the conversations we've had in design so far, there's the develop phase that comes right before delivery, where you are diverging and trying to figure out all the different possibilities and exploring. You know, what ideas are you going to move forward with? And delivery is where you start to narrow down, where you may have already done some prototyping, but you're starting to really, really hone in on what you're doing. So just again, for the benefit of our listeners: What is prototyping, and what is testing, and how does that come into the delivery?
05:41 TIM: That's a really good question as well. Prototyping and testing, I personally feel, have to happen throughout the entire process of design. So it's not just, you know, this idea of "right before delivery, there's a thing called prototyping." Again, that's where things become interchangeable. You can prototype early on in phases of design work where you're trying to develop a proof of concept. This could happen in the realm of physical design, digital design, or any area really. The question is: what is prototyping used for? So, what is it that a prototype is helping people understand—the team, the stakeholders, the users? The essence of prototyping is to create something tangible from ideas that might be more, you know, philosophical or theoretical—things that haven't been realized yet. Creating a prototype helps people make something tangible so that someone can use it in their hands and have the ability to actually play around with the idea that a designer or a team is trying to envision. So, prototyping really is just making something come to life—from an idea to the first step of realizing that this could be a possible thing. It's that first step of making something tangible from something intangible.
07:01 SYDNEY: And what does it look like when you get further in the process when you are at that point that it's like really close to delivery or a point of delivery, how does the prototype and the testing change, if at all?
07:11 TIM: A lot of people would say you usually get less and less robust with some of the playfulness in testing as you get closer to, you know, whether we call it an MVP—a minimum viable product—or the first version of the service. It really does kind of become, you know, less experimental. So, usually, the feedback mechanisms near the end—let's say closer to the delivery side or the end of the project life cycle—become more about finessing the final product. At that point, there are pressures to deliver something tangible, and that ties back to the idea of what delivery actually is. Is delivery the end point of a project? Is it the first phase—the end of that phase of delivery work or product work? Near the end, prototyping becomes more about delivering something concrete, where there’s often a drop-dead deadline. At that stage, I’d say you’re really just refining and finessing the idea that used to be a little more ambiguous and abstract. When you test every time from the beginning through to the end, prototyping refines itself. By the time you’re near delivery, you’re focusing on validation rather than exploration. At the very end, right before delivery, you should have minimal tests that would redefine the work or force a major pivot, because at that point, a lot is on the line. So, when you think about that again, delivery, it's, you know, at what point are you testing something to redefine the product, and you work with your team, your stakeholders to think about, you know, are the last few phases of testing to just understand some of the last lingering questions that we have, or are you finding that something is inherently wrong with what has been designed, and are people ready to pivot from there? Right, and testing can uncover those harsh truths, but that's where it's, again, it's providing a point of clarity where, near the end of the march, depending on how your team and how your, you know, broader organization approaches the testing of, you know, the thing before you release into delivery, it becomes more of the, "What do we need to last understand to best help us set up for success?" is probably what I imagine it to be.
09:21 SYDNEY: Yeah, and how do you handle that when you're, as you say, getting close to the mark and you find that you still need to do something else before delivery or, you know, not everything is going as you dropped?
09:37 TIM: That's a good question. You know, it's one of those very much so, because there are many situations where things can go very sideways, and that could be, again, through various phases of, you know, having extra discovery and research built into, you know, not just prototyping right before delivering. It's just...
09:39 SYDNEY: Depends on the situation, I'm sure.
09:56 TIM: Different ways in which understanding right before the idea of, you know, delivering something can influence the outcomes. A lot of it goes back to every, you know, every team communicating appropriately with, you know, everybody on board, from stakeholders to the team, where I think constant alignment and realignment needs to be had, and if someone's lost along that journey, that's when usually people find the most tension. So again, that's where, you know, how often are things getting communicated? If you're testing, if you're doing prototyping and doing research, getting feedback, you don't just keep it to the product team to understand that knowledge. There should be regular feedback playback mechanisms to those who are sponsors and, you know, those who are funding the, you know, those programs, those services, those products, because it is not just the delivery, you know, teams need to understand this information. It's those who are actually providing the reason this became an initiative in the first place. For startups, that could be different. Yeah, exactly. So if that communication's lost, then that's often where the question of "Are we changing something at the very end?" comes into play, and for startups, again, that's where the tech world is a little bit more flexible.
10:54 SYDNEY: Right. The reason why you're doing the project.
11:09 TIM: There they are. The founders or CEOs. And if something happens, they might have been very involved in that, you know, quick development of, "Oh, something's coming up. We could, you know, pull the plug on releasing our product next week," and make the choice right now with executives to say we're not ready for this because they were very hands-on. But for those big organizations that have hierarchy, if you don't communicate throughout this, you know, triage of information, the grapevine, when that happens, that's when you go, "Oh, wait a second. Someone's not happy about what we're doing," and that becomes a different situation of how you handle that. And there are many examples from projects that, you know, we've done at J5 to personal projects in my past that, you know, that becomes the point of which do we, you know, have to redefine the work? Do we look at, you know, how do we get realignment, and do we pivot? And, you know, what's the best way to propose that? Because sometimes it's for the better.
11:59 SYDNEY:
Mm-hmm. Yeah, there's a reason why you're doing the testing and if you don't like the results, then you know there's no point of doing it if you don't do anything with the results that you get basically.
12:18 TIM: Yeah. And you don't want to release a tool or service or something into the hands of somebody where, you know, if you did find something inherently groundbreaking at the very end, to not take into consideration. Where I think it is up to everyone in that, you know, tool provider or service provider side to think about, "Wait a second. If we hear something that really does change the way we approach things and is really far along in the process," to have that hard conversation and go, "Are we delivering the right thing?" Because in this world of design and human-centered design, we're really not trying to just push out an idea that's not right for people. It's the idea of co-designing and making sure that we're actually listening to what's happening, and that, you know, comes up during the testing and feedback that we get.
13:05 SYDNEY: Yeah. Do you have any stories or examples of lessons you've learned from this delivery phase, in particular that you want to share that I think paint the picture of some of the things we've been talking about?
13:19 TIM: Yeah, there's definitely some good ideas that have, you know, kind of come up along the way where, again, in delivery, it can just be those points in which, you know, a team has to pivot or things that are just extremely successful. I could think of maybe one instance when a project was needing to pivot, and, you know, our team had time to do that. So, you know, with a very high-level way of explaining it, without revealing all the client details, it was a public sector initiative, and it was a digital one. So, this is the idea of delivering a service, a digital service, to the public with a, you know, a public sector body. And we were given a short 6-month period to develop an MVP, a minimal viable product. Again, there's always a short timeline that's, you know, sometimes given to any product team, any delivery team to make something happen. We're working under a very complex space, and we, you know, come, you know, month four or five, and we knew that there was a lot left on the table. So, that's often the case in, you know, in our design world. We want to design and almost cover everything, but we also realize we could only deliver maybe a solution that might tackle one facet of the problem space at a time.
14:41 SYDNEY: Yeah, just make those hard choices.
14:43 TIM: Yeah, and that is where the hard choices were exactly the point at which we had to, you know, and most teams would have to start seeing what's out of scope. I think that's part of that delivery process being, you know, ingrained in the entire design process where, when you're delivering, you sometimes forget about what it is that the goal is for the team, the client, the stakeholders. When you dive into the space and go through discovery, you go through, you know, defining and refinement. You go through development, you often kind of start creating a tunnel vision of, you know, what the team is trying to deliver and the problems that they're trying to solve. With service design and, you know, the idea of looking at systems and systems thinking, often, you do give yourself the ability to step back, and I think that is, again, part of the reason why service design and service designers are part of, you know, this current world of work, is that they are one of the actors in place to help constantly keep, you know, a zoom-in, zoom-out view of the work and kind of understand the dynamics of, you know, what was it that the team was trying to achieve? How did it affect the broader system in this work, in this project? We did basically have that same thing with the service designer, a UX designer on board, as well as developers, a digital architect, and a product owner. The design team was able to, you know, kind of keep things moving and refining the scope of the project, even though things started going into, you know, what would be called scope creep, or, you know, the additional things and functions and features of a... Yeah, can we keep doing this? And then when people go, "Oh, yeah," the timeline getting closer and closer, you guys just have to go, "What do we cut out?" And yeah, there's really the...
16:28 SYDNEY: Can we add this and this and this and this and this.
16:39 TIM: Given starting to backlog items, and you know, in the world of digital product design, you have a backlog that just becomes quite big. Usually, come the end of the delivery cycle, you just realize there are so many things that you can build out and do for the users. But again, given a certain timeline, you just have to realize, was this what we originally set out to do? Do these functions and features actually help with the thing now, or does it help with, you know, the thing in the future? And you do start prioritizing the work by going, 'OK, these are things that we found that weren't as important,' versus some of the things that we found essential to helping, I guess, our end users get to a better outcome.
17:23 SYDNEY: Yeah. So tell me more about that. How do you make those decisions around what you're going to keep and what you're going to leave on the table essentially?
17:31 TIM: A lot of conversations go back to communication. That goes back to talking to the stakeholders, and the team being able to communicate regularly with the stakeholders. On your side, when you start building out more and more features and more ideas, the teams have to constantly have these regular cadences of talking through, 'Well, you know, what have we covered? Who finds it important? Is it us, or do we actually know that people are saying this is the trend?' Again, that's through the research side of things, where you understand: Is it one person who said this thing was interesting, and did someone pick it up as an idea that we thought was fascinating? Or was it, you know, 10 people, 50 people? And so, often a lot of that goes back to how many people have engaged and heard this idea from, and found it useful. And how many people did not even mention it at all? From there, it's really a prioritization activity of finding, you know, time to say, 'OK, like we're working on this thing right now. We've heard something come up. Do we need to prioritize this? Do we need to pivot?' And sometimes, things called design spikes— the idea of escalating work that does come up—where, in Sprint work of, you know, the product development, well, digital product world, you might have a design spike where you actually push everything aside just to say, 'OK, we need to prioritize a new idea that came up. That's, you know, all hands on deck, code red.'
18:51 SYDNEY: We have to do it.
18:51 TIM: Yeah, we have to do it. We have to include this or it's you know...
18:53 SYDNEY: And we have to test it. We have to prototype it to make sure it's right, yeah.
18:55 TIM: Yeah, and yeah, and that's a conversation. So it's one of those things that are, yeah, the teams have to be aligned, and, you know, some of the team members might be like, 'Oh, we thought we were working on this.' But through conversations, it's just the idea of replaying that feedback. That was the reason as to why we need escalated: Is it, you know, something that's going to be monumental to our users or stakeholders even? Or is it something that our team just chose to do? And I think that clarity does help everyone get on board with that, versus the lack of clarity and lack of communication, where, you know, your team members might get less engaged when they don't know why the ideas have been, you know, pushed forward the way they have been.
19:36 SYDNEY: Right. Yeah. So it goes both ways. Like it's the whole team, all the different stakeholders, even the users like the more that people are aware of what's going on and why things are happening and what the decisions are and being part of those decisions, the smoother this is going to go. But of course that all takes time. And you're constantly balancing those.
19:57 TIM: Two things always, always—that's why it's, I think, really the success of any project, anything is, you know, up to how well the team works together. I don't think it's, you know, up to one individual guiding the entire team. It's, again, in this world of design, I think it's, you know, we play together, and it's not an individual activity. Design is a process, and designers are facilitators of the process, where design as a tool gets lost if not, let's say, facilitated. Unless everyone really has embedded that of working into the team's end, then there would be like no need for a designer, almost. And/or designers become more specialized as an activity of maybe just a visual design side, the UI interface design. Those things become more targeted if design became truly embedded as a process within the teams. But I think oftentimes, designers have a big role to play to keep facilitating the design thinking and the process of this is a process, a process that we all are part of and we're sailing on this. As you know, this ship, this journey together. Yeah, sometimes we might be the captain. Sometimes we might be the...
21:10 SYDNEY: Skipper.
21:10 TIM: Skipper. Yeah, exactly. So it kind of interchanges those different roles of when do people need the extra guidance and when do people not? And if everyone's smooth sailing, yeah, you might just be another, you know, sailor on the boat. Just. Yeah, yeah. Yes, exactly. Yeah. And those are different situations.
21:17 SYDNEY: Yeah. Sometimes you're also the lifeboat. It brings us back to kind of what we were talking about in the beginning. There is a design process, but you have to know how to apply it, and if you apply it very, very tightly with no flexibility, it's probably not gonna work. Like so much of design is knowing when to flex and when to use this. And actually, like you said, having the team come together around something, and actually the team dynamics are just as important, even though it's not mentioned in the double diamond, but it's actually maybe the most important thing in the whole design process.
22:05 TIM: Yeah, yeah, I would definitely. That's a great way to put it. As I use that sailing boat analogy, I was thinking exactly that: the delivery teams are the crew members, and there are some people with very specific roles. But I do find the design side—it's like the ship is, you know, this is a design and delivery process, and that's the act of sailing, the active designing and delivering something. The roles of the designers could, again, interchange between the skipper, you know, maybe, at times, the captain, and at times, sometimes, yeah, the first mate or someone just putting up the mast and just helping push the, you know, help the wind push the boat. And, you know, sometimes it's just, again, the idea of, you know, understanding whose role is what, having the team communicate together so that you're moving the ship forward.
22:54 SYDNEY: I'm curious what happens after delivery, so the date has come. The outcome has been delivered. What steps do you take that ensures that your design remains adaptable and responsive to evolving user needs even after that point?
23:14 TIM: Yeah, usually after delivery, it's this idea of feedback and, you know, constant iteration. I think, as we all know, back to the design process, feedback and iteration can happen anywhere in the process. But I think that's part of the idea of envisioning maybe that double diamond in, like, small chunks in a bigger timeline, and that sometimes you can see probably like, let's say, four or five phases of the double diamond. And at the end of each chunk, maybe that's the best time to have the team, you know, pause a big part of the work to get feedback and to focus on improving the process and, you know, taking what you learned from the previous cycle so that you can improve on the next cycle. So usually, I think what follows delivery is what a lot of people would say is a moment of feedback, implementation, and iteration, and I think that's kind of often misconstrued as to, again, the usefulness of it. And that, you know, there's many reasons for that. Is that the only time to focus on implementation, iteration, and feedback? But again, I think if you have someone who, you know, helps, you know, align those pieces together to saying, like, we don't want to forget about this, and maybe there is a moment in time where we take more time to focus on this, that does help the overall process after delivery to actually go, 'OK, we're taking time to learn from what we've just achieved, from what we just built. And I think without that, days after delivery, you might just keep moving forward and that eventually cascades into maybe losing sight of, 'Oh, did we just not listen to people's feedback and did we lose something along the way? Did we just keep our team's momentum, but we actually started pushing the idea in a different direction?' And so, I think that after delivery, there is very much a need to pause and say there is a feedback/iteration moment, and then again, the cycle could repeat. But that's what I find usually the most helpful—creating a moment of pause, or creating a moment of reflection and allowing room for iteration.
25:25 SYDNEY: Well, and that's the other thing: it's actually not done after delivery. It feels like it should stop, but it's not. You know, we talked in one of the previous Design 101 episodes about how design can kind of go on forever.
25:37 TIM: Yes, nothing is ever done, only budgets, and you know, things like that. Exactly, that's exactly it. That can go on forever. If you look at the best companies out there, there's a reason why they're still around: because...
25:42 SYDNEY: Yeah. And the will to continue, but the actual work is never done.
25:54 TIM: They've kept creating new things and, you know, probably taking their learnings, iterating on their products, their services. The things that probably have stopped the startups, the technologies, the services that maybe haven't made it to date as surviving products in our world are often those things that probably didn't iterate and just stayed in their lane for too long or didn't look beyond what they made and the next version of it.
26:30 SYDNEY: They stay stagnant like...
26:31 TIM: Exactly.
26:34 SYDNEY: Given that this is our final design 101 episode, I want to ask you something to leave our listeners with, which is in your opinion, where is design going? What is the future of processes like the double diamond, but also just the design world in general?
26:53 TIM: A fun question. Yeah, I would say I don't even really know in terms of, you know, there's trends, there's trends that I could see the design world going into, and there's definitely inklings that design has been escalated to this point where, you know, it's more well known to the world. There's definitely a lot more organizations, schools of thought, programs out there that teach design and teach the maybe, quote unquote, the mainstream way of approaching design and including design into your process, your organization. That's definitely surfaced in the last probably 15 to 20 years now. So with that increase in fluency, I'm personally seeing trends where design lingo and language are being so normalized that you're seeing like a decline in how people used to use it as buzzwords and the kind of the hot topics of, 'Oh yeah, are you using design thinking?' and, you know, 'What are these frameworks like double diamond?' The more that it's been used, I think the more—and almost like you can see—the maturity in which organizations maybe think about design and are really truly, you know, a part of that process, they probably use the language.
28:01 SYDNEY: Less, yeah. And acknowledging the depth of that practice.
28:06 TIM: Yes. Yeah, because it's, again, you want to understand the framework. You could really have, again, these foundational building blocks that you can now build anything with. And I think that's the exciting part of, you know, the design practice. Maybe it is like a moment in which design might not be used so widely, quote unquote, anymore as a design method or a design approach, and it becomes more of an understood way of doing things that then evolves our practice into another unknown step where we don't know where and what it's going to be called. As practitioners, it will be cool to kind of really see what that evolution can be and where things go. But I think that allows for a new thought to come up with, you know, maybe frameworks that benefit the new modern, you know, future way of thinking, but also allows, you know, the current designers and practitioners to kind of also be more comfortable and maybe help this work just keep growing and keep, you know, giving room for it to breathe and to see how it actually impacts different worlds of work because it doesn't always benefits something. There are, again, different ways of approaching any problem-solving process. Design is one method of approaching something in human-centered design. We're doing it in a very certain way, making sure humans are included in the process, and we always believe that's part of it. There's also many businesses and other things out there that might not need to escalate that as much—maybe in terms of animals. Maybe there's an animal-centric design process out there, that's just... yeah. And that's, yes, exactly. Who knows where things will go? So I think that's the thing we're in right now: we're in that kind of flow where design is more understood, and now designers...
29:40 SYDNEY: Or life centered design planet centered design? Yeah.
29:54 TIM: And kind of just work in the work a little bit more. There are often still, you know, places that have opportunities to grow in that area, but yeah. The areas that I think—again, in government, public sector, healthcare, finance—some of the biggest things that help the world operate, they have, you know, adopted their own innovation departments, their own design departments. They have service designers. They have included design into their process and their way of being. There are, you know, schools like Harvard Business School, Stanford. They've done this for years now, and it's now just kind of a way of doing things that has cemented itself as something more normalized. And that's a really good thing. But, again, there will be a decline in that language as it's going to be too normal and untrendy at some point. There will be new jargon.
30:42 SYDNEY: And then there'll be new jargon that comes up. Yeah, absolutely. Well, that's an exciting note to leave us on. Thanks so much, Tim, for sharing your valuable insights with us.
30:53 TIM: Thank you again for having me. It was a wonderful conversation. Hopefully it was useful. And thank you.
30:57 SYDNEY: I'm sure it will be.
31:00 SYDNEY: Listeners. If you've enjoyed this conversation, be sure to check out more episodes of Responsible Disruption, and if you haven't heard the previous Design 101 episodes, make sure you check that out as well, because we give a whole overview of the design process. If you've learned something from this mini series, I hope that it is that the design process is ambiguous and confusing, but also can lead to some really beautiful and wonderful things. Until then, keep exploring and innovating.
[Outro music]
That's all for today's episode of Responsible Disruption. Thank you for tuning in and we hope you found the conversation valuable. If you did, don't forget to follow, rate, and share wherever you get your podcasts. To stay up to date on future episodes and show notes, visit our website at thesocialimpactlab.com or follow us on social media. And until next time, keep on designing a better world.