Since my first job out of college, I’ve worked directly with developers, whether I was managing their projects, slicing PSDs or working on the user experience.
I was hired at Dyn as a web developer and I’ve finally documented an arsenal of tips for working and communicating with devs that project managers, designers and other developers may find helpful!
1. Send finalized requirements
The requirements that your dev receives will be the ones that he uses to start working.
Changes to the requirements may be unavoidable in certain cases, but the norm should be delivering the finalized request!
2. Be specific, not general, with requests
Sending short, specific requests to your developer will either:
- allow her to start immediately on the request, or
- prompt her to ask you specific questions in return
An email that lists your specific goals (more on that below), a specific “to do” for her and a specific timeline has a much better chance of getting the request kicked off than a general overview of what you’re looking to do.
If you’re not sure what the project looks like yet, or if you’re looking for feedback, say just that and then schedule time to talk.
3. When looking for feedback, ask specific questions
- a link to wiki page with screenshots
- questions for each screenshot (both on the wiki page and replicated in the email)
- a deadline
My questions are often based on the user experience: “What would you expect this button to do?” or “Do you know how to get to this next step?”, but your questions could be anything that requires a short response. Providing a deadline will help your developer prioritize your email in his queue.
4. Outline your measures of success up front
Are you hoping to increase conversions? Decrease exit rates? Drive revenue? Share with your developer the high-level measures of success that you’ll be looking at after the project is launched. It’ll help her better understand the whole project and how her work is making an impact.
I like to include the goals within the documentation I’m developing and update them after the project is finished (I wait for 1-3 months of data, depending on the project).
Keeping this benchmarking and outlining of goals on wiki pages or other documentation will also help anyone else who wants to check out your project and better understand it.
5. Express your thanks
My coworkers know that if they send me thoughtful and insightful feedback on a project, they’re going to get some homemade baked goods in return. I sincerely appreciate the time they took to send me thoughts on a project that they may not even be working on!
I also update my documentation to include all suggestions sent – even the ones that I know I’m not going to include in this round (or ever). In the table of suggestions, I indicate whether each suggestion is in progress or completed, or if we’re not going to include it right now (and a very short “why”).
This way, everyone who contributed ideas can see that we took them into consideration, or if their suggestions made it to production. My coworkers are much more likely to send feedback again in the future if they know how much I appreciated it before!