Jason Cranford Teague outlines some designer-developer issues, and how to avoid them.
We know that developers can get frustrated with designers, especially when the designer designs something that's impossible to build. But there's plenty for designers to become frustrated about with developers.
Design is often seen as a 'soft skill' that is about an opinion of aesthetics, not hard rules, much less the rigorous logic of code. Yet designers work for years perfecting a craft, not just spouting uninformed ideas. However, being able to explain and articulate the 'method behind the design madness' is not always easy, and rarely quick, which leads to numerous project frustrations. Fortunately, there is usually a way to defuse the tension.
01. I designed it that way for a reason
Image source: Cat Donmit on Flickr
The Problem: The designer spends weeks creating meticulously crafted visual comps and spec documents, only to have them seemingly ignored by the developer. Beyond ignoring the specifications, some developers simply allow the browser defaults to stand without change if they are not explicitly stipulated in documentation, not just shown in visual comps.
The designer assumes that the developer will look closely at the comps and try to make them match 'pixel-perfect'. However, this generally leads to interfaces that feel cramped or poorly organized, despite the best efforts of the designers.
The Solution: Designers should assume nothing, and know that documentation is never enough. A good design guide is the first step toward eliminating this problem, but designers also need to work side-by-side with the developers, regularly reviewing their work to ensure it's what is intended in a design acceptance review when the developer feels comfortable with what they have done.
02. MVP!?!? It's all MVP!
Image source: Jugbo on Flickr
The Problem: The developer has a finite amount of time to create the end product, even less for each sprint, so they will prioritize features and functionality based on the 'minimum viable product' that will meet the product specifications. Most designers, though, view the product as an integrated whole, not a series of interlocking components. But the MVP is often not defined until the development phase, so it can feel more like developers are making the decisions based on their schedule needs rather than user and product needs.
The Solution: The MVP needs to be defined during the initial phases of the product, and truly be the minimum viable product, not just the easiest to make, for different development phases/sprints. Designers can work to create a product that is built-up in stages, rather than completed all at once. This should also make it easier for developers to plan accordingly.
Get top Black Friday deals sent straight to your inbox: Sign up now!
We curate the best offers on creative kit and give our expert recommendations to save you time this Black Friday. Upgrade your setup for less with Creative Bloq.
03. This will take how long?!?!?
Image source: Jon Hathaway on Flickr
The Problem: The designer has spent months planning, researching, and creating designs to meet the user needs, only to be told that it will take much longer than expected due to conflicting project schedules, staff shortages, and the dreaded scope creep.
The Solution: One of the facts of any UI development project is that development comes last, and is generally squeezed in time by the steps before (I have never known the discover, define, or design phases to go faster than planned to give development more time).
One way around this is through Agile coupled with Lean UX to allow development in parallel with design, allowing the developers to get started before the design is completely locked down. This approach is not without risks (design may need to be reconsidered) but generally leads to faster output and happier project managers. And really, isn't that what we all want?
04. What do you mean "I can't do that!"?
Image source: Peter Kaminski on Flickr
The Problem: The designer has created a really cool experience, but the developer takes one look at it and proclaims, "That'll never work." One reason developers might not be able to do something is because it cannot be done, but more often than not it's one of two other reasons: 1) it would take too long, longer than the project has, or 2) the developer just doesn't know how to it.
The Solution: If it can't be done, it can't be done, and the designer needs to rethink the solution. If it will just take too long, then the team needs to decide whether to scale back or take the time needed. But, if the developer just doesn't know how to make it work, the designer will need to show them examples of places where the desired technique is working. I find that CodePen.io is my best go to place when I need to show 'existing art' to my developers.
05. Usability testing is NOT optional
Image source: Dopey on Flickr
The Problem: For many developers 'usability' means that it works as defined by the requirements. If designers want to test anything, they should do that before the developer spends long hours building the UI to specs. However, only so much usability testing can be performed with paper and clickable prototypes. Often, the most effective usability testing is done during development.
The Solution: Plan usability testing spikes into any Agile project with iterations that feedback into the development of the product.
06. They are telling me how to design again!
Image source: Amy McTigue on Flickr
The Problem: A developer reads one article on usability by Jakob Nielsen, and suddenly they are a usability and design expert. Designers spend years developing their abilities, knowledge, and aptitude. One problem is that, because everybody has an 'opinion' about design (informed or not) in some projects – especially where there may be a UX team of one – their voice is often drowned out.
The Solution: This is not an easy problem to solve, as it has more to do with interpersonal and group dynamics than it does with actual logic and reason. The best way I have found to deal with these situations is to simply listen without getting defensive. Let them have their say and consider what they say.
Does what they have to say have merit? Let them know, and then explain why you chose to go the path you did, acknowledging even that you are disagreeing with existing 'best practices' as prescribed elsewhere. Often developers want to just feel as if the designer is simply listening to them.
Anything else?
I've outlined the six frustrations that I commonly see designers having with developers, and previously detailed the six frustrations developers have with designers. What's your take on this, and can you add to the list? Please suggest solutions in the comments below for us all to benefit from your experience.
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.
