Top 6 frustrations developers have with designers

Avoid the contents of this list, and designers and developers will get on just fine.

Unless you are designing just for the joy of it – or you are one of the fabled 'unicorns' who can do EVERYTHING – at some point you will encounter (and probably lock horns with) someone tasked with taking your pretty little pictures and turning them into a real world product. Like cats and dogs, these relationships are historically known for being… strained.

Of course not all designer/developer relationships are contentious or based on mutual distrust. In fact, increasingly designers and developers are working closer together in agile environments, where the walls have to come down out of necessity.

Still, some of the ill will persists. In order to help alleviate that stress, I'm presenting the most common frustrations I find that developers have with designers and how you can work to avoid them.

01. Yes, let me spend the next 5 hours figuring out what color that button is

Image via Creative Commons license: Chris Metcalf

The Problem: The deliverable is Photoshop/Illustrator/Sketch file with 53,002 layers that the developer has to wade through to find what they are looking for.

The Solution: Simply stated, you need a style guide. Rather than relying on all of the values in a visual comp to be 'pixel perfect', record the important standard values (colors, margins, padding, borders, etc…) in one common reference. This greatly cuts down on the guessing and interpretation the developer has to perform and can drastically reduce their development time. You get bonus points if you do that using CSS and ultra-bonus points using SASS or LESS to capture variable values like color.

02. Did you even look at the content that was going into this thing?

Image via Creative Commons license: Erin Crouse

The Problem: The design is delivered using placeholder Lorem Ipsum text, but when the rubber hits the road, that isn't anything like what the actual content going into the product.

The Solution: Content is king! The designs need to fit the content, not the other way around. Developers, since they are at the front line of where the content hits the designs are the ones left holding the bag when you do not design with content in mind first. Designers, for their part need to make sure they have a full content inventory before finalizing designs.

03. Your job is just to make it pretty, not tell me how it works

Image via Creative Commons license: Thomas Claveirole

The Problem: The designer creates a carefully crafted interactive/temporal prototype that works the way they want it to, but it's all 'throwaway' code.

The Solution: Developers are used to getting a stack of static diagrams and then trying to figure out how to make them work. Moving towards interactive prototyping often intrudes on what they think is their territory. Design isn't just what it looks like anymore, it's also how it works.

However, the landscape for how to communicate this is shifting, and not all developers have learned how to effectively communicate. So, the designers job is to talk to them. Let them know that you are not trying to take away their jobs, just trying to find better ways to make it clear what your ideas are. And if the developer uses the old 'throw away code' argument, just ask them, 'what you think you do with the static diagrams?'

04. We'll do usability testing when it goes live

Image via Creative Commons license: Andy Bardill

The Problem: In the agile world, user testing is something of a luxury, one that for developers may seem like an unnecessary distraction from getting the Job done. But designers know that user testing is only effective if it informs decisions before launch.

The Solution: While planning sprints, designers need to build in user testing spikes that will allow them to test and iterate back into the development phase. As long as developers plan for these refinements, they are usually accepting of their necessity.

05. I can't do that

Image via Creative Commons license: Peter Kaminski

The Problem: The designs been signed-off on by the powers that be, but the developer does not see them until they are told to 'make it so.' The only problem is that the designer was thinking about what they wanted to do, not what was possible.

The Solution: First, designers need to be grounded in the capabilities of the platform they are designing for. Whether that's web, iOS, Android or something else, know your medium. Second, you can never bring the developer in early enough in the design phase. At the minimum, include developers in review sessions so that you can head off potential issues before they grow out of hand.

06. You want it when?

Image via Creative Commons license: Jon Hathaway

The Problem: Since it comes at the end of product creation, the development phase often gets short changed if the other phases go longer especially if there is a delivery deadline. If you are still working in a waterfall or even 'hybrid-agile' process, this problem is compounded.

The Solution: If you can't be agile with lean-UX, at the very least include developers at every stage and let them start work on what they can even if you haven't finished the entire design.

I used to be very stubborn about releasing designs before I finished the final screens, because I was worried that I would need to change something on earlier screens due to decisions made down stream. This caused developers no end of heartache, and I quickly learned that if I prepped them in advance for iteration, I could get my changes made and still feed them work as I completed sections.

Words: Jason Cranford Teague

Jason Cranford Teague is a Senior Creative Director at Capital One and teaches workshops on experience design for developers, development for designs, and temporal design thinking.

Like this? Read these...