Collaborating with developers

From Design to Code: Collaborating with Developers

Ever since I joined GVio as a UI/UX designer a little over two years ago, I’ve had the opportunity to collaborate directly with developers (both in-house and remote teams). During this time, I’ve witnessed how designers and developers bring different skills to the table, different way of approaching problems, and so on, which has made this a very enriching experience. I thought it would be helpful to share what I’ve learned over this period of time.

In general, I believe that we, as designers, should work towards fostering a strong sense of partnership with developers. Here are a couple of things we can do to strengthen this collaboration and bridge any gaps.



I know, how cliche, but it is the core of this interaction. There will be situations during which developers may know something you don’t or that you know something they ignore, therefore, communication will ensure both of you are on the same page. Based on my experience, nothing beats in-person communication but sometimes it may not be an option. Phone calls & GoToMeetings can do the trick depending on what we are trying to accomplish. Something that has worked very well is having a Skype chat group with the developers. It acts as an open channel of communication to bounce ideas off and clarify any quick questions that arise. As this relationship builds, both parties feel more comfortable and empowered to voice their needs and concerns.


Reality check

After a couple of ideation cycles, we tend to run our designs by the developers to gauge their level of comfort and make sure the concepts are technically feasible. Depending on the team dynamic and process, we may cycle the designs by them before showing something to the client. The benefits of this are:

  • Minimizing the gap between the design and what is actually built
  • Developers feeling empowered by having a voice
  • Designers managing more effective design cycles
  • Developers are not taken by surprise when they have to start implementing the designs
  • Designers and developers working together to find the sweet spot


Documentation & resources

Always make sure the developers have what they need. Some redundancy and over-communication won’t hurt when it comes to documenting the desired user experience. Use cases, workflows, specs, annotated mockups, and style guides are some artifacts that developers we’ve worked with have used to implement our designs. Unfortunately, time is also a factor and in some cases we’ve had to find the right balance on what needs to be documented and how. The best you can do is ask the developers what they need to get started and take it from there. Another time-saving option is to walk developers through so they have a better understanding of the concepts and any questions can be addressed right away.



As developers start building the product, we review updates and provide feedback to ensure that it is working and looking the way it is supposed to. Most of the time we (designers) will have a sharper eye and be more critical about it. You can have the developers walk you through what they have so far or maybe you can get access to a demo of the latest build. Capture what needs to be improved and share it with the dev team. It is also important to keep note of the root cause when things are not implemented as intended since you may want to revisit your documentation and communication channels.



There are a couple of other things that may not be critical but can be helpful when it comes to supporting this collaboration:


Some technical knowledge or understanding of the technologies that the developers work with can help you make better informed and more realistic design decisions. Ask them about libraries they feel comfortable using and it can give you some sense of what should be doable.


Sometimes the wireframes and high-fidelity mockups are not enough when trying to convey how things are intended to respond, flow, or be animated. When we face this challenge or when we would like to review the holistic experience, we often produce clickable prototypes or some sort of interactive artifacts. Developers have expressed that it is easier for them to work on something when we provide a prototype they can reference.


It’s not always about reinventing the wheel. To balance things out, I think is good practice to look for some things that developers can reuse across the product or from previous products to ease the implementation. Adapting some off-the-shelf libraries can help with this.


There may be a couple of tools out there that can make things less bumpy and more clear for the team. As I mentioned before, we create clickable prototypes using InVision to get some interactions across. There are other solutions like Zeplin, which makes the design hand-off easier by generating style guides and resources automatically. provides an interactive visualization of the top prototyping tools on the market. This is helpful because you can sort by use case, speed and affordability. I’ve yet to try it so I’ll probably talk about my experience on a future post.


Final thoughts

It’s been a little over two years and I’m still learning new things on how to collaborate more effectively with developers. Every project and team is different. Technologies and tools are constantly emerging (and changing!). In this partnership effort with developers, communication will always be our constant.

How are you fostering this partnership? What tools do you use?