From Design to Production: The Importance of Cross-Functional Collaboration

I'm so glad to be more often at your place, Alex. Nice that you are hosting me here today. Welcome to Casa da Punt. Yeah, find it on Google, give me five stars. Well, Alex, yeah, so I was, I was, I mean, you remember we recently launched the episode when I was attending the product conference Berlin 2023 and it was really inspiring to me and a couple of takeaways that I got because I was just thinking hosting a product conference is so much work but also so valuable because you connect to so many people, you get so many insights and also after the conference there are so many cool discussions that are popping up when you meet all those people and there was one particular thing that caught me and I wanted to talk to you about it is the collaboration between engineers and product designers. I think that's something that I don't read a lot about and people haven't talked often about so I was just thinking what your experiences are when it comes to the collaboration between those two parties. I mean, I think in terms of my experiences, the relationships with the engineers are some of the most important overall, right? I think it's something that follows you also across the whole product development cycle from the initial idea generation and defining also what you want to build because the engineers are the ones that know all the limitations that you have or that can also tell you what is possible, feasible and what isn't, right? And then it goes all the way to the final implementation of what you're building where it is extremely important that they can implement the specs that you have, that they understand the specs that you have, that there is enough communication and also quality assurance in the process, right? So I'm actually always surprised when I hear questions like that because I think pretty much like in my experience this is like the most natural thing besides working with the product manager, right? I mean there is basically three main touch points that a product designer has. The PM, the engineers and the other business functions. So it's like really at the core of what you should do. And when do you think, when you look at the design process, at which point should engineers be involved? All the time. So already in research? Yeah, also, yeah. I mean we do have usually engineers participating in the research studies as well. I mean mostly in observer positions and so on. But I think like as they are also the ones implementing the things, it is very important that they are aware of the customer pain points, that they can also to some extent emphasize with them and that there is like general understanding across the whole product team of why you're doing something, right? So I mean probably the whole scrum team isn't like attending to the research study, right? I think that would be a bit of an overkill. You also don't want to scare the customers that you interview. But I mean you at least try to like pull them in also when you're synthesizing or when you're presenting and sharing the results, to keep them involved. And I think that is like super important to also look at the engineers, not as like the ones implementing it after it has been decided by the core product people of what you want to build, but like to really involve them in the process. And you will be surprised how many great ideas actually come from the engineers themselves, right? Because like I think, I mean they are doing nothing else than building products since ideally multiple years, right? Like if they're around for some time. So I think like they also know how to leverage the tech and they can really contribute also to the ideation very early on. So yeah, I would pull them in as early as possible and as much as possible. Yeah, and I have seen it many times that during the implementation process, for example by building a model or a certain pop-up, the idea comes up to use for example native elements instead of the ones that have been designed and decided so to say, which saves you a couple of days of development time, right? Which is sometimes really great. And also on the other hand, sometimes it's mandatory to stick with the developed design system instead of mixing things up. But these conversations are super important and super valuable. And additionally, sometimes out of these two options, you have the third option, which is maybe something in between which delivers the most value and doesn't cost too much time. So I have experienced any collaboration between product designers and engineers many times, so good results, which is amazing. And I think we need more of that. So one thing that I was at the beginning of my career struggling with or was challenged with was the fact that after a design was so to say decided, it took me a lot of time to write down the acceptance criteria to go into the nitty gritty detail, how a screen should have behaved and stuff like that, which I shouldn't have done by the way. But at some point, the product designer got more involved. We involved this tool called Zeppelin, where the specs were all introduced already. And yeah, I think there we started saving a lot of time and a lot of communication. But I'm also curious to hear how you handle your design teams to make sure that the communication between both parties is ensured at the end of the day. Yeah. I mean, interesting, a lot of things Zeppelin died, or is dying. No way. Is dying a slow death together with Sketch. Okay, Sketch is, well, what is that? It's so 2016, right? Oh, yeah, 17. Yeah. I mean, Figma and the collaborative approach to design that comes with it actually changed this quite drastically. I mean, I think there is multiple parts to good handovers and to specs when we're working with engineers. One, obviously, which is an extremely important one, if you're in a more mature organization, is working with a design system, right, which takes a bit of the guesswork out because you work with pre existing components, or you have a process in place to implement new components. And the other one, like also, because you're talking about acceptance criteria. I think as a designer, it's also important to use tools or like to use prototyping as a really great tool to capture flows and to capture also that all the steps are there, that all the clicks bring you to the right screens, that you cover some of the edge cases, and so on. And I think then yeah, in the end, it's fairly straightforward, because you get your engineers into the tool, they can inspect all the different things, they can like take out the components that should already exist in code, with no need to redevelop some things. And then you, you should be fairly aligned, right. And I think it's important that there is this communication also moving forward to make sure that whatever the engineers do is like aligned or that they raise any changes or any inconsistencies where maybe a code piece, a code component looks different than what's on Figma, and you need to align there, right. So yeah, it's always like communication. I think we're beyond the waterfall approach of, I am done, I throw it over the fence. Now it's your turn. And you need to do it exactly the way I designed it, because my part was the one before you started working, right, which is like this whole pushing it, pushing it down the waterfall. But talking about pushing it over the fence, I mean, there's like, at the end of the cycle, usually the QA process, right, to ensure good quality. And I'm just curious, what is the role of a designer during the time the engineers start putting stuff into review or pushing it on like kind of development environment? So what are your experiences there? So the designer should definitely also be involved in the QA process, especially when it comes to the visual sides. I think it's also normal that for a designer, it's easier to spot some even simple things like something isn't properly aligned, or some margins are off. Because they're just like way more trained for it, right. So I think like, in the process, it's important that the designer goes through it to flag any wrong things. I mean, it always depends also on how your team is like set up and how each individual like what skills they bring to the table. I mean, I love when designers can actually go into a pull request, or open a pull request and make some of these minor changes directly so that you don't have to constantly go back and forth, right. I think especially when it comes to some minor CSS adjustments, a designer should be able to do it. But it's not something that everyone will bring. And then I think it's, it's also down to how you work with your engineers, right? I think if I could draw the perfect words, I would sit next to the engineers, and just have that exchange and have an engineer that knocks on my shoulder to show me something and we can refine it as we go in code directly, right. And I think, I mean, my IC days are over since quite some time. But if I, if I think about Felix and Monica, and you both know them, I mean, the collaboration with them has been a dream. Like, we spend so much time together, they had valuable input into the designs. I had like full transparency on what they're building. And we would like constantly improve the output. To give some background, Monica and Felix were engineers we used to work together with. So, but the best engineers, the best engineers, definitely. And yeah, we're going to see them in person soon. At least one of them. And actually, that brings me to my final question, because what do you think is the number one thing engineers can do to empower the designers during the development and delivery process? Transparent communication, be transparent, communicate, show the things. In Jira or in person? I mean, I would say in person. The word has changed a bit. I mean, it's changing. It's changing back. It feels a bit like, you know, a yo-yo when you throw it down. And then at one point, the spin brings it up again. So I think we're a little bit there. Yeah. I mean, in person, right? But you can recreate that also digitally. I mean, while Jira is great to track progress and the tickets and make sure that all the acceptance criteria are there. I think it's just also not extremely efficient if someone has to constantly go check Jira, write comments. It's the easiest thing is to look at the screen and write some lines of codes and change some values. Fair point. Couldn't agree more to that. I mean, I remember back in the days when I was doing app redesign projects or things like this, where I was just coming with my coffee in the morning into my team room. And two engineers were sitting there together with the designer, and they were talking, discussing. And it felt like so good, you know, because you see, okay, these people are talking to each other. They believe in what they're building, right? I mean, that's the best foundation for good communication. Yeah. So, and in my opinion, it requires also a clear direction in which you're heading, right? By knowing, okay, what is the product vision? What is the strategy? Where do we want to be? What's our team mission, for example? And yeah, with that, I think the communication is the most important part. And hopefully you and your team can enable them by providing the environment that allows good communication. Yeah. If you have any questions or comments on this topic, you know, you find us in the digital world or in person when you're ever in Berlin. Drop us a line and see you next week. Bye-bye. Bye-bye.