How to communicate with developers

We are recognized as a top App Design & Development Company on DesignRush.

The wind blew across the blue waves, and set the tone of the day: blue. There is a downed tree in their yard, I wonder when they’re going to take care of it? Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

Language is an imprecise tool – especially when you’re attempting to communicate abstract, involved ideas and concepts. Language barriers aren’t just limited to foreign languages – they’re present amongst different professions as well.

Take, for example, the muddy waters of acronyms (which tech is rife with): A chemical engineer is talking to a software engineer about APIs. The chemical engineer thinks they’re speaking about Active Pharmaceutical Ingredients, and the software engineer is thinking Application Programming Interfaces – they’re both engineers (admittedly in very different fields) but they’re talking about completely different subjects, all while using the exact same acronym.

This game of telephone is compounded when two (or more) people who work within completely different schools of thought are communicating the intentions of their ideas. We’ve all been trained to think in different ways, depending on our type of profession: writers live and die by the five w’s and the upside down pyramid, while graphic designers think in the rule of thirds and adhere to visual hierarchy. Mechanical engineers live and breathe f=ma and deal with safety regulations while physicists work with… well, who really knows? You get the idea.

Okay, okay… just one more. A software engineer is sent to the grocery store with a set of instructions: “Buy a carton of milk, and if they have eggs, get six.” The engineer comes back with six cartons of milk. The person who sent them to the store asks, “why did you buy six cartons of milk?” The engineer replies, “They had eggs.”

How to break through the barrier

The first thing to keep in mind (and this is very important) is that software engineers are people too. As much fun as it is to pretend like they’re robots, they have feelings just like you and me – and communicating with them as such is crucial to a successful development cycle.

The easiest way to get around miscommunication is to accept it will happen – and plan for it in your development schedule. There’s a lot going on during mobile app development – a UI designer will look at a project one way, while a programmer will look at it from a different lens, and a project manager will have a unique perspective as well.

Treat your people like people, and you’ll already be miles ahead.

Be organized

It doesn’t matter what tools your team uses to communicate with each other and keep tasks organized – all that matters is you do it. There’s a bunch of project management platforms out there for you to choose from, but it’s important to pick the one that fits your team’s needs and preferences the best.

We like to use Trello, as we can keep track of an entire sprint and the tasks that make up the sprint in an easily digestible format. Our project manager will break these tasks down into individual features that need to be implemented, with specific details of what the final product should be – the flow, the visuals, and the information that must be included.

It’s important to make a distinction here – a project manager doesn’t tell the software engineers how to implement a feature – just what features need to be implemented where. A good project manager can admit they aren’t as technically savvy as the software engineers (unless they were originally a programmer), and will communicate that to their dev team. A good project manager should also know every use case scenario, every step of the app’s process and it’s flow, and it’s entire feature set.

Our project manager rarely fields technical questions – most of the questions software engineers will ask are more about clarification than “how do I do this?” Questions you can expect from developers will be:

“Where should I place the quotations in the text field?” Or, “What font should I use?”

It’s best to provide every piece of information every time. Don’t worry about making your lists pretty – software engineers aren’t worried about that. What they’re concerned with is getting things to their exact specifications. If your project uses multiple fonts, denote which fonts should be used where for each and every task. If you need an to turn 50% opaque after being interacted with, include that information in the task.

There’s no such thing as “over describing” when it comes to code. Say what you mean in the simplest terms possible, repeat information whenever necessary, and communicate exactly what you want and expect. The less wiggle room, the better – be direct.

Code iterations can become repetitive – if you have a sneaking suspicion that you and a software developer are speaking about two different features, clarify. Programmers love clarification.

A picture is worth a thousand words

A prototype is worth a million. If your software engineers can actually analyze what the final product should look like, and how it should act, they’re much more likely to implement your concept correctly. Just like project management tools, there’s a lot of prototyping platforms out there. We prefer to use Invision.

It’s good practice to keep track of your assets by assigning a universal naming convention, i.e. “homescreen_header.svg” rather than just “header.svg”. This will help your developers keep track of what goes where. Checklists are a big help here.

Don’t be afraid to use sketches either – they don’t have to be pretty to get the idea across. Use every medium available to you to express your idea before development gets into the swing of things. Use flowcharts to help software engineers keep track of the flow of the app.

Know your project

Top to bottom, front to back. The more you know about your project – the better. Software engineers don’t have the answer to everything. The work they do might seem like magic, but a lot of programmers are very specialized – a front end developer might even have less knowledge about backend logic than you!

The key to good development is to build a good relationship with your software engineers – and this is achieved by clear and concise communication.