How to work with devs as a junior UX designer

Question

I work as a junior UX designer in a small team of a department (consists of 2 junior ux/ui designers and a non-designer team lead). There is no senior designer. The reason why I emphasize on this team structure will be explained shortly.

So as a UX designer, I have a lot of interaction with the devs... especially the FE/BE developers. And whenever I present the designs to the dev team, the team-leads of the dev team always have something to say to go against my design. Which I totally understand, they have their professional opinions while I have mine.

But one time, I presented my designs to the clients in a meeting, and they were satisfied with the design solution that I've came up with.

And then later on, I presented the same design to the team-leads of the dev team, and one of them had strong feelings against it (not all of team-leads on the dev team, just one of them). And when I asked what was his reasoning, he would just say it is 'too complicated' to build it.

Although, I had my heart set in stone that this is the best UX solution that I could give for the product after a lot of research, but I tried to ask the team-lead more questions as to why this is not feasible other than it being 'too complicated', and tried to give my reasoning why this is the solution. But he just did not want to proceed with the discussion.

And the team-lead of my team, who is not a designer, is just there listening and says he has no idea what to say on the design, and wanted me to go back into my 'research-mode' to see if I could find a better solution. I have to go research again while the clients were satisfied, but just because one dev said it's too complicated.

Thus, I guess my questions are...

• Can the devs get away on opposing the design by just saying "the design is too complicated"? (I mean the UX designers have to come up with at least one valid reasoning, imo, to back up a design solution. But the devs's situation doesn't seem to be the same)
• Or is this because of my lack of seniority and experience as a UX designer that cause the devs just to say no to the design?
• Is there anything that I could have done better in this type of situation? (Should I have asserted more on my design with more reasoning?)

I really appreciate your advice.

Answer 1

It's complicated...I mean, it really is.

It's usually wise not to show something to a client unless you have some idea of the cost to deliver it - and by cost I don't just mean financial, but time, and people. Sometimes a design is creative an innovative and yes it works, but if it's not off the shelf, or doesn't suit the framework or tech stack, then it's going to take extra effort to deliver and that's something that your business should have a grasp of before proposing to a client.

Once you have some experience in working with a technology or a team or a framework, then you kind of get a feel for what's doable within such constraints. And, yes sometimes a solution needs to be simpler than the one that works best - deliverables are almost always about compromises.

However, a response of "It's complicated" shouldn't be a deal breaker on its own. Most things are complicated. You should at least get a breakdown of why it's complicated, so that you know how to simplify or improve the design in a way that makes things easier for implementation as well as working for the client. Besides you need to know this sort of thing so that on the next project, you can factor in this new knowledge and not get the same response again.

But the absolute best thing you can do is to work WITH the developers in designing something. If you collaborate from the beginning then there's no surprises for anyone, and each of you feels like you've been involved and have a stake in the design. You iterate around a solution that gradually takes in the constraints, and the developer(s) can't just turn around at the end and say "It's too complicated" - or at least - if it is complicated, you'll already know this, but will have accepted that the benefits are worth the effort. It's hard to share designs before you think they're ready, but you definitely should.

Developers and designers can't work well together if you shut each other out.

Answer 2

Can the devs get away on opposing the design by just saying "the design is too complicated"? (I mean the UX designers have to come up with at least one valid reasoning, imo, to back up a design solution. But the devs's situation doesn't seem to be the same)

Devs can get away with anything since they are the ones that have to deliver on the design. A rule of thumb is to never design anything that the devs can't commit to delivering, because then it's them and not you that gets the blame for failing to meet deadlines. A sure way to annoy devs is to propose designs without checking with them. Of course, you can get the opposite situation of devs who don't want to do anything, or just want to take the easier way out. But if you dig deeper into the issue I am sure you'll find the right way to resolve it.

Or is this because of my lack of seniority and experience as a UX designer that cause the devs just to say no to the design?

I think any developer worth their weight will listen to reason/logic rather than emotions. If they can't tell the difference between a valid and invalid argument simply because of seniority, then you'll have more than just those problems with them. We know that as designers ourselves that we need to show more humility, not just to the users but ourselves as well because that's what allows us to learn and grow.

Is there anything that I could have done better in this type of situation? (Should I have asserted more on my design with more reasoning?)

Only fight the battles that are worth committing your troops to, so that you stay on track with the overall objective and can win the war. In the context of the entire project, the earlier decisions will have more weight as the project progresses. So you do have to pick your fights and the timing, but it is hard to say since we are not in the same situation, and we might have different ways of dealing with this.