3 Reasons To Involve Developers In The Design Process

The goal of an interaction designer is to get the best possible product in the hands of users. Everything we do, from research to critique to documentation, is in an effort to reach this goal and involving developers in the design process is paramount to delivering a great product. Here is why:

1. Developers have great ideas.

It’s foolish, and a bit condescending, to think that someone won’t have great product design ideas just because they don’t the word ‘product’ or ‘design’ in their job title. Developers spend countless hours building and using tech products (often in the domain you are working in) and they bring tons of great ideas and feedback to the table.

2. Understand development tradeoffs earlier.

As the design goes through reviews and iterations it’s great to have developers involved to both critique the design and to keep you informed about features or UI elements that would require large amounts of development time (as well as ones that come cheaply). Since most projects have limited development resources, understanding development costs early allows you to steer the design in a direction that gets the most value for your development buck.

3. More developer commitment to build out the full design.

If a development team believes in a design and feels ownership of it they are much more likely to the make the full design a reality, even if that means long days and extra hours. We have all worked on projects where the development team simply ran out of time and had to cut scope, leaving some delighters or fun details out of the feature. I have found that this happens less frequently when a development team is truly bought-in to a design.

There are a number of reasons why involving the developers in the design process is a great way to get this very important design buy-in from them. Here are a couple:

  • No one likes being told what to do and by involving the developers in the design process it makes it feel more like a team effort and less like a designer telling them what to build.
  • People are more likely to support a design they worked on (see Ikea Effect), and when you involve developers in the design process the final output is truly a result of their ideas and feedback. It’s important to share the credit, so when I present a design to executives I always highlight the design contributions of the development team.
  • No one wants to build something they think is shitty. Having the developers in design reviews allows them to voice their concerns which allows you to either adjust the design accordingly or to explain the rationale for the current approach.
  • People are more likely get excited about a design that solves an important problem, and involving developers in the early design explorations, where context and goals are presented, gives them a better sense of what we are solving and why.
  • People are more likely to support a design that has had a lot of hard work put in to it. Your end deliverable looks similar whether you spent 10 or 100 hours on it but when involved in the design process, developers get to see the various steps and the amount of work put in to a design.

Convinced that it’s a good idea to involve developers in the design process?

Yes? Awesome. The next big question is how to involve developers in the design process. If done incorrectly, you will waste everyone’s time and create a product that feels like it was designed by committee. In my next post I will cover best practices for involving developers in the design process.

Like what you read? Give David Royer a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.