Design-Development Collaboration with Yonatan Ziv

Hi everyone, my name is Patrick and if you're interested in design and development collaboration, this episode is for you. We share what is expected of design nowadays, how to grow the fastest you can, as well as some experiences when it comes to collaboration and how to do that more effectively. Joining me today is Jonathan Zia, gamer Dad and product Design director, and I love learning from his experiences. Enjoy.

I'm really curious as to what your experience is working in a product team, because most of the product teams I've worked with only have one designer, whereas then with a bigger development team. I feel like the design is kind of the funnel for the work that needs to be done as well from a visual perspective as well as kind of design and market

research perspective, right. You mentioned AB testing as kind of testing your outcome and testing your assumptions, but still we want to do enough research to make sure we're actually building kind of the right thing before we then test and optimize that, which is a whole lot of work, I feel like. Have you worked with product teams where you were the only designer, or have you worked with a designer team as well?

So I I worked in all set ups. So I I also when you talk about you know agile and the waterfall and all this stuff and fake agile, that's also a thing. Waterfall the agile. But yeah I think there's there's a few different set ups There's like the really tight tight team. Yeah. And that's usually like one or two designers working with a front end, back end security, dev OPS, you know depends on the on the project or the if you work for a client, depends on the client and then you're

really tight. So I think you you also talked to Michael Dewey, my also previous colleague and so we were together in in this kind of product team and we were really, really super tight. We had really short time frames, it was innovation project. So there was no exist, there was nothing. You have to build everything from scratch. And this is where you have to

really collaborate closely. And we did things like their design pairing when we sit next to each other and instead of me designing something fancy on my figma and saying, you know, hey, fancy frontender, make it happen, we just said, OK, this is the general concept, let's sit together and figure it out. And then, yeah, I can do this, I cannot do this. So how do we compromise this? And this wasn't really nice exercise of finding the balance between feasibility and and

experience. So this is a really tight team for like tight product team example that I I also you know sit down with the back end there and understand what what is the information he's getting what kind of AP is that he have and and trying to see OK how do I use it in the design. So it's actually the other way around.

This is the information we have. We had this kind of financially heavy solution and I needed to understand what are all the figures we can actually show and how do we arrange them and what makes sense for the user. So that means I need to really know what we can and cannot, you know get so I can make again my fancy design, come back and say make it. But this was more like a tight collaboration. So this is of course what I prefer, right?

This is the I see it as an ideal situation but sometimes the

again going back to the scale, the big solutions you find yourself in corporate set up. So there's a bit more separation. So there's a design team and there's a development team and this is this is of again, you have the same conversations but there is a lot more of siloing of the designers kind of work with the brand guides and with the vision and making something they think from experience and

visual perspective is ideal. And then you say, OK, let's start a conversation, let's bring in the development team and discuss and see OK is this even possible? What is the effort? And then we are starting this negotiation of OK, if we make this, it will take us 3 sprints, is it worth it? And this is again the, the sad part of being a designer that you have to compromise a lot for visibility. But yeah, so that's that's another set up when basically you have two separate teams.

I'm trying to think if there's another one. There is also kind of an overlapping 1, so you have product teams. So again big, big solution. For example, in e-commerce site you have different product teams that they own different parts of the journey of the user journey. Some of them own the checkout, some the you know PDP, some the whatever. The more exploration part in the beginning and what you have is that you get a bit of both. So the the product team operates quite tightly.

So you collaborate a lot like I mentioned before. But there's also like this overlapping circles between the different teams because everybody owns a part of the journey. You cannot work in a silo, you have to understand what happened to the user before he came to your part of the journey. And when you're designing something that impacts the rest of the journey, you also need to talk to the other teams. So in that way you get like this

overlap. So the designers are really talking to each other, but you also in your own product team really tight with the with your own, you know, team members and working nitty gritty into the details. So yeah, but still there's there's a lot of magic when you have early stage Thai team trying to figure out things, almost like a start up vibe to it. Yeah, if I look back at my own kind of experiences, I've only had the, let's say, the the product team, the one that

you're most fond of that. That's been my most experience. I've only had ones where there was actually design agency and since I worked at a consultancy there was also a different company as a whole which was then feeding our team with fancy designs in a way that we had to have those discussions of feasibility and then duration as well when it comes to time and investment which was very hard to work with.

So then I always got the preference of OK, having people in the team to then work together with and have those discussions. And I think compromise from both ends because engineers also love some engineers over engineering a solution and making it perfect from an engineering perspective.

And I think compromising and and having some middle ground on both ends as well as coming from kind of a business value creation standpoint is the best solution even though it's it's hard to do that and to to make that happen in that way.

And and when you work with the agency, basically at what phase were you involved? Is it just they finalized the designs and just threw it over the fence and said what do you think? Or was it there like a process where they're like stage gates? We, we knew what was coming functionally, but then they were very much involved in how to do that visually. And we were then involved more so at the end when they already imagined and mostly created

almost all the designs. And that was the hard part because then we had to be like, OK, you get something and from a development point of view you're like, OK, either you see holes and then you have to shoot and be like, how does this work? Then they're like, OK, we haven't thought of that. So that back and forth would take the longest or you would be like, well, I had something way simpler in my mind. And then you have that discussion of, OK, what, where

are you going to go here? Are you going to go towards the end solution or something in the middle and the product will have to jump in between as well and make a decision at the end? Yeah. And I think something people forget is that we are all also users, right?

We are also, we are also consumers of our own product and something that I liked when it happened in in in their own clients or in a product team is that you come much earlier with your concept and you get everybody in the team regardless of their, you know, their role to poke at it. And it can be from your own perspective if you're a front end there, you would say, yeah, this is going to be difficult to

make. If you're like if you're saying OK, this is going to be hard to cash in, like there's a lot of information in this table. This is practical things, but also I love it when like the security engineer says like, yeah, I don't get this, it's not clear. Maybe consider doing it differently cause 'cause that's super valuable. And if I if I just say yo no it doesn't know anything about design, I would lose a lot of

insight. So again, I'm I'm not a big fan of the agency, working in the dark, coming in, throwing in designs. I really like the product team like you mentioned, but there's also ways of introducing it into your process that you're getting the whole team on board with your designs because sometimes maybe there's logic to to all the designs that they made, but you were not there. You don't. You didn't get the whole process of how did they come up with this, so you're just judging the

final outcome. Absolutely. And yeah, of course, of course maybe there's smart people that made great choices, but you're kind of like, I don't get it. That's the that's the worst part. Are the worst situation to be in. And you're not really empowered in that sense. You you just like how you call it, like you're just on the delivery side, just make it and that's that's not fun to anybody. No, that's I agree with that.

There's a thing you mentioned about feedback, which I think is interesting because I have the same challenge from a product perspective. Whenever we deliver a feature, whenever we deliver value, we get feedback from the users, sometimes very direct, sometimes indirect depending on the the

size of the organization. But there is always feedback and especially if you're building an internal tool for an organization and those users are right next to you, everyone expects their feedback to also be picked up. And I feel like from a design perspective, it's kind of the same, right? You you create something, you

get feedback. But I feel like it's very hard to balance accommodating for the feedback as well as kind of believing in your own vision and being like, no, this is For these reasons, therefore the feedback we're not going to incorporate in that way. Yeah. And and this is again when you compromise, right, because well if we had data about everything that.

Would be easy. Like I I just did a like a redesign for for for a journey and it was amazing because we had so much data about behaviour and so much insight about you know where user coming from and we had both direct feedback from users like what we call qualitative data data and we also had quantitative. So we also saw what converts better, where do we funnel and and etcetera.

And what it made is that basically when you design at the end almost all your decisions are based or backed up by something. And this is really and this is really a unique snowflake kind of situation because many times there's a lot of holes. Yeah, also in this case they were holes. But on on the bigger topics, there were quite a lot of things to support you in your

decisions. So when somebody comes to you and say you know somebody from the from your own team saying like, yeah, I don't like this or yeah, I think we should do this, then you can have the conversation and say, OK, but we have data supporting this kind of approach. Even doing benchmark, you know, looking at 10 other journeys that are exactly the same, you can always say they are all

wrong, right. But it does give you a sense of saying, yeah, if we do this, this is really different from what users are used to. There's there's more risk there. So this, this is where where I like it. I never say no to any feedback and always try to understand the, the, the underlining issue that the person has, right.

So maybe you you finish something and you're quite confident in it and somebody comes with like a feedback out of nowhere and but it's yeah, it's always good to just try to understand, ask why, why, why why and realize OK, they actually have an issue with something else or they didn't understand or they don't have the full picture.

So, yeah, but it is, it is quite rare like always we, we have a lot of assumptions in what we do and even when we validate, even when we go in and do you know, interviews or even try to collect, you know, track user behavior, there's always interpretation, yeah, and bias and et cetera. So it's never perfect, but that's why we still have a job. It's never perfect. So you know we need to I prove it. I really like that you say the

the data wins right at the end of the day whether that's market research before and then based on that you foundationalise your assumptions or UAB test and you figure out OK, this decision actually even though everyone think thought it wasn't going to work, it actually made the most sense out of the data. You have to make those decisions and at the end of the day it is easier the more data you have I feel like. Yeah, but. But there's still human decision

at the end. Yeah. So even if the data said, OK, we should really go for whatever make the font huge, right? We all love that. Can you make it bigger? So yeah, data showed that this makes all the users notice this. Yeah. But then you're really isolated on one thing because once you made all your, all your users or customers users is a tricky word. We can discuss it later.

All your humans they noticed just that big title they forget about other stuff so they've been they varied from other journeys or other things they're trying to do. So even with data you can say it's it's always, always wins, but it's also how do you, in what context you put it in.

And this is the interesting part and this is where as a a user experience designer you can really bring that overview of kind of challenging and saying yes, we have the data, yes we have your opinion, yes, we kind of know what the user is trying to do. But let's let's look at the bigger picture, let's analyse it a bit deeper and yeah, and at the end you always have a stakeholder that comes in and say like, yeah, I don't care, I just want it this way and that's

also legit. Like I feel like that is the art. Because you from a decision making standpoint, whether that's UX, product, even development, you want as much feedback as you can right from people as well as data. Yet you still want that decision power with yourself. And at the end of the day, you want to make a decision but still don't break any relationships because otherwise you lose that feedback, you

might lose that stakeholder. And the more people that are in your corner, the better it is, I think for the product and what you're creating basically with your business. So it's very hard to accommodate for feedback, have people feel acknowledged even though you're saying no. In a way I love that you're saying.

I never say directly no. I try and understand where the feedback is coming from, because in that way you might still give that sense of fulfilment to someone while still disagreeing with their feedback or doing something else based on other facts basically. Yeah, I sometimes I wonder if we

spend more time convincing each other than actually doing the job. But I yeah, I guess that's part of the process and what makes good product and what makes the team work well. So yeah, sometimes you kind of like it's really obvious and when I say obvious, it's like based on experience it's obvious this is what we should do.

But then you have to convince a lot of people and you spend a lot of time not figuring out the solution but just getting the buy in on that solution and that that can be a bit again, going back to the frustration part of yeah, why, why do we have to go through all these loops to get it happen. But, but buying is super important because when something goes, goes in the funnel like when it's when you decided this is the direction, this is solution, there's a lot of

impact. So people are going to start working on it. It's going to be, you know, published, it's going to be live, Users are going to see it, interact with it. It's going to have business

impact. So so yeah you sometimes you forget like maybe I'm just moving here to pixels but there's so much like a snowball effect and and something nice we had in the past is that we said OK as a designer is our job is to make sure that when our solution comes in the hands of developers we did all we can to ensure this is the the the lowest risk effort you you can do. So basically we did all we can to validate that this is a a

good idea. So when somebody is now going in and looking at the design and trying to implement them and trying to build that solution, yeah, they are confident that they're not just wasting their time and that's going to be thrown out of the window in two seconds.

And and I I like to put that in the back of my head when I, when I go into a design process that I have responsibility to make sure that you know, people working on this, they have the confidence that they're not wasting their lives. For some, Some like a whim. You know, some designer's whim of yeah, we should do this, yeah. Yeah, that's an interesting one. I I agree with that.

But also to play devil's advocate, there's kind of a right time, right place for that. When you're at an early stage and all the features matter basically because time is at the utmost importance, then I think that holds true. But when we're looking at kind of a further stage in a product where you're working more towards multiple scenarios and you're you really want to test

in production what works best. I love doing something and then being like OK, is this actually going to matter or not from a development standpoint? And then I have no problem throwing it away if it doesn't work. We had this kind of optimization in a check out and we had the assumption together with design that OK, from a check out form perspective we can make it easier for people to see what data they need to fill in. So we added colours and I was

like, OK, as a guy, like there's a male percentage. 10% of males have like an issue with colours. It's like a colour deficiency, basically. They call it. So yeah, I'm partially colour blind. So it's like this is not going to work for me. How about we also do shapes, give me a check or give me an X or whatever. So we incorporated that as well. And then we all of a sudden had three variants, the existing, the new colours and the one with the icons.

And all of a sudden the ones with the icons made the most sense out of the data. And I was like, OK, I have no problem removing all the colour stuff even though we built it.

I built it as fast as possible to see if it would work basically with that in mind and then the work that you create, even if you do just a regular AB test and your new feature doesn't actually make any difference, then I do think we should throw that away because the simpler we have our application, also from a tech perspective, and more code, code is like a weight. The less code we have, the lighter we are, the faster we can go.

Well what you're talking about is kind of like fail, fail fast, right? And and what I'm trying to say

is that it's easier sometimes for for designers to fail fast than for developers because there's more loops you need to go through to make things you know live. And for me to make a prototype, I can do it in 30 minutes and make a really extensive prototype and just go and see if

it works or not. So there is also that in in the mix and if if designers tell you like, yeah we don't, we don't want to waste time on it but that's that's our job like to do. So yeah, this is a small example, the icon, but when you go in like a bigger feature or bigger change, then that's going to be a lot of effort for you to make it, to make it live right. Very true. Yeah. And and for me will be quite fast. So it's like unfair how fast?

Yeah, yeah, yeah. Well, but it's not, it's not the real thing, right. There's there's a lot of tools now to make it to fake it as much as possible but it's different. But I, I, I of course everybody in their own lane should try to experiment and and and basically evolve their products as much as they can. Sometimes you are getting caught in all this process and all this you know everything needs to be evaluated.

You know, we need to refine it before we actually go forward and you kind of feel like OK, I just. Yeah. I don't have the opportunity to just experiment and try things and just throw it into the wild and see what happens. Yeah. But yeah, that's again depends on the culture that you're working in. Absolutely. And how much you empower people in the in the team to do these kind of things? Yeah, for sure.

I was thinking of kind of the the skill set nowadays of first of all developers which are quite broad. Yeah, front and back end data engineering more so. AI especially nowadays which is kind of more booming, but from a design perspective it's it's super broad as well I've realised and I don't think many people realise how broad it could be yet we might sometimes expect the world out of in a

product team. It could be one designer from a research perspective, from prototyping to actually visual design, and then market research and user feedback at the end. Like all of those could be separate job in and of its own exactly. Sometimes it's only in one person and they first of all have a preference, they second

of all have experience. So what they're good at, And then third of all probably want to learn a lot of what they might not be good at or be really go deep in what they're already good at and make that even better. Do you feel like it's it's too much right now, 'cause I've and it's funny, I heard that recently. I've heard the term full stack design. What is that? Terminology in the design world is a topic. If I start talking about it, it would never stop. And also I only have my opinion

and it's really funny. But yeah, I call myself a product designer, right. If I go now to a company like Philips, a product designer is somebody making physical product. So it's already I'm off. I now work for an automotive company and when I say product, they only mean one product, the car. So. So that's just one example that it's also broader than just the design industry.

There's a lot of yeah trends and yeah you you have the full stack designer, the Unicorn designer, the I can do it all and if we're being honest there's always for every designers there is a strong side and and areas that they need to either get support or they are looking into doing more and this is the nice. I think the nice thing about it is that when it's not that harshly defined there's more chance for you to kind of explore these other avenues. So if if I call, if I call

myself a UX designer, right, user experience, then it means that either I do really early stage discovery and research or like before we go into a visual design, wire framing and flow, you know, flow, charting and all this kind of stuff. But that kind of gives me a limitation. But you see, even in in a UX designer there's like a broad sense you're. Really scientific about it.

And there's like, yeah, there's people that are really, really research, Harvey. And there are people that are still kind of close, more closer to UI designers to user interface designers in the sense of they want to make stuff, they want to, they want to try it out, they want to play with it. They can't even do a product from zero to to 100. So I I have so many opinions about titles and I think it's always about the person and how they frame their own expertise

in a product team. I I would say like the my current set up is basically I'm a I'm a UX designer, but I also do UI work and I have a whole research team support me because it's a lot to also run the research yourself and do the interviews, write the scripts, all of that stuff. So I I feel like depends on the scale of the solution and the scale of the product. You got to have support and yeah maybe you really want to learn about running interviews.

So if you have a a researcher with you which is another type of I don't know designer you can join them and you know take notes and learn and and etcetera. But you you got to have, you cannot have everything on your back for for for bigger project. But yeah, I don't know how you experienced it with your designers. And many times when a designer tries to do a bit of everything, yeah, something falls. So we cannot be good at everything even a full stack developer cannot be good at.

Yeah, I know. I know that. Exactly. So, yeah, but it is, it is. It's an interesting topic in the industry and it went to a lot you had in the past. Gooey designers and web designers and mobile designers. And I'm like, why is it just limited to one platform? Yeah. So yeah, I I like to call myself product designer because it's kind of fluffy enough to give me a chance to do a bit of everything. Yeah, I think so too. Yeah. I mean, from a product team, I

kind of know what a product designer would do or can do. Yeah. I mean, especially now from a product manager perspective, I like asking people what, what they want to do because I feel like want is a big thing. If you want to do something you have, I mean first of all, passion a certain drive for it and I can enable you to do that. From a product management perspective, I can see opportunities and put people in the right places to do so.

Then also try and learn kind of what their experience is. So what they, what they've already done in the past, what they might be good at in that way. And I try and accommodate and leverage that to whatever we need to do and if I see there's holes in there and then it becomes those are kind of the challenges we need to overcome. So also for design, right now we have a very large, I would say development team which needs to be needs to be fed with

basically work. And the organization is more and more I feel like more organizations I work with which are software heavy, really rely on market research and design and are very design driven. First of all, I think that's a really good thing, right. We we cannot just exactly as you said, the time investment to create software if it's the

wrong thing is a big investment. So we try and do enough research to make sure we're building the right thing and then still we can experiment and see how to tweak it. But at least we know everything is feasible, right We do our best to do so. Then it becomes a bottleneck if you have only one person kind of feeding the development team in

that. And then there's still a preference of let's say I have a person that loves to do most of the research perspective and their balance in what is feasible is different or their appetite for what is feasible is different than from either the business or the development team. And then we have to manage that. I feel like that is that might be the current situation I'm in, whereas the bigger team you have, the more work kind of needs to be there because more work can be created.

So then the funnel basically, which is the design team that gets smaller and smaller and more narrowing that way. Yeah, this is actually a rare occasion that the designer is behind development. Like usually the designer is like quite fast to create a lot of concept or a lot of ideas and then that's being fed quite, you know, quite a lot. So you're in a luxury. Or that designer, maybe you feels the pressure, but he or she feels the pressure.

But yeah, it at least there's the, the the firepower to make it happen. Yeah, but I do recognize what

you're saying and you always have to decide where your focus are. We early stage, we need to learn more about what we're building. Are we kind of like in the middle? Is it about like what is the critical features that we need to add? Or is it again the more later stage of really small informations of of refinements and each one of them has their own challenge and and kind of different slices of the pie of

the time you need to invest. But yeah, it's always, it's always better to work with more of your kind around you, you know? That's how we are. We're stronger as a as a as a triad, absolutely. And and the same for designers. Like it's it's, I find it really

hard to be a solo designer and just work in isolation. But how many? How often has that happened? Because I feel like that happens more often than it should. Wow. It's it depends. But yeah, in IT, it happened in in in my career, yeah. But I always found ways to to bring other designers closer and collect feedback and etcetera. So even you know we work as part of a company. So if if you're an agency or if you're a consultancy, yes, maybe you find yourself in a product

team alone. But then there's other product teams in different clients or different areas of the organization. So you do need to find your, your, yeah counterparts. Kind of like, who can I ask feedback from? I I cannot design more than two hours without getting somebody else to look at it. I I feel weird. It's kind of feels like what what am I doing here? I'm just, you know like a cow eating their own. That doesn't make any sense. So yes, I always call in somebody.

I even talking to somebody, like not giving them. They don't really need to give you like the most crazy in feedback or insights, but you just need that collaboration. So when you when you're finding yourself isolated, there is ways to reach out to others. Now what you refer to is actually doing the work. And yeah, if you're alone doing the work, then it's also a lot of prioritizing.

And what worked for me is that I know there are things that are low risk, so like core features or things that you know by doing quick benchmark just looking at the competition, I know all of them have that feature. So I'm like OK, I'm going to reduce. I'm not going to invest time in researching that. There's low risk. I don't need to validate. I will just make that.

Then that goes to the development team they have, they have enough to run with and then I can really take the risky areas of the product and explore them or the more innovative things and and that's also a way to mitigate that time management. But you always start by OK, this

is low hanging fruit, Let's just get this done and then I don't have the pressure of. Time. Figuring out what to do. Yeah, 'cause research takes so much time. I know how how how many people know. But just getting So first of all, you need to write the, yeah, kind of definition of who you want to interview, right? I'm just talking about the qualitative in this case. So you need to explain exactly who you want to interview, right? Define your your persona or define your target audience.

Then you need to somehow find those people, right? And then you need to book their time. People are busy. They don't have like, so it's if you're if you're if you want to get like eight people to talk to, it's going to take you two weeks to go to schedule them. Yeah. And then you need to write the script of what are you actually when I ask them, you know and you need that to be refined a few times because when you write it first time, it's super biased.

You just ask do you like this feature? Yeah. I really like this feature. Do you like. So you also need to have some time to process your own questions, yeah? And then if it's also there is like a visual materials, there's a prototype, or you're using your current website, or you're using the current existing app, you need to prepare that as well. So that needs to be in place.

And then the really annoying thing is that when you're done with the whole interview, you have all these great insights. They are all stuck in a table somewhere. You need to actually distill them. You know, you need to actually summarize them and make them visible to others. Like if you did a research and everything is stuck in your head, that's useless. Next time somebody else comes in, they don't have the record.

And that also takes time. So yeah, that was just my way of saying, yeah, research takes time and sometimes you you, you're kind of finding yourself at the end. OK, A classic thing is that a stakeholder says, like, yeah, we should do this. And you're like, OK, we need to validate. It's like, no, this is obvious. We should just do this. You're like, OK, but let's, let's run a test. It's like, OK, fine. And then you done the whole test, the whole thing I just

talked about, right? It's two weeks of waiting. There's two weeks of processing. And after a month you come back and you said, yeah, you're right. And then I told you so. So why did we do the test? You know, why did we interview all these people? Yeah, yeah. It's it's risk versus reward. I feel like and I'm I'm really curious in this kind of suite of

let's say creating a product from a design perspective as well as from a software perspective, when do you involved in software engineers because you said you already like that kind of dev development, pairing session for example. But I feel like I'm also biased. I feel like if I were to be at the research side, I would also gain valuable insights in understanding whatever we're

doing here. Yeah. I'm I'm I'm on your side on this again in in more tight teams I had the whole team members they can join the interviews and basically as a note taker. So they're in the background. They're not visible to the to the interviewee and they can also ask questions like hey, he just said this weird thing can you ask him And I'm I'm getting a text message of like saying OK this is an interesting question from my front tender, let me ask

that. And it really gets them in the mindset of what we're trying to do. So even when they are now we're discussing a new feature they say, Oh yeah, I remember when we interviewed David, you know he said that so this is really critical, but I actually think he meant that he wants this feature.

So can we tweak it. So you're getting all that cycle and this is perfect, but it's it's again, it's about of time investment and return on that so your your team members can write code or they can sit and listen to somebody. Bravo about a feature. So it depends how stressed you are. Yeah. Yeah. Talking to you as a product manager, yeah. Yeah, no, I was thinking like I I don't want to choose four people.

Yeah, it's it's really hard. If I don't choose four people and everyone all of a sudden decides we're going to do 4 hours of interviews, then yeah, we don't have much time in the in the day left, basically. There's also recordings, right? So you can also look at recordings afterwards or that you make sure the designer and kind of present the results and collect questions or even even from the script phase. So before you go into the interviews, you kind of present

to your team. This is the questions I'm going to ask. Is there anything else you guys want to, you know, ask about? That can also be a way to kind of get people involved. I like that a lot. Yeah. In general, the closer you are, the better it is. It's like a yeah, there's no way around it. I I mean, I fully agree.

It's just, yeah, from that product side, it's really hard because I feel like everything is like risk versus reward and trust. Because if I if I do enable people, I trust them to do their best and stuff like that and everyone has trust by default. So then it's just a risk versus reward. How much do we get based on this, based on X amount of people joining extra. And right now we're very much OK. The team is completely new. It's also a bigger team. Everyone's getting used to everything.

So I feel like we need time basically we can, we can, we need as much time as we can get also to understand what we're doing. Because this investment right now, especially when a team has just formed way of working, creating value is going to return in the future as long as the team remains stable, that's the big asterisk there. So then I'm trying to give everyone as much time as they can also when the domain is most complex to figure that out.

And then, yeah, I feel like I'm just postponing those risk versus reward decisions for later on. At some point I feel like OK, we, we do, we will need to deliver. But right now we're still in a very fresh domain. I really like it and and I think a lot of product managers or team leads are underestimating the the bonding or kind of like the investment in the culture of

a of a team. And before they go and they start like crunch time because if you know if the team does not trust the the designer that they're doing like the best job they can or that they appreciate their effort. So they they think about what they follow through, you're going to get a lot of friction. And the same when the the designer thinks like OK just the frontiers are just they're lazy, they don't want to do it. It's a lot of effort. I want these fancy micro animations.

Why are they like shooting those down. Then you are getting like this conflict and then people will try less and it will be less productive. So yeah, getting that tight team feeling is, is super important, yeah. But it's also a bit of luck, so. It's like magic. Yeah, yeah. You just need to get the right people in the right mindset and yeah. Yeah, I don't know how to do it. I I did have one kind of final train of thought because I thought this was interesting from a product perspective.

I recently had a guest on or kind of recently bond on and he said from a product perspective he's always been in this payment domain because it's just interesting and he's gone from country to country. So he's seen various stages of payments being available to people. And I think about myself from a development perspective right now, most experience I have has been in e-commerce, but I do not want to do more e-commerce like I'm I'm kind of fed up with it.

I want to do other stuff and I feel like from a design perspective you you have these tracks where you can go really deep into the same domain and still go from either country to country, company to company and see various stages of that. Take all the domain knowledge with you and leverage that in

whatever you're doing. Or like kind of my developer experience be like, OK, I've seen that I want to go to the automotive industry and figure that out or I want to do e-commerce or I want to do whatever. And which track are you? Before I say which track am I, I will contradict you and say I think designers are exactly the same. They don't want to stay in there, you know, in the domain for a long time.

We we'd like to specialize. But then it's also really nice to change industry or change like a whole different, you know, if you if you're working on apps for five years, it's not that you want to just keep on doing that. Or I love it when job description says e-commerce experience or banking experience. Or like, yeah, if somebody worked in banking for eight years, they don't want to do. Banking anymore? Like that's the whole point. They're really.

Good at it. Of course they're really good at it, but they had enough of it and that's that's the same. So I I think in general you like to take your superpowers and use them on different planets. I don't know if that's a good metaphor, but but basically you want to be challenged and become a a subject matter expert in a different field. It's like, yeah, I did. I did banking for four years, right? I said like, OK, no more.

I became really good at all this stuff like, you know, understanding all the different tools that you use and already have, OK, what do you need? You need the payment. Fine. I know exactly the journey. I've seen it. I did benchmark for 100 times, but you don't want to do it anymore. And I think the same with like e-commerce.

E-commerce is a bit more fluffy because you can find yourself doing e-commerce for different products and you know, selling, selling cars is really different than selling things like that cost $1.00 on Alibaba, whatever. So there is a different challenge. But yeah, I think we're all trying to kind of be challenged constantly and make it interesting. So I don't think there's, I would like to specialize in a in a field.

There's maybe things that you find more interesting, but I will give you a really quick example. I had a project about a process of auditing products. So it's it was a really weird thing. It's basically the whole process of when something is manufactured, let's say you you wear AT shirt that T-shirt is says a Nike T-shirt, no sponsorship and basically that is being made in a factory. Then that's been packed, it's been shipped, it's been whatever, distributed to shops.

And then a client buys it. There's a company that checks the quality of the product in every step of the way. Oh wow. OK. And basically I came into that having no knowledge about this whole process, right. And I've been asked to map this entire journey like this entire service and and basically find the areas we can optimize. And again, I don't know anything. And the first day I'm getting like all these abbreviations and terminology and I don't know

anything. But that's exciting because you're getting to learn something. And this is like a whole different weird thing. I didn't know, like somebody actually from a company goes into H&M and buy a shirt and takes it to a lab and tests that this is the same shirt that they tested in the in the factory.

That's the phrase. Yeah. So this might sound like the most boring project ever, but actually doing it was kind of cool, You know, it was kind of like, whoa, this is a whole different industry I never knew existed. So this is what's I think really nice about our field is that we are kind of agnostic and we can find ourselves in different clients, products, platforms, everything. And that's really cool. So I think I kind of answered your. Yeah, yeah, I think so too. Lengthy way?

No. It's. I I mean, I'm biased, right? I I agree with that, that the domain for me is most interesting. I do however see that like this ambiguity, you have to kind of be comfortable in it, right? You have to have that curiosity. Dr. You, any other person could have been like, what the Hell's going on with these abbreviations? Like, I I don't want to do this basically.

And they run away and they go to something they're more comfortable at or something they've done before and they do the whole process, for example, at Nike, Adidas or any other clothing store, and it's the same process basically. They'll be like, oh, how does it work here? And oh, it's still kind of the same, maybe some slight differences. So yeah. Full respect, like if if this is your thing, then it's it's whatever floats your blood exactly. And I don't think there's a right or wrong.

I just really don't see the other side yet from a product perspective. I do get it. And actually from every perspective because you're so valuable for, for an organization and with your e-commerce example, from a development perspective, I'm like OK, Alibaba or like selling one product or millions of products might be kind of slightly different or get more complex, but it's still kind of the same.

If you have a basket you check out, from design perspective it might still be kind of the same and and different, but yeah, from a park perspective you do know what to focus on then I guess it's it's. So different. Like I I worked for a glasses company, eyewear and I work for an automotive company, right. They both have a Configurator, you can configure your product configuring your your glasses, right? Like you would get to you went wild €200 you know configuring your car.

You know that's that's a different aspect and you use the Configurator in such a different way and the functionality is so different and the kind of reinsurances or not reinsurance insurances that you need to have when you go into that process, they are so different and and and even your goal is so different. So it might be like they're both

e-commerce, right. You're just configurating your your product, but the the the journey that gets the user into that configuration is so different and the the amount of times they go into that configuration, You know when you when you're buying a car you will go probably five times and try different things and and you know your journey is so much bigger. When you're getting like your iPhone cover you, you will basically go to two or three

times. Yeah, just, you know, I'll just get the cheapest or the one that looks the best. Yeah. So it even within like things that might be using the same functionality, yeah, there's there's the this challenge of of having that bigger journey in mind. So I I find this really interesting. Yeah, yeah, I agree with that. I agree with that as well. That's kind of a like final,

final thought. Then from from your experience kind of looking back, there's various avenues, right? You have consultancies, agencies either internal at an organization and then different domains as well. Would you say there's like a specific place or a specific track where designers can grow the fastest or or really get to experience the most in kind of their learning journey in that way? Yeah, it's an easy, easy answer

in all of them. Like, you should really jump and try all of it. Like, yeah, I let's, let's put it this way, let me be a bit more serious about the answer. Yeah, I I feel like I I really try to encourage also my team members to explore and try different things and it's also team set up. It's also you know that you work for a product house, you know for like a big tech company for a small start up famous agency, unknown agency, like it's all so

different. Sometimes you just take take you know take your chances and if you go for an unknown brand and that brand really grows and you you win. You know you you kind of grow really fast and you get to experience that and sometimes you actually learn more being like a one of of 300 designers because there's like this huge community behind you. So yeah, I think you should just try all of them and find what fits you. And we all again we have it's it's it's a long life.

You know we have many years of being in our profession. So you have the time to try it all? Yeah, I think that's that's my only smart thing I have to say about it. I like that a lot. Take take all the experience with you and then maybe you'll end up opening a restaurant in Yeah. In the end, and that's it. Forget about your, yeah. Thank you so much for coming on you. This has been a real blast. Thank you for having me and it was awesome. Cool. Then I'm going to round it off here.

I'm going to put all your on socials below the like buttons. Check that out. And with that being said, thank you for listening. We'll see you in the next one.