7 things developers should do more when working with designers

I had previously written an article titled “7 things I wished designers did more of when working with developers.” It may be tough for both sides to hear the tips, but it wouldn’t be fair for me to write a similar article for developers, right?

So here it is.

In order to create great products, collaboration between developers and designers is key. Although they may focus on different aspects of a product, they have more in common than most think. Both designers and developers are analytical and creatively solve problems.

I’ve been on both sides and wanted to take some time to put together a few ideas that hopefully some of you may find helpful. From a design perspective, I’ve conducted research, come up with ideas, and fleshed them out into concrete designs. From a development perspective, I’ve built designs as closely as possible to what the design team has worked on. And there were times when I have both come up with the concepts and implemented them.

I hope this background helps you understand that I don’t want to offend one side or another (why would I take so much time to do that?). I see the value in what everyone brings to the table when they work together and love seeing both sides collaborate efficiently and effectively.

1. Proactively give feedback and be upfront about constraints

Just as designers can offer valuable feedback, developers can too

Many developers I’ve worked with have a lot of experience and insights, especially when they have been working in the industry or on a specific product for a while. Many developers are involved in wireframing, prototyping, and visual design nowadays. So, they have a lot to offer designers in terms of feedback. Design is about co-creating and developers are as integral to this as anybody else.

I interact with designers regularly throughout the design process. If you haven’t already, get involved in meetings. Although you may not need to be involved in every conversation, check with your team or project manager to make sure you are involved in important conversations that define how the product functions. This gives you the chance to speak up before it’s too late. It’s important to manage the expectations of designers, clients, product managers, and the others involved.

Factor in time to provide feedback

Working on the current sprint while also providing feedback for designs in the next one is not easy. Because of urgent deliverables, you may end up prioritizing the first sprint instead. This often leads to problems later on. If your team doesn’t already do this, I’d recommend you (and/or your project manager) to factor in time to provide feedback on designs when planning.

I wish I had done more of this in some of my projects because providing feedback can turn into a part-time job when you’re working on a complex product. Whether it’s you or someone who will check back with the team, it’s important that there is representation from the development team when it comes to defining a product.

Why your feedback on a regular basis matters

Reviewing and providing feedback on designs you will be building is just as important as building the actual designs.

Why? Think about it from the perspective of a designer who’s spent a lot of time deciding how something should look or function, a client who’s signed off on a design months ago, a project or product manager who has to manage expectations from different parties, or a senior manager who has communicated information about the deliverables.

Below is a graph I use when I lead workshops on UX and why the design process matters. As you get further along in a project, the number of design alterations decreases but the cost to change your mind increases. When you first start a project, the number of design alternatives is high and the cost to change your mind is low.

2. Review notes, specs, and prototypes thoroughly

3. Ask questions if you’re unsure

4. Invite designers for informal reviews

5. Shed light on your workflow

6. Learn how users interact with what you’ve built

7. Understand where design changes are coming from

Conclusion