Over the past few years, I’ve had the chance to talk with multiple designers about their work and what their environment is like. And perhaps I was naive, but I was surprised at the number of times I heard that they were told by developers that X feature they wanted to do was “not possible.” Then when I would ask more about the requirements of X feature, I would often be boggled by how simple the request often was. So that got me thinking, “Why are developers often so quick to say no to what designers want?”
To get a few of the obvious counter arguments out of the way, I’m going to be speaking purely from a front-end perspective since that’s my area of expertise; but I do think the sentiments in this post still apply to the rest of the field. In addition, I’m well aware of the fact that a number of things could be playing into a developer (or his team) being able to build X feature. Many reasonable explanations include:
That said, the statement I draw particular issue with is when developers say:
No we can’t do that.
Now, short of some outlandish feature request, I honestly find that statement to be absolutely absurd. When I hear that statement, all I hear is the unwillingness to devise a solution to bring a feature to reality. Sad as this is for me to admit, but I’ve run into and heard of enough situations where I’ve seen developers give what only can be called pathetic attempts to help designers and/or stakeholders accomplish what they want. They often just stick with conventional solutions that are common and conventional. If the feature is outside of that bubble, good luck. This often works well for them because:
And this is wrong on so many levels because what developers don’t realize is that there are so many negative byproducts of this kind of behavior:
Surprisingly, the solution is actually quite simple. No it’s not to kill yourself trying to build every feature imaginable. Instead, we simply make a few modifications to the original statement to become:
Yes, that’s possible; but these are the trade-offs we must consider…
In other words, while you may have the technical expertise in the difficulty level of implementing something, you do not hold a comprehensive understanding of the business plan or strategy for the product. So instead of acting like some endgame boss for projects, have a discussion with your team so that you all can make a collective decision that is best for the product and company. After all, maybe they don’t mind that doing that one feature will take an extra month as long as they get what they want. If you try to cut them off at the knees though, they never get that option and the working relationship is hurt that much more as a result.
Remember that as developers we have a critical role in building things in order to make projects a reality. So instead of acting as a barrier, let’s wield that power responsibly and use it to enable peoples’ visions responsibly.