Communication: A Designer’s Guide to Speaking with Developers

Other Comments Off on Communication: A Designer’s Guide to Speaking with Developers

One of the most frustrating duties for designers is communicating with the developers and convincing them to follow their design. This is one of the tasks that you didn’t sign for, but come with the job anyway. There are plenty of tips for us to share with you to help make this easier.

Communication Through Documents

Documentation is the first way you present your idea. The text portion of documents should be as short as possible, even point form if you can accomplish it and have it be understandable. Technical writing is a skill not many possess, but even if you haven’t learned it, you can still make a nice document.

The document should list the features and behavior of each feature. Use short specific sentences, and basic language. Unlike many other forms of writing, you’re not showing off your intelligence or what you know, you’re giving instructions on how to build your design. The simpler your document, the sentences and the concepts, the easier it will be to understand.

With short and simple in mind, you should use sketches to describe your design whenever possible. “A picture is worth 1000 words” they say, and in technical design writing, saving words is what you want to do. Sketches and wireframes are the way to describe positioning, visual elements and different states of your features. You can draw them by hand on a piece of grid paper, or you can use a wireframing tool like You can use more advanced tools too if you’re proficient with them, but you do not need to do anything incredibly fancy. Like your language, your design should be as minimalistic as it can be.

Flowcharts are the final piece of the design documentation puzzle. Showing how the different screen states interact with each other is gold in a developers hands. It puts everything in relation to each other, and clarifies the relationship all the sections of the site.

Communication through flowcharts

A very basic sample flowchart

When the project begins, not all of the documentation is required to be completed, but you should have enough to get the developers started and you need to be ahead of the developers. Generally, developers working in sprints need 2 weeks of development time planned in advance.

Make Your Decisions

An indecisive designer is an extra expense, a time waster and a frustrating experience for everyone. The last thing a developer needs is to change what they had just completed in the past sprint.

Developers working in an AGILE or SCRUM environment make a plan every 2 weeks, the first day the schedule every hour and then they work through their hourly tasks until the end of the week. This 2 week system is very solid, adding or changing items makes them scramble and have to reschedule tasks for the entire team to reach the same goal. Changing your mind mid sprint affects their efficiency greatly.

Developers may even resist changes mid sprint because of the amount of planning that goes into a sprint. They may prefer to skip a feature until the next sprint, or if they already completed it, they won’t change it.

During the sprint, the developers working on your project will likely give you a rough prototype for each feature being produced, then give a final product. You should be testing the prototype thoroughly. Not necessarily looking for bugs, but for deviations to your design. Comment about everything.

Comments such as these are not an opportunity to be mean. They are professionals just like you are. Like your design document, keep your comments short and use imagery when you can.

After testing and commenting on the prototype, they will give you a final product candidate, which you need to test and comment on as well. Here though, you should also be commenting on technical bugs.

By being confident in your design, and being professional in your communication, you’ll be able to communicate well with your developers during the projects creation.

Keep Your Scope In Mind

When developers take a project, they expect a little variation in the design. They expect that when you contact them the design is somewhat solidified. You are allowed to make changes, and even make an addition or two, but as you use your product, features come to your mind.

Every change you make, and every feature you add means additional costs and increases time to market. If you’re a freelance designer, you also have to manage your client’s ideas. Keep feature creep to a minimum.

Communicating Deadlines, Respect Deadlines

You need your product produced, and they need the design designed. You both need to understand that you are dependent on each other.

In order to produce your product, they will need your design in time for their planning. Communicate with them, ask them when they need, and tell them your own.

In short, respect your developers in your documentation and your communication, and the website you designed will be completed smoothly and efficiently.

The following two tabs change content below.

Comments are closed.