UIrrational

Involving Developers In The Design Process (9 Tips)

Note: This post is a follow-up to 3 Reason To Involve Developers In The Design Process.

1. Invite developers to take part in ideation sessions.

When working on a new feature or product it is pretty standard to run ideation sessions where a group of designers and product managers rapidly sketch and explore ideas. By inviting developers on your team to join in these sessions you get the benefit of hearing great ideas from people with a different perspective. Developers appreciate being invited to these sessions as they often have ideas about the product and these sessions give them an opportunity to express those ideas and have a hand in shaping the product.

2.Keep the ideation sessions short, efficient, & fun.

You should be running short, efficient, fun sessions anyway, but it is especially important when involving people who are taking time out of their normal job to participate. Send out an email before to explain the context and design goals, use the first couple minutes of the session to review and clarify the goals, and then get right in to the sketching. If the session feels boring or like a poor use of time, there is a good chance that your development team will skip the next one.

3. Run 10-minute design reviews with your scrum team.

The review should cover a design you plan on building in the next couple sprints. Quickly walk the developers through the design and send them a link to the design afterwards. These reviews are short enough that they can be tacked on the end of standup, when the team is already together. This review should be separate from design reviews with PMs and designers as those usually take much longer and can often spiral in to other product design discussions.

The benefit of these reviews is that you get more eyes on your design and some guidance around how hard things are to build. Developers appreciate these sessions as it gives them a forum to voice design concerns and because it gives them a preview of what they are going to be building in the next couple sprints.

4. When you invite developers, make them optional.

Being involved in the design process should feel like a fun opportunity, not more meeting overhead. For both the ideation sessions and the design reviews make all of the developers optional. It will quickly become obvious which developers love getting involved in the design process and which have no interest.

5. Design-loving developers make great informal design collaborators.

The developers on your team that love being involved in the design process can be great partners to bounce ideas off, work through problems with, and get quick, informal feedback from. A great side effect of this collaboration is that by being more involved in the design process these developers will become more bought in to the design and will put in the extra hours to make sure the design gets built.

6. Only involve developers in products they will build soon.

It is less important to involve developers when the design is more forward looking, like a design vision or a sales prototype. The main purpose of these artifacts is to communicate and align people around a high-level approach. If the forward-looking design is well received you will end up going through the design process with more rigor, using the design vision as a rough requirements document. This second time through the design process you determine what will actually get built and this is a more useful time to involve developers.

7. When the design is well received, spread around the love.

When you receive praise at at a meeting for a design, mention that most of the great ideas and direction came from others and call out individuals when you can. This acknowledgment and positive feedback builds good will on the team and increases the likelihood that developers will participate in the design process.

8. If shit goes wrong, take responsibility.

Occasionally a design will fail to hit certain goals and it will be subject to internal criticism. No matter who originally came up with the idea that is getting dumped on, you should take responsibility for the failure. You harvest ideas and feedback from others, but at the end of the day it’s your job to sift through the ideas and feedback to deliver a great design. Blaming the failure on anyone else is a sure way to lose goodwill and ruin any chance of developer involvement in the future.

9. Be appreciative.

People are taking time out of their busy lives to help you design a better product. Thank them.