There’s this feeling among some designers. That developers stand between them and greatness. That developers are a burden they must overcome to create great design. I think this is a cop out. Designers should approach technical restrictions the same way we approach user restrictions. We need to design for them instead of fighting against them (or worse yet ignoring them all together)

Holly Wall
Seyma Turan

At IceMobile, we get feedback on our designs from everyone on the team (and our developers are opinionated as hell, so trust me, we don’t do it because it’s fun).

I once interviewed with a design agency I admired — their work was elegant and simple, and their list of clients was impressive. I’d done my prep, curated my portfolio and, half an hour in, was feeling pretty good about it. Then we got to discussing working with developers — and in that moment I knew I wouldn’t be a good fit. When it came to developers and collaboration, it was the designer’s way or the highway. It seemed that in their minds, collaborating with developers meant compromising on their designs.

There’s this feeling among some designers. That developers stand between them and greatness. That developers are a burden they must overcome to create great design.

I think this is a cop out.

Designers should approach technical restrictions the same way we approach user restrictions. We need to design for them instead of fighting against them (or worse yet ignoring them all together).

Don’t get me wrong, I’m not saying developer input is absolutely necessary for great design. Plenty of designers manage to produce good work without ever considering technical implications. But a lot of those sleek designs showcased on sites like Dribbble, for all their merits, ignore crucial limitations that, when implemented, would sink a project in complexity, budget and resources. Not everything is feasible, and a good designer must balance desirability, feasibility and viability.

A little while after I met with that talented but dev-adverse design agency, I found my place with a company that shares my opinion on the benefit of dev input. Where I am now, a Dutch company in Amsterdam called IceMobile, designers and developers are encouraged to work closely together and are (dare I say it?)… friends. To be clear, we don’t always see eye to eye. In fact, more often than not it’s the exact opposite. But it’s through conflict, tension and discussion that we uncover the best design solutions for our projects.

Now, I know what some of you are thinking.

Those other guys were right, how can you possibly make innovative designs if you’re listening to developers?

To be honest with you, I’m not trying to make innovative designs. Innovation is an overused term in this business. People believe that good design must be something new.

But newness, usability and business value are not necessarily correlated.

Great design isn’t about innovation for innovation’s sake. To me, great design is about being creative in a restricted space. It’s about taking what you’ve got to work with and making the best possible solution.

Developers may give us constraints, but instead of using them as an excuse to make subpar designs, embrace them. Take them as a challenge to be more creative in the space that you’re given.

Okay, but aside from getting technical knowledge from devs, why should we collaborate with them? They don’t care about UX.

I’ve never met a developer who woke up every day and thought, “Boy, I can’t wait to get to work and build something that really sucks to use.” Developers want to make good products just as much as we do. When I hear people say that devs don’t care about UX, I think what they mean to say is that they don’t care as much about UX. To which I say, “Of course they don’t, it’s not their job. It’s yours.”

This isn’t a good reason to exclude devs from the conversation. At IceMobile, we get feedback on our designs from everyone on the team (and our developers are opinionated as hell, so trust me, we don’t do it because it’s fun). Good ideas can come from anywhere, and developers will have vastly different points of view than designers. We don’t agree with all of it, but it broadens our thinking and we respect the value their opinions bring to the final product.

Maybe so, but developers will say a design can’t be implemented just because it’s difficult and they don’t want to do it.

This is a big one. If you’re working for a company that you feel hires people who are apathetic about their jobs and don’t want to be challenged, then you’re dealing with a systemic problem that’s bigger than any individual developer. If this is the case, then you need to GTFO. For real. You need to jump ship, like yesterday.

For everyone else, as designers, it’s our job to guard our designs and make sure they come to life. Sometimes this means being strict about the end product and fighting to get that button moved those extra few pixels to the right, because yes, that does make a difference, and no, it’s not cool to just leave it that way.

Collaborating with developers isn’t just about asking what can and cannot be developed. It’s about sharing knowledge and understanding the technical implications of our designs. In some cases, it pays off to fight for something that’s technically challenging, because the extra development effort is worth it for the overall user experience. But in other cases, something that’s difficult to implement may not add much, and resources are better used elsewhere. The more we understand technically, the more informed our decisions can be.

Okay, you convinced me, but as a designer how should I approach working with developers?

For anyone who’s still with me on this, here’s where it gets tough. Like I said before, in a lot of ways it’s easier to ignore developers when you’re designing. If you want to start working more closely with developers, you’ll have to get out of your comfort zone.

Integrate design and development 

At IceMobile, all the project teams work in Scrum. Each team consists of developers, testers and designers. Designers do a lot of up-front research, exploration and concepting, but we make a point to keep as much of the detailed design work inside the sprint as we can.

Working side-by-side with developers makes it easier to share knowledge. Designers see what it takes to bring our designs to life and we get a better understanding of the technical limitations of the platform. Conversely, developers see more of the design process and get a better understanding of the rationale behind our designs. When developers are exposed to more of the design process, they understand where and how they can contribute and can weigh-in on technical feasibility early on.

Designing this way presents its challenges, but integrating design and development means both groups are working together toward a common goal. When there are no barriers between the disciplines, collaboration comes naturally and easily.

Break down the barriers between disciplines 

Integrating disciplines isn’t possible in all cases. We have a client for whom we design a website, but all the dev work is done by a third party who works waterfall. At first, this was a struggle. We weren’t used to designing in a black box and throwing our final designs over the fence, to be picked up by faceless developers. After a rocky start, we quickly realised something had to change. We asked for weekly Skype check-ins with the UK-based developers so we could validate our ideas before getting too far with design. Things quickly improved and all parties, especially the client, were relieved.

Whatever your work flow, identify the barriers between you and the devs and get rid of as many of them as possible. Don’t hand over designs without the opportunity for discussion, or rely on someone who isn’t a designer to explain your work to the people that will implement it. Devs will have the most questions the first time they get a look at the designs. Being there in person means you can clear up any ambiguities right away and get valuable feedback going forward.

Document for others, not yourself 

This one may seem like a no brainer, but far too often designers create documentation that suits them, and this doesn’t always correlate with what the developers actually need.

In the project with the waterfall third-party we started out creating specs the way we did for our internal developers. This kind of documentation worked when we were right next to each other, but the third-party developers were missing a lot of information. We asked them how they worked and what they needed to get the job done, and then changed our process to fit their needs. We switched to using Axure which allowed us to more easily share and annotate our designs. The benefits for the project outweighed the personal sacrifices we had to make to learn and design in a new environment.

Ask developers for their feedback 

Feedback is highly valued at IceMobile. Regardless of position or seniority, everyone’s welcome — scratch that — everyone is expected to share their ideas and opinions. This works the other way around too. No one’s ideas are accepted without question. Even the most senior team members are challenged. (This, I believe, is largely due to the fact that the company is Dutch, who are egalitarian to the extreme and famously known for their directness. More on that in another post.)

Defending designs helps to think them through and uncovers any tiny cracks (or giant gaping potholes) as early as possible. If we’re swimming safely in the shallow end of a problem, developers are there to pull us down into rougher waters. It’s our job to fight our way back out. This process can be gruelling, but we don’t shy away from it. If we can’t make it back to the surface, then we may have been going down the wrong path to begin with.

Don’t design by committee 

For designers, processing feedback can be tough. To do so effectively, we have to be open to the idea that we could be wrong. If we’re not open to this possibility, feedback is wasted on deaf ears. On the flip side, we have to know when to ignore feedback. Everyone’s ideas are valid, but that doesn’t mean everyone is right.

In the end, our commitment is to the users, not the developers. The goal of collaboration is not to make developers happy or to come to some harmonious state of oneness. In fact, this process depends on designers and developers having distinctly different (and conflicting) points of view. A good designer has the ability to question their own designs, but also has an unwavering sense of duty to their users and enough confidence in their expertise to know when to fight for the best solution.


- Improve communication and broaden your technical understanding by removing the barriers that are between you and developers.

- Be transparent about your design process and involve developers

- Get developer input before you start designing

- Find out what developers need from you and create documentation that works for them

- Don’t design by committee