Improving Design to Dev Workflows: Collaboration

Posted on Oct 31, 2016 in Design

Hello design-jerks! Or reformed design-jerks. Or I suppose you could just be normal designers. On this, the third and final installment of how to be nice to your developer, I'm going to talk about something much bigger and less concrete than before, and it starts with listening.

Specifically, listen to what your developer has to say. Your next project is the perfect opportunity to begin building a working relationship with your developer. You can learn a lot by bringing them into UX discussions early and often, especially when features are on the table.

If you can't get developers into those discussions, pay attention during your dev handoff meetings. If they seem apprehensive about a feature you designed, ask them to explain why it worries them. Note their answer and remember it for the next time you run into a similar challenge. You may find that a simple change to how the feature works will vastly decrease the development effort without negatively affecting the user experience. Designer or developer, we can all agree this is much better than having the feature shipped half implemented or cut out completely because it was too complex to be finished in time. When both you and your developer feel comfortable asking questions and giving feedback, your team will make better products, guaranteed.

Our design process often uses limited-functionality prototypes. This means the designer can overlook problems that would be readily apparent to the developer. Conversely, during the implementation phase, it can be too easy for developers to unintentionally deviate from the designer's original intent. It's only when developers and designers collaborate at every stage that the final product becomes a coherent whole.

My main point is this: know what you don't know. Then work around your limitations by consulting with the people who do. If this way of working is not part of your team process, seek them out on your own. It's worth taking time out of your schedule. As this becomes a habit, you'll have an easier time understanding the dev point of view. Eventually you'll be a lot better realizing what implementation is worth the effort and what is a design conceit. Working this way is the key to designing better products on time and under budget. 

Haven't read my previous posts in this series? Get caught up by reading about asset sheets in part one and developer guides in part two.

Code.pendency - Nokogiri Improving Design to Dev Workflows: Dev Guides