Cut down on emails: 5 tips to help communicate with your developer

It’s a common problem when working with developers, you ask a simple question, report an error, or request a change. Three hours later you’ve exchanged 20 emails and you don’t have any answers. Being a project manager I have been on both ends of this predicament. Either I’m trying to solve a problem I don’t understand or can’t see, or I’m getting frustrated as to why my seemingly simple request continues to get messed up.

Here are 5 key steps to stop email back and forth:

1. Be specific & detailed
   Something simple like “my form is broken” seems straightforward, but there are actually a lot of elements that make up a form. Any number of things may be broken for that statement to be true. Is the form not submitting? Are the drop-down fields wrong or not displaying? Does it not work correctly on a phone? Is the thank you email not sending or are you not getting notifications of submissions?

   Let your developer know exactly what is wrong with as much specific details as you can. It may seem tedious, but when they come back and say “I’ve submitted the form and did not have any issues” you’ll wish you saved yourself the time and explained a bit more.

Let your developer know exactly what is wrong with as much specific details as you can.

2. Send screenshots
   Every browser, monitor, operating system, mobile device is different, and there are a lot of combinations between them. If something is not working or does not look right to you, send a picture of exactly what you see. The easiest way for a developer to fix a problem is to be able to duplicate it. Knowing what that issue looks like helps cut out on a lot of the guessing – a picture says a thousand words.

If something is not working or does not look right to you, send a picture of exactly what you see.

3. Send device, URL, & browser details
   This one plays off the first two items but is worth mentioning. The faster someone can replicate an issue, the faster they can resolve it. Some issues are device or browser specific, and this information can really help. It will cut down on a lot of questions and frustration knowing where the problem happens.

   As in the case of “my form is broken.” Which form? Do you have more than one? Do you mean your contact form or your newsletter subscription field? Which page? Is it on the about page or the about the team page? It’s important to know what the exact URL is.

The faster someone can replicate an issue, the faster they can resolve it.

4. Provide a history & a timeline
   Give your developer some history. Even something as simple as – this feature was working last night & I have not made changes in months can help a lot. It doesn’t matter how small or large an issue is, knowing the rough timeline helps backtrack to any activity at the time or date that could be the culprit.

   Also, provide some context on the issue. Is this a rush issue or did you just happen to notice something? Knowing the level of urgency around a request or question helps developers prioritize your work and cuts down on additional costs. “Broken” typically implies something is urgent, but you may not care enough to pay for someone to rush. So let your developer know.

Knowing the level of urgency around a request or question helps developers prioritize your work and cuts down on additional costs.

5. Do not assume there is a standard
   In some instances there are best practices and web standards, but not always. When you say “I want my form question to have three options” does that mean radio buttons or does that mean checkboxes? You may be seeing radio buttons in your head, but that is not a given.

In some instances there are best practices and web standards, but not always.

This last tip is the one I am probably the most guilty of breaking. Working closely with developers online through chat you sometimes forget the details. It’s frustrating when it happens because you feel that they should have known what you meant, but in reality, there was no way anyone could know what I was thinking

This may seem daunting (and yes, in some instances all this can be overkill), but when you are having a critical problem on your site and your developer resolves your issue immediately, you’ll be happy you spent the time providing additional information.