In the web design industry, developers have gained an unfortunate stereotype of being grumpy, overly-pragmatic naysayers, especially towards their designer counterparts. If you’re a designer, you’ve probably had the experience of coming up with a brilliant interaction for a site, only to have your hopes and dreams dashed when you consult the nerds tasked with building your masterpiece. Even the simplest of requests – like vertically centering some copy – seem to aggravate these cynics.

So, why do developers always say no?

Chances are that they have very legitimate reasons, but often these reasons are quite technical and difficult to explain. That being said, it’s very important for designers (and also managers!) to understand on some level the reasons why their brilliant ideas are being vetoed. It’s my goal here to close this knowledge gap between professionals. I’ll be focusing on web developers specifically, but most of these principles apply to all realms of programming.

Dear Developers – Stop Hatin’

Before I defend my fellow developers, I first need to call them out. In situations where a new feature is asked to be built by a non-developer, it can be quite easy for tempers to rise, egos to inflate and nerves to be strained without proper management of expectations. When we operate from such a defensive place, our gut reaction is to just say no.

But quite often, developers don’t know whether something is possible or not. It’s important in these moments to slow down and think.

There are a number of reasons (which I will go into shortly) as to why something might not be worth exploring. However, as a developer, it is worth letting the inquirer know exactly what constraints you might face, as well as all unknowns. This provides them with the best information, sets realistic expectations and abates adversarial responses.

With that noted, let’s examine the top 5 reasons why web developers say no.

Browser Compatibility

You saw this one coming, didn’t you? Not all browsers are created equal, and it’s never possible to have websites always look and operate exactly the same across the board. However, using the practices of graceful degradation, we can make websites look passable on outdated, less awesome browsers, albeit not the same.

5 Hidden Gems in Chrome DevTools that Anyone Can Use

Sometimes developers will turn down something because it’s not possible to pull it off in older browsers that they’ve been asked to support, and the alternative solution would require quite a bit of work. It’s important to know what browsers the majority of your visitors will be using, as support for these older versions often increases the level of effort for a project. If your target audience is not technically savvy or at a disadvantage technology wise, you might not want to skip the IE 8 support.

Scalability

Developers only write code for two people: themselves today, and themselves six months from now. Sometimes while a feature proposed sounds like a great idea, the amount of effort needed to make it scalable can be extremely involved. Sure, they could pull if off with a simple hack right now, but what about months down the line when managers are asking them to expand on it? Will it be a good solution then too?

ducttape

JavaScript

Specifically talking about the front-end world, a lot of conflicts arise between designers and developers due to the amount of CSS and or JavaScript necessary to pull something off. These days, a lot of cool interactions are possible with CSS alone, which is almost always preferable, because it means less code. Because my aim with this blog post isn’t to deter designers from coming up with awesome ideas, here are some cool things that can be accomplished with CSS3 in modern browsers:

Boost Your UX Skills View Reading List

CSS, while definitely code, is not a programming language. It lacks the power of a more complex language, and thus is limited in what it can accomplish. When styles alone can’t get the job done, JavaScript swoops in to the rescue. Adding JavaScript to a website can complicate things and increase the time needed for a project.

So how are you the designer supposed to know when something is complicated or not? While you can’t be expected to understand the in’s and out’s of code enough to estimate the level of effort required, here are a few things to keep in mind:

How Difficult is my Interaction?

All interactions are triggered by certain events. On the web, there are four main events that can trigger any given interaction:

Hover

Anything that needs to be triggered on hover can be accomplished with CSS alone, and while the typical usage might be a simple color change, you can get really creative with this. Tool tips and dropdown menus are some of the more complex ways of using hover events, but you can get pretty inventive, such as in this accordion style slider. Pretty much any combination of the above techniques can be used to create beautiful, fun hover effects.

Click

With a couple of exceptions, you can’t rely on CSS alone to build an interaction triggered by a click. This would include clicking on a link or button to reveal new content (without the page refreshing), clicking through an image slider, triggering a modal or lightbox gallery, etc, would require some JavaScript.

Resize

To clarify, this event generally refers to when the browser window is resized. This event is most handy when creating responsive solutions. CSS has a built in tool called media queries which create rules for how things should look at certain window sizes. So if on smaller screen sizes you want things to shrink and look differently, CSS is a great and simple solution to that.

However, if the changes you’re looking for drastically change the arrangement of the HTML elements on the page, you’ll need JavaScript to do the dirty work.

Scroll

Do you want something to happen when a user reaches a certain part of the page? How about one of those cool, subtle Y-axis animations you always see on single page responsive sites? CSS has no ability to measure how far down on the page a user has scrolled. Only JavaScript is privy to this information.

Time & Budget Constraints

One of the least enjoyable parts of being a developer is estimating time. Tasks that seem like they ought to be done in an hour or so can turn into week-long endeavors. It should be noted that this is the norm for all programming, and it says nothing about the skill level of the developer. A developer will be inclined to say no on a feature request – no matter how small – because while it might seem like a minor tweak, it is actually quite difficult, or has enough unknowns around it that it has the potential to take a much longer time than it’s worth.

When deadlines are quickly approaching, everyone looks at the developer as to why everything is taking so long, forgetting all the baby requests that were added along the way. This kind of scope creep can be detrimental to a project’s progress, which is why developers will give quite a bit of pushback on certain things.

Best Practices & Technical Debt

Think about what happens to a car that you don’t maintain. If you just continually used duct tape to patch things together as they wore out, eventually it would breakdown or become too difficult to fix, and eventually you’d just scrap the whole thing and buy a new one. The same principle applies to web and application development. If best practices aren’t followed and corners are cut, you accrue technical debt. If that debt is not paid off, your site will become harder and harder to modify and to use. Eventually it will become such a mess of a knot that the best solution will be to axe it completely and start over.

Designers & Developers Can Still Be Friends

All of the above being said, the key to any good designer-developer relationship is communication. It’s not a designer’s job to know what’s accomplishable and what’s not, and a developer should assume as much. Staying in frequent communication with an open mind is crucial.

All of these issues come from the fact that the web world presents significantly more problems than the print world ever had to accommodate for, and we’re all still in the process of feeling out the limits. But if designers learn to be comfortable within the boundaries of the browser, and developers with saying yes to new challenges, we’re going to vastly transform the web together, for the better.

Comments
  • Oli

    Thanks for the good article. Since we do have responsive design it became even more difficult for print designers to produce ui design layouts. In my opinion this is a no go. The designer must have knowledge in front end development. UI design and front end development must come from the same person.

    • Annie Sexton

      You’re spot on with the responsive design. Using frameworks like Bootstrap can help designers some, but it won’t account for everything. I’ve found that UI design is best done with a conversation between the designers and developers about how things collapse and rearrange responsively.

    • Alex

      Totally agree. A UI designer who doesn’t at least understand code and how their work will translate is like a print designer saying they don’t understand how printers work.

  • Great article. I think another reason developers might say “no” is that sometimes the design or business requirements haven’t been thought through. Even though a designer may not implement the final design it’s important for them to do their homework on the technical side so that conversations with the developer will be more productive.

    • Annie Sexton

      Good point! I find this is especially true in the realm of interactions and also responsive design. It’s super easy to design something without fully fleshing out the utility of it, which is where a developer can help out.

  • First, nice article. I think this topic is one that needs to be explored more. Not just devs vs. designers but just interactions in the interactive web space in general.

    As a full-stack developer.. I feel that — and maybe i’m just from another planet. What is best for the project should be explored at all costs. I once told a designer I would NEVER say no — but it gave them no excuse to not swing for the fences.. we did some REALLY great work this way. It pushed me to be better each and everyday and keep trying and learning new things. It also allowed the designer to take more risks and continue to loop me in on everything so we were working together to make the best project possible and not just .. the same site again and again.

    I think a designer should have the respect for the developer to run new ideas by them BEFORE its pushed in front of a client/etc.. to give a dev a chance to prototype to make sure it can be done etc. That way EVERYONE wins and the dev isn’t forced down a bad path — and the designer can make sure that the execution is working with what they had in mind.

    I think this article is good but gives a bit too much ammo in the camp of saying NO vs. how can a developer grow/push to find a yes.

    If time/budget is a concern.. but you think you’re on to something that is even better than what was quoted.. i think the dev, designer, pm etc can rally to the client to try to add the new idea into the project or at least plan to get it in for a phase 2 etc. I think that it’s up to the entire team to do right by the project and try to make the best possible outcome for the end users etc.

    Idea i just had: Give a dev a ‘no card’ once per project… that way if there is something they really want to push back on.. say no.. but that would force them to try to find a solution vs. risk not being able to say no to anything else per project. I understand somethings may just be impossible in today’s current technology set.. but at least the concept of .. ‘i can only say no to one thing.. maybe i should atleast look into it to see if this is my one time no or if I COULD make this happen..”

    again.. i may just be a crazy person.. but thinking this way has got me to some really awesome projects and some really awesome relationships with designers/teams.

    Thanks again for starting the conversation with your article. You’re awesome.

    • Annie Sexton

      I like your approach, my co-developers and I do everything possible not to straight up say no, because that usually doesn’t help anyone, even when there’s a good reason behind it. What helps is stating the challenges that might ensue to the stakeholders, and giving them the power to decide. Its a solution that can be risky, and is not without it’s own set of challenges, but as long as expectations are properly set, I think it puts teams in a position to pull off REALLY cool stuff, and gives devs the chance to really stretch themselves.

  • Interesting read, I’ve dished out my fair share of no’s to designers but usually follow it with an alternative solution.

    My main reason for saying no is due to budget/time constraints rather than technical limitations which often results in there being a cheaper/quicker solution that nets the same results.

    • Annie Sexton

      Providing alternative solutions are a super great practice to get into, you’re totally right. I think not only does it help to project, it doesn’t stub out that creative flame for designers. I know a few designers that are afraid of asking a developer if something is accomplishable simply because they’ve received so many flat out no’s.

  • Martin

    Nice post. Dropping in here with a bit of developer perspective. First off, our team might be a special case because we don’t have designers doing visionary photoshops and front end devs doing all the implementation; instead we roughly divide the world to that high level designs, CSS, fonts, and bitmaps are the primary responsibility of the designers; HTML is more or less a common ground; and Javascript (business logic, communication, data binding, etc) lies with the designers. Being an agile team, the developers occasionally mess around with CSS or page designs to circumvent bottlenecks. Not sure that this is the holy grail of agile web development but we try to make it work.

    Anyway .. when I find myself saying nay to the visionary ideas put forth the designers I like to think that I do so from a UX perspective. Designers like to add nice colours, appealing images, snappy transformations, nicely aligned pages and the like, and that is all good. But occasionally they also try to reinvent the wheel and create new funky ways to achieve user interactions without thinking about whether the old, boring paradigms might work. I find myself gravitating towards somewhat bland but well-tested solutions to things like copy/paste, navigation, details views, etc. After all, we don’t want to confuse the user.

    To I guess what I’m saying is that designers want to invent new and groundbreaking stuff when they get the opportunity. Hey, Jon Ive gets away with that. But I’ll “nay” most of it, not because I’m a grumpy person, but because it’ll introduce friction for the user.

    Guess what, developers are just the same. We also want to create new stuff all the time and get patted on the shoulder for our inventiveness. Hey, Edison get away with it 😉

    • Annie Sexton

      Agreed. I find that the best ideas come from a healthy push and pull between designers and developers, when really inventive and envelope-pushing ideas are reigned in just enough to still be practical and usable. Really cool stuff has come from these kinds of exchanges in my experience, and they’re really fun to pull off. 🙂

  • Brian

    Very nice post.

  • Seriously, the world needs to know this! wow! Finally, I feel like I’m not crazy, lazy or incompetent, especially when talking with my boss about what can be done or not done 🙂 Thanks for this.

  • Great article. You folks write really cool stuff, this context also applies to our workplace. I have shared this with my team and hoping they understand each other’s perspective better now 😉

    • anniesexton

      Glad to hear you found it useful!

  • anniesexton

    Great article!

  • anniesexton

    Why developers always say no

  • dtpublishing

    Great article, Annie!

  • Pingback: Media Cause | 11 Resources for Launching a Nonprofit Website - Media Cause()