UIrrational

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. Almost everything we do, from research to documentation, is in an effort to reach this goal and I believe that 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 their title doesn’t have the word ‘design’ or ‘product’ in it. 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. Buy-in & belief means more 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 great delighters out of the product. I have found that this happens less frequently when a 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 helped shape, 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 highlight these contributions so when I present a design I always credit members of the team who contributed ideas that affected the design and those who gave feedback that lead the design in new directions.
• 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 (on the surface) whether you spent 5 or 50 hours on it but when involved in the design process, developers get to see the various steps and the amount of thought put in to a design.

Convinced that developers should be involved in the design process?

Yes? Awesome. The next big question is how to involve developers so that you get the most value out of them, they feel involved, and you don’t use up too much of their time (someone has to actually build the product). I will cover these topics in a follow up post, as well as related topics like which projects should involve developers (hint: not every project) and which developers on the team to involve.

Update: Here is the follow up post about how to involve developers in the design proces.