Getting the most from developers

My developer friend, David Hezlep, recently shared this link: Advice from Developers for Working with Developers.  It’s full of great stuff, and it got me thinking about the nonstop tug of war between those planning and those building user experiences.  Why can’t we all just get along?

Earlier this year, I talked to an information architect who was desperate for advice. At her office, tensions between developers and the UX team had come to a head. The developers were fed up with unexpected complexity (which they viewed as scope creep), while the UX team was frustrated that the final outcomes never seemed match their intentions.  In their efforts to improve the processes, both teams had replaced conversation with documentation.  And the chasm between the teams was growing wider every day – a chasm that exists in many web teams.

No matter the company, developers are often some of the smartest (and most important) people in the organization. Over time, I’ve tweaked my way of working with them to get the most from their participation in the project life cycle.  Here are some basic tips I try to follow to make these technical minds more active participants in the creative process.

• Include developers from the beginning. Asking the right questions upfront saves time in the long run, because we are all working within known technical parameters.  And it’s not just about parameters – as key reviewers through the IA and creative design portions of the build, developers can also help inspire the team with creative ways to apply the latest technologies.   Without that communication from beginning to end, you miss out.
• Get at least 2 developers review the work. The uncertainty in early phases makes it harder to gauge a project’s complexity, and nobody likes to make commitments on their team’s behalf, especially when those commitments are based on guesswork.  When a developer has a colleague off of whom to bounce questions and concerns, early feasibility assessments go more smoothly. When possible, I try to get the people who’ll actually do the development to advise early on; it’s a lot easier to speak on your own behalf rather than that of a teammate.
• Insist on meeting in person. Although we all joke that developers relish in flow charts, the truth is that web planning documentation is not easy for anyone to comprehend.  Talking through plans as a team always uncovers far more than a quick glance at one’s desk does, so I insist on getting everyone together (in a room or on the phone) to talk through the work.
• Heed all red flags. Many of us have learned (the hard way) to take note of every concern raised by technical advisors on a project.  Failure to do so can (and has) ended up causing trouble for projects later down the road.
  • Document red flags as assumptions. You often can’t let red flags stop you in your tracks while you wait for more information, so make your best guess, and continue working against that assumption.  Keep a record of the assumptions you’ve made, and include it when presenting plans to let stakeholders know that changes to the assumptions will mean changes to the plans.
  • Investigate them as soon as possible. If an assumption is untrue, the plans may break!  So begin work immediately to get confirmation on assumptions, which leads to the next point.
  • Get technical resources aligned on the other side(s) of the project. When you’re working with client teams and third-party technologies, business clients can rarely confirm (much less, understand) technical assumptions.  Make sure that your partner teams arrange a technical contact (a developer or programmer familiar with the functionality in question), so that your developer’s questions and comments can be answered early on — giving you time to change direction, if you need to.
  • Create multiple release teams, if needed. Plan ahead!  Major launches and releases sometimes suck up all available resources, but it’s important to have your complete project team assembled early.  If you know things will be busy, plan in advance to have enough manpower that you can protect a few developers from the hubbub, so that they can consult with a clear mind on other things that need attention.

It’s an on-going struggle, but the first step to improved relations is getting agreement on the right way to do things.  What advice do you have for getting the most from developers?

See also

1. Attach… a Link?
2. Why I Won’t Call You “a Creative”
3. User Testing Fallacies