Episode Transcript
[00:00:00] Speaker A: Hello, everyone. Today's another episode of Can I have it in Blue? And we have a guest from Subvisual.
This is Davide, he's a developer. And today the subject that we are discussing is basically how designers and developers and whoever else might be involved in the process can make projects happen as frictionless as possible. And, and how does that collaboration look like and how that collaboration should happen in a way that we have the best results and no one has a meltdown in the process. So welcome, Davide.
[00:00:40] Speaker B: Hello.
[00:00:41] Speaker A: I guess we could dive right in with.
I can actually tell an anecdote as a way to begin. Unfortunately, had to do some construction work in my house. And, and I decided that the best way to approach this was actually to hire an architect before I jumped into technical solutions. And I have to say, it made the process much more difficult. All of a sudden I had two different teams of people looking at the same problem. They were completely disconnected from each other. Actually, when I reached out to the construction workers, they panicked when they saw the project that the architect had developed.
And immediately they start putting a lot of breaks in the process in the sense that they were finding all the problems and they had none of the solutions and it died. And so my solution in the end was just to hire a technical team for them to look at the problems, solve the basic problems. And I had something that was better than I had before, but way, way less than I had initially int for the project. So basically I threw a bunch of money out the window with the best of intentions. And I cannot help but see a parallel between what we do and how basically for me, this represents how designers and developers approach problems in such a different matter. What are your thoughts on this?
[00:02:13] Speaker B: Yeah, unfortunately, that sounds very familiar. It's a reality of the developer and designer sites where we, we see a problem and we have different interpretations of how we solve it. Designers will probably go a different route. Developers try to fix the issue or try to find the solution that make it work, but not make it pretty or something like. Something like that. So, yeah, I think we can get a closer working relationship between developers and designers like you have with the architects and the construction team. But in the end, the same issues will always appear because we have one, one problem and two different ways of solving it, and we just try to find the best solution between both solutions. Yeah, I think that's a reality of our work and we don't have that. Yeah. What are the key.
[00:03:02] Speaker A: I think in the end it really.
Not in the end, but one of the issues would Be that it really boils down to an imagery that I have in my mind, which is a funnels. And we open up possibilities as designers. We're exploring, we're finding new solutions, we are finding new problems that we want to solve. And before we even get to funnel it down, you guys basically come in that part, which is to say, sure, we have all these possibilities, but we only have so much power to make these happen.
And so it creates friction. Obviously we're going in two different directions. Of course, part of the design process should also include funneling down solutions in the sense that we need to prioritize what is most important to solve. Now this is a process that inevitably should go through a team of developers. So that's where the developer understanding the design and understanding all the context behind all the possibilities that we're exploring to also be able to help out and have a vision and say with this amount of time or these amount of funds, whatever it is, there's only so much we can build. And if we're trying to solve these specific problems, then this might be the best way to go. And so for that I think there needs to be context on all ends of the, of the process.
The developer maybe should look at user research too. Maybe, maybe the developer has a lot on their plate, but it can be interesting for the designer to actually present findings to the technical team to so that they have context for their decisions.
[00:04:48] Speaker B: Yeah, 100%. I think the sooner the developer gets involved into the research flow and the design sprints and the entire design work per se, it helps a lot of the project because we can get a more realistic sense of the implementation that we are going to build. In the end, I think there's a nice parallel between the developers try to converge all solutions that the designers try to come up with. So we have the, let's say a customer or a client comes to us and I want to build something, but I don't know exactly what I want to build. It's the responsibility of the designer to say, okay, you can have the entire world. We can give you everything that you want and everything that you need. And then a developer comes in and says, okay, let's make it realistic. Let's try to scope this down to the essentials. Let's try to build an MVP first. Let's try to make the essential happy path and then we can make all the other features and make a roadmap and go from, go from there.
[00:05:39] Speaker A: Yeah. And I even, I even believe that there has been situations where when involving Developers on ideation stages, they also have inputs that are interesting in the sense that sometimes maybe I can suppress certain ideas because I think that they're not feasible or that they will be too demanding for the developer team. And it's actually not that tricky. I maybe have a perception of something that is undoable and I will not explore that possibility. But there's been situations where developers have aimed higher than the designer themselves and go like, no, actually we can do this, we can go ahead and make this happen in a fast way. I guess that's. We actually wanted to touch this point right about AI. And how about now it's more possible to achieve certain things in a faster way. I guess you felt that on your end too, that I've been in projects where developers have pushed for quicker implementation and aiming to have things faster in a way looks good and works well, especially for testing, which is super important.
[00:06:46] Speaker B: AI tools have been a very big improvement on the feedback loop that we had recently.
Last couple of projects that I've been working on, I've been using them extensively, both on the design side and the development side as well. It helped iterate a lot faster than we had previously before. And we had a project where we had a designer developer working with the business person and the client to build an MVP for next week. It was a simple mvp. It was a very simple project that we were going to do. Designers started implementing the figma. Then I came with AI tools and say, okay, I want to build this. And from one week, from one week to another, we had a build build, we had built a prototype where we could show the actual client of this is how it's going to look like this is going to work this way. Instead of having the design on figma and then waiting for the implementation.
[00:07:37] Speaker A: Yeah.
There has been a recent situation with a given client where our initial idea was exactly to go through or go use the route of prototyping with AI instead of jumping to the development and then testing. So we found that it would be a faster solution. Then we ended up changing our mind. The feedback we got was that maybe it would be equally as fast to develop it. It ended up not being. And it's interesting to see that we could be just going for a certain hype and like there's this new tool, there's this new shiny tool, let's use it. And that can be a hit and miss kind of situation. But in this case we should have followed the hype. And that's where I have a question for you. Is that where are the limitations here?
Because prototyping with AI right now feels kind of like a simple solution to a complex problem. And that's usually, usually sounds too good to be true. Many times it is. So what are the limitations you find here?
[00:08:48] Speaker B: There are a lot of limitations still.
It certainly helps a lot.
But you kind of need to know exactly what you want to build. So in a sense you can just go to the AI, say I want to build my new shiny platform and have the AI built it. We need someone that has the knowledge, that has the experience, that knows how to guide the AI.
We need to have some way of saying I already know what I want to do and using the AI to get that faster. You won't be able to just go to an AI and say, build me my next SaaS enterprise build project and that's it. You also need the developer and designer with experience to make the AI make the best decisions. Because there are still some limitations still, especially when converting Figma designs to actual implementations. Sometimes the colors don't match, the spacings don't match. There are some things that you should look at. Oh, this is obvious, it should be this way. But the AI doesn't know exactly how to make it, how to make it. So you need to adjust it. Yeah. And then there's also the performance side of things. It's very easy for the AI to just give you the, it's working, it's a mock version, it's done. But when you actually build, when you actually build something that's a production ready system, you need to make some other decisions that the AI will not be able to do it. So in terms of limitations, I think those are the main ones. It won't be a simple one shot solution. It will help the developers and designers iterate faster, but you still need to have someone with the knowledge and the skill set to make the right decisions and tell the AI I want things to build this way and don't let the AI just build whatever.
[00:10:19] Speaker A: So is there in this process a moment of design decisions translated into developer decisions and then prototyping, or do you see some autonomy on how to make things happen?
[00:10:31] Speaker B: I don't think there's a need to have designer, developer and then implementation at the moment because the sooner that we get everyone on board and the sooner that we get everyone on the same page, the process will go a lot smoother. It helps to have designers with development experience. It helps having these developers with design experience just so that we speak the same language.
It's more Work to say, oh, I need to have the 16 pixels padding. Instead of just having a designer, instead of having a developer look at the page and see, oh, this is not correct, this is not the same size. We need to make this the right way. And it's not a question of being pixel perfect. It's more. There are some UX decisions and UI decisions that the AI will simply not care about and you need a developer or a designer to look at it and be critical.
[00:11:16] Speaker A: So I guess something that I am always wary about. These scenarios where people need to be synchronously doing work on the same object and they're from different backgrounds and have different sources of knowledge, everyday communication becomes key. And everyday communication, especially in environments where people are working remotely, can be a challenge. I think we've moved past the stage where we thought it would be the solution for every workplace problem. It created others.
So what do you feel like it actually works for you? Like, are you the type of person that goes for meetings every day if necessary? Are you more of a fan of keeping it asynchronous? What do you feel like it works best for teams from. From what your experience gives you?
[00:12:06] Speaker B: I'm going to give an answer that it's not an answer, but it depends. I think it depends a lot on the project. It depends a lot on the team, it depends a lot on the context of the project itself. Let's say that we have two weeks to build an MVP or two months to build an mvp. Those will be different timescales that we can operate with. So in a two week scenario, we probably need to have more regular things and have people align more daily just to see that we are moving on the right direction. When we have two months, we can prepare a bit more and then, okay, let's take a couple of days to prepare to scope out some next week's work and then we work independently and when we have some questions or some doubts, we just sync or send a message or whatever. The context of the project depends a lot matters a lot as well. I personally prefer to have as few meetings as possible. I like to prepare things ahead. So if I already have a big planning session and I know what I'm expected to build and I know the direction of I need to go. I don't need to have a regular check in every day saying, okay, this is done or that is done or now I'm going to move to this. We just need to be aligned in the beginning and then keep the regular check in saying, we are still moving in the right direction and things are going as we wanted to because we also don't want to have people just isolated in their own bubble building stuff without having the feedback loop. I think the feedback loop is very important, especially between us and the client, but also between the developer and the designer as well, because we need to make sure the implementations actually fall on the design expectation.
[00:13:33] Speaker A: I have to say I'm probably closer to the other end of the spectrum of people that are for preferences of communication. And I think that also has to do with the kind of black screen that exists between designers and developers, which is not understanding the technicalities of development. And in my case, what many times happens is that in asynchronous communication it's harder for me to understand what actually is happening than by having a meeting. And I can ask as many questions and not be spamming a chat. So I'm more of a, more of a meeting regularly person. But I fully understand that if you want to have a subject to discuss, it makes no sense to do so every day. But for example, for me once a week might be the minimum I'm willing to go in terms of regularity of communication.
[00:14:31] Speaker B: Yeah, my, my preference is to have as few meetings as possible per week. But in reality I ended up having more huddles and quick syncs and chat messages throughout the week than my, my ideal. But that happens and that's perfectly fine. We just want to have people aligned. And if it takes everyday stand ups or once per week stand ups or every every couple of days, that's the reality of the project and we need to adapt.
[00:14:56] Speaker A: Yeah. And I believe that might be something that is also specific to, to developers because of the typ that you are doing, which is a bit more individual when in the case of designers, especially if there's a PM involved. It makes a lot of sense to have more than a once a week communication on how the design is evolving because a lot more decisions or a lot more work ends up being done per day. I would say on average the amount of screens a designer will make in a day will probably be a lot more than a developer does, for obvious reasons. And so it's very important for us to have very quick feedback loops and to see progress. And for that we are heavily dependent on all the other inputs because somehow we end up kind of steering the ship on an initial stage.
So it's a bit, it's very difficult for me to work in a project where there's not like constant communication. Maybe it has to do also in the types of companies that I've worked for, bigger or smaller. And bigger companies many times require a lot more meetings because there's a lot more people involved in the processes and we are usually working on smaller teams. But when you have big teams, it's really hard to go around having all those meetings. And so maybe I got used to that dynamic, but it's true that it can create entropy in certain situations where you make a decision, then you have another conversation in two days, and all of a sudden you end up having a completely different solution. Meanwhile, developers are checking in every week or every two weeks, and all of a sudden everything changed. Like, all the design has changed and like, I thought we were going to implement this solution and all of a sudden you have three more features than what we began with.
I believe that that can be also overwhelming for your profess.
[00:17:03] Speaker B: It is. And I have a very recent experience with the same topic. I think the more people are involved in the project, the more meetings are required to get everyone aligned. But also there needs to be someone taking charge and saying, I want this to build, I want to build this this way. And that's the final decision. We can't have too many, too many people saying, I think I prefer this way or that. That feels right to me. Someone needs to be the, the decider and say, no, this is my final call. We are moving forward, everyone's aligned and we can, we can't keep changing everything because, yeah, we can get stuck in a faster iteration loop and the iteration loop gets faster every time. Or with recent times with AI stuff, it's been getting faster and it's very, very easy for us to keep iterating without moving forward. And I think that's a. That's one of the concerns that we currently have about AI, where we can just keep iterating and keep designing and keep planning and we don't build anything. Despite being so easy to do things and implement things right now. If we just go. But I think this feature should be that way, or this button that doesn't feel right, or that place for the table needs to be somewhere else. We get stuck in the, in the feedback loop. I think that's why it's important to have a developer join the design decisions and iteration as soon as possible. Because we can get some decisions that look easy on the design and be a pain to implement, or we can get some potential painful implementation that will fetch data from everywhere and join everything, but in reality to be a very simple implementation. So the sooner we can get People aligned with. I keep saying the same thing, but I think it's very important to have designers, designers, developers and clients aligned on what's possible and what's the plan for us moving forward. It's very good for the project.
[00:18:47] Speaker A: Yeah.
And without this ongoing collaboration, there is this moment that can be extremely scary, which is the handoff moment, where all of a sudden we have this almost ceremony like situation where the designer presents everything, all the work that they've been doing, and developers now have to pick it up and make it happen.
So handoff gains this dimension of like a pivotal step on how the project is going. But should it be a single moment or should we be doing this as progressively as possible instead of just focusing all the attention on this single moment of delivering the design? It shouldn't be a surprise moment. Right. But somehow it happens so many times.
[00:19:43] Speaker B: I think the worst thing that we can get as developers is someone coming in with the finished design and they just say, here's a design, now you go build it. What do you mean? I mean, there are some decisions that we don't know. There are lots of assumptions that you made about the project, about the tech stack, about the situation of the, of the project that we don't know about, looking at the designs. And if you just have one single handoff moment, you're going to be stuck looking at a final product. But you don't get all the context about all the decisions that were made until, until we got to that point. So, yeah, I think the endoff shouldn't at all be a surprise. I think the developers need to be aware of the. At least have some ongoing awareness of what the design is doing. And maybe sometimes it's possible to do, sometimes it's not. Because we might not be able to start the design until the design advanced to a certain point or we need to be building some other infrastructure stuff and there's not enough time in the day to build everything. Yeah.
[00:20:39] Speaker A: Okay, so we are here, we're talking a lot about, about the. Before the handoff. But I also think that there's then a responsibility on both ends to keep the handoff or the. This process of delivering design ongoing after this moment, in the sense that, yes, you have a moment to present the designs, but then everyone should be still communicating because certain decisions are going to have to be reversed. Very likely certain information will not be clear in the design files, as you, as you mentioned. So the developer needs to have full access to the designers and to ask as many questions. And I think that's where asynchronous communication is most important probably, and not so much on the exploration stages, but when building asynchronous communication is what keeps the developer from making a bunch of decisions based on a design file and then presenting the work at the end of the week. And the designer is going like it's not at all what should be happening.
So if developers kind of have this, or in my opinion, developers should kind of have this responsibility of asking as many questions as possible and not assuming things in the same way that designers need to be quick with answering so that then developers are not stuck whilst waiting for your feedback. And it ends up being, I would say in terms of communication, even more intense, or it should be even more intense than initial stages in what comes to regularity of talking and knowing what's up and having designers attend the meetings where developers are presenting their work and discussing their work with each other, not be completely disconnected from, from that process. I think it's not something that I do often or many times, but it's something that I would like to do more definitely. And also it creates this opportunity of actually learning how things are built on a very high level. But learning something about the implications of what you designed, I think can be enriching for designers too.
[00:22:48] Speaker B: Yeah, I agree. I think there are some cases where it makes sense to have the designer come a bit earlier into the project and then wait a bit for the developer to come in at the same time. The designer might not need it to be in the final, final stages of the project, just some minor implementations that are needed at the point, that point. But most of the project should have an overlap between developer and designers because the communication is also very important. And also when we start implementing things, the client will look at it. This is not how I imagine it, or this looks good in the design, but the action implementation doesn't feel quite right and I don't want this feature to work this way. And then the designer needs to do some last minute changes and we need to be aware of the implementation decision we'll make. And sometimes we are developing stuff and implementing stuff and we find something that wasn't in the design or it wasn't planned on the design. We can just send a quick message or have a quick call and say, hey, in this scenario, what should I do? The designer can look at it five minutes and say, oh yeah, that I totally forgot about. It should be this way or that way. And it saves a lot of time and it saves a lot of meetings and back and Forth just as that communication between the developer and designer during the actual implementation phase of the project as well.
[00:23:59] Speaker A: Yeah, it's true, I hadn't thought about that, but that actually happens many times that the designer doesn't actually take into consideration all possible scenarios that obviously are going to go through the hands of the developer in clearer way many times than for the designer because there's all the if thens involved. This is my, my technical input on this because of all the possibilities that are involved in the scenarios and it's hard to actually, and I don't know why exactly, at least personally I don't have this skill of anticipating all the possible scenarios that might happen or knowing immediately all the types of pop ups or success messages that I will need in this or that situation. It's very often happening. So yeah, definitely the designer needs to still be paying attention and the developer needs to ask the designer instead of taking the initiative of coming up with the solutions, even though their input on what the solution should be is super, super valuable also. So, yeah, I guess, I guess one thing that we can, that we can both agree on is that communication is key. And going back to the initial anecdote of the architect versus the construction worker, it was that they weren't working as a single team, so they were working separately. And that can also happen in consultancy where you have a team of developers working completely separate from the designers and communication maybe is not as easy. That is one of the scariest scenarios is that you're not close to the developer's team or as a designer. It can be really scary to, after all the work you've done, just send it out into the wilderness and now someone's gonna pick this up and hopefully do something cool and functioning and all of the expectations answered. So it's very unlikely for that to happen in those scenarios. So communication is important 100%, but it's definitely not frictionless. So there will be moments of conflict which obviously don't need to escalate. They should be healthy moments. But there's definitely those moments where the designer wants something, the developer doesn't, doesn't give in. And they don't have to, obviously, because there will be a multitude of reasons for them to not want to go that direction. But how do we solve that? How do we solve those moments? How do we commit to a single solution without, not without the friction, but without leaving or without one of the parties or both parties leaving the conversation feeling like they haven't been heard or that we're going in the Wrong direction, this is not feasible, or this is not a good result. Have you dealt with those situations and how so?
[00:26:52] Speaker B: Yeah, I think more often than not we are aligned.
I don't remember any situation where we massively disagreed on developer and designer. And in those, on the, on those situations we kind of made a decision by going to the client and having the client say the final decision. More often than not is easier to have a final decision from the client. It's very uncommon to have a designer and developer come to completely opposite solutions to the same problem. We have industry standards, we have best practices, we have UI and UX guidelines, we have implementation code reviews and stuff like that. That kind of guides us to a solution. And the final solution tends to be a middle ground between the best solutions for the designers and the best solutions for the developers. So it's very, very rare to have a complete opposite. I think taste is relative. Right. The designer might have some preferences on the colors and layouts and templates and stuff like that, but I think the developer shouldn't care that much about that part because that's not my responsibility. At least I know that I'm not an expert in design, so I'm going to give my design decisions to the actual designer. In the same sense, I think when the developer says something's not feasible or something it's not technically possible or it will take a long time to implement, the designer also needs to give some middle ground and say, okay, so this is not a priority for now, let's build something else first and get to it when we get the time or when the project evolves to a point where that is possible to do.
[00:28:22] Speaker A: Yeah, definitely. In what comes to more front end decisions, I usually don't feel like there's a lot of friction between developers and designers. I believe these frictions are usually solved by the developer handing off the design decision to the designer and also the designer understanding certain limitations. And I believe in other scenarios where we're actually trying to define the scope of a product and a developer really insists that we should develop this first and not that other thing. That's where like you said, if we're coming from the same place and if we are developing the same solution, why would we be aiming at such, such different directions? But I think that is possible to happen exactly in situations where we all don't have the same context. So maybe the developer was really distant from the entire process of ideation and explor and research and doesn't have this context. So for him is harder to Understand where the designer and where the design decisions are coming from. And it's harder for the designer to trust the input of the developer because they don't know what you know. And this is, this is I think the most common scenarios in defining product scope where, where not everyone was on board since the get go or otherwise you have a, a developer team which is saying yes to everything regardless of then being feasible or not. Which can also happen, but it's not as common, let's say.
[00:29:59] Speaker B: Yeah, I guess that that can happen a lot more in design hand offs than I was aware of because sometimes you just build a design and you ship them out to a third party or whatever to build it. In my experience I've been working almost always with designers from sovisual. So I kind of know the designers. I kind of know I'm already in this process of getting as soon as possible into the project trying to understand the context, trying to help guide the design decisions as well to the actual MVP solution.
When we get a scenario where a developer insists of doing something their way, it's usually because they don't know enough like you said, or they feel that there's some technical necessity to implement first or it's their area of expertise so they kind of try to push it that way because they that way can show more work sooner. Yeah, at least in my experience has been very rare having those, those scenarios where we just disagree and we try to, to make a design decision be the last thing to do because at the end the product will always have a front end, will always be something consumer facing the designer or the design is the first thing that the user will see and at least in my, my point of view should be the, the main guiding of the project. Also there are some development decisions where they can and they should impact the design but I think there are fewer than the design can impact the development, if that makes sense.
[00:31:19] Speaker A: Yeah, definitely does. I'm wondering here if we can actually do like a drill down of the, of the main points we discussed here because for different scenarios we kind of have always circled back to a couple of themes which are basically, I think I can say that communication was one of the main points here is that everyone, everyone's on board understanding context. So having context is for everyone involved is super relevant. Dealing again with the differences in approach or dealing with the limits and trade offs that are involved when handing off or discussing the scope of a project or a product.
And in the end I feel like it all kind of boils down to this is managing expectations, communicating and having everyone on board with context. We don't want. We could discuss this forever actually, but any final words, any advice for our listeners?
[00:32:19] Speaker B: Yeah, I think you summed it up perfectly. I think for fellow developers, you should try to get involved into design decisions when you can because it will also help the project along. There are some assumptions that the designers a lot of times need to do where a developer can solve that assumption in a five minute call. Try to try to understand and try to help the design decision. Don't try to take care of it because it's not your area of expertise. Try to be a part of it. Try to be a member of the team and don't try to build it your your way or the highway. I think that's my advice.
[00:32:53] Speaker A: All right, perfect. Thank you very much. It was a pleasure to talk to you about this. I think we touched so many points and all of them were, were very constructive. I hope, hope this helps other people also understand what are the pitfalls of working with multiple expertises and teams. And yeah, thank you very much for listening.
[00:33:14] Speaker B: Likewise. Bye bye.
[00:33:16] Speaker A: Bye.
