Finding the middle for designers and developers

May 22, 2013 Nina Mehta

Oh the age-old ‘should designers code?’ debate again. Nope! I pushed the matter further last night at Pivotal’s Extreme Roundtable meetup in LA. I asked, ‘how involved should designers get into code?’ and ‘Should developers design?’ In a room of 7 developers, the latter surprisingly got the most votes.

It all comes down to finding the middle and meeting there. It’s challenging for developers when a designer is thinking too high level in abstractions or too low at implementation details. Having conversations at the wireframe level, the middle, lets both parties have fluid discussions about product and implementation. It also gives the opportunity to try something out before going too far down a path that has a dead end.

When designers get too far in the ahead, the product owner gets too committed and excited about an idea that’s still just an idea. If they devs aren’t involved early in the process, product owners are sometimes “so juiced” on the idea that they’re disappointed or frustrated when implementation is expensive or ends up not being a good direction. It’s important for the three teams: design, development and product to be exploring ideas and communicating throughout the process.

However, designers who know a lot about code and implementation can be a dangerous constraint. It’s important for designers to understand how code works, but not be a barrier in ideation and generation phases. Let us not forget blue-sky design. One developer said, “sometimes they come up with really expensive ideas that are hard to implement, but it’s worth it because the design and user experience ends up being excellent!”

It’s a toss-up about whether or not developers should design or make product decisions. In some regards, they leave that up to the designers, which can be frustrating if the designer is blocking and not able to make quick decisions during development time.

Developers do have a lot of experience with implementation and should speak up what they’ve built before. It is ok for them to talk about where a design path may lead, because it doesn’t always lead to fairy tale ending. Devs should feel comfortable telling designers, “I know your expectations for this layout [or interaction]. It doesn’t play out how you think it it will. It doesn’t usually go the way you want.” They should of course propose some alternatives or explain which part doesn’t work. It can be frustrating for a designer to hear that, but that’s why it’s so important to start conversations at the wireframe level.

The developers last night said they like the idea of designers coding–if their code is good enough. It’s more important designers understand how code works to inform discussions and decisions.

What do you think?

About the Author

Biography

More Content by Nina Mehta
Previous
Socialvane Gears Up To Organize Social Media with RabbitMQ and Celery
Socialvane Gears Up To Organize Social Media with RabbitMQ and Celery

A new social media startup called SocialVane shares with us how they built their app out with scalability a...

Next
Data Science and the Value of Design
Data Science and the Value of Design

Data visualization is far more than simply translating information into charts. Effective visualization rev...

Enter curious. Exit smarter.

Learn More