Speaking Their Language: Presenting IA to Developers
Ideas, even earth-shatteringly magnificent ones, that aren’t communicated effectively can suck the life right out of a project. For the next couple of weeks I am going to be discussing considerations for presenting your IA work to various audiences.
Here are four guidelines to keep in mind while you’re preparing to meet with or present IA directions to the developers involved in your next project:
In every situation, always respect the developers. I’ve unfortunately been witness to and even participated in hasty critique of developers’ work. The truth is that we don’t know the constraints they were under when they created a system, what obstacles they had to overcome, and the problems that have already been solved. Make assumptions with benevolence, draw out current weak points as springboards for discussion, and use the project goals to guide constructive conversations.
Developers usually have several complicated problems rolling around in their heads that they’re in the middle of solving (occasionally this creates the illusion that they’re not listening, but don’t be fooled – they are). Acknowledge their cognitive load and don’t take up more time than is reasonable. They will respect you for your brevity and be glad to get back to working on those solutions.
Get to the good stuff.
These pragmatic problem solvers benefit from getting right to the meat of the matter, so make sure you cut verbal fluff where you can. Be careful here: that doesn’t mean they aren’t interested in the project goals, site audience, or other “soft” topics. In fact, it’s these details that give their work context and purpose. It’s the delivery which matters, which should be sans pretense and filler words.
Engage with the details.
From the very beginning of a project, the developers should and will be thinking through implementation details. Stay a step ahead by preparing thoughts and questions related to the implications for both front and back end development. Every piece of a wireframe or prototype impacts their scope. Sometimes this can get frustrating if you’re excitedly sharing a big idea and they’re giving you five reasons the execution of this idea is not going to fly. Expect this back and forth and be thankful that the development team is putting all that thought into the project.
Of course, I am painting with broad strokes here and every developer is unique (I work with ten and am married to one, so I have some firsthand experience). These guides are just a good place to start as you get to learn about and relate to these individuals on your project team.