6 Tips About How to Communicate with Developers

CodingAndrian Valeanu • August 05, 2011 • 6 minutes READ

If you have an experience of working with a developer or a development team then you might be well aware of the fact that frequently differences of ideas and work attitude do crop up between a designer and a developer. As designers we have to work with scores of international developers and teams who have different viewpoints and work culture. Most often we have to work with unknown developers based on some other place on the globe and there is little chance of face to face contact.

Most of the times hundreds of people are involved in a project and very often these people do not belong to a same team, organization; rather they rarely know each other. But while working in a common project, it is very important that all the people working on it must share a common understanding of the problems and solutions. It should be remembered that developers and designers have different work attitude and ideas.

Rarely these two type of professionals share commonness of nature and attitude. Therefore to make the development process run smooth in future you may follow these principles and hope for better results.

1. In depth Documentation:

In this age of Information Technology and software developments you may easily believe that documentation is not so important or less documentation will do the work, but it is not really so. Documentation is always very important for understanding and in depth analysis. For beginners, the user interface is the best documentation. The UI provide the developer with the basic ideas of where data should be and how it is to be formatted. It also focuses on what is to be done. A well defined and innovative UI will certainly help the developer. But there are many developers who wish to work independently on your interface. These developers are few and they are not appreciated in the designers’ community.

It is highly recommendable that you stay ahead of the developers though it is not a necessity for a designer to think about each and every page before starting development. But if you have your plan ready and possess some type of structure like HTML handy, then you may provide it immediately as soon the developer ask for it. Many developers like to insert data on a ready page rather than creating the page from scratch and let the designers work after them.

2. Make Decision:

Being designers we have to take lots of decisions on each and every interface we work upon. We have to take decisions on amount of text to be used in a table cell, height of navigation, or the alignment of text in the footer. Similarly the developers too have to take hundreds of decisions during their work. But development is less subjective than design. The code style, language and architecture may attract different opinions. Some may choose for illustrations while others may opt for images. Everyone has his own choice of colors and many colors may provide different perception to every individual.

Being designers it is our job to decide upon the style and look of the interface. However many developers do interfere in the UI, but it is indeed not their job. It only kills some more time. Also it is to be remembered and recommended to avoid any sort of alteration in the design of UI while the developers are working on it. If the design is changed it will only make the job of the developers more critical and difficult as changing of HTML is tedious. Stick to one HTML structure. CSS should control the interface; therefore accept the HTML as backend code that cannot be altered easily. Just as like designers do not like providing revisions to the clients, Developers too dislike refactoring their code.

3. Be ready for communication:

The user interface that you have developed after so much exhaustive work is to be handed over to the development team. This is where designing part ends and development starts. Being designers it is hoped that the design concept gets fully utilized in the working application. Never believe that what you have envisioned will be completed by the developer, rather get involved and stay connected with the developers throughout.

Make yourself available for communication and clarification whenever the developer seeks for. There may be many issues that need to be sort out and developed only after a discussion between the designer and the developer. Unless everything is clarified the desired outcome will never come, so try to clarify everything what the developer wants to know. Make the developer understand about your requirements and make him comfortable with your views.

4. Avert creeping of features:

The book “Getting Real” discusses about this problem. Though this topic is more relevant to product managers, it is similarly important for designers. Always ensure why a particular feature matter. Always try to avert a UI which is complex because it will lead to unwanted hamper in development and therefore result in missing the deadline. If you think that a particular feature is least importance then just deletes it to avoid complexity. Always have focus on users’ interest. Take an example, if you are well aware of the fact that your users will not use invoicing heavily or there are better alternatives easily available in the market then simply don’t include the feature.

In one of our recent projects we did not provide a full suite of tools including invoicing, rather we desired to focus on bids, proposals and request for proposals. As we felt that we have to serve a small user base that needs invoicing, we decided to add a simple bare-bone system rather than creating a full featured invoicing system.

5. Deadlines should be strictly maintained:

Deadlines for projects and delivering them to the clients on right time should be strictly adhered in order to maintain goodwill and professionalism. Being designers we can easily create the designs but when the project goes to the developers it requires good amount of time. Developers might need some time to implement all the features. Sometimes they might need clarification from the designer before implementing a feature. All these needs some time, therefore give your client a date which would be safe for any delay.

You may face some unforeseen delay while working on a project. You may fall ill; your family may need you for sometime or certain unwanted delays may crop up from nowhere, so it is better not to commit any date to the client. Be sure that it will take more than six months to complete a project. Remember never to commit about dates to your clients. Make your client realize that a good project needs time to be implemented successfully. An intelligent client will never ask for quick delivery, rather he will be pleased to get the best product. The client will for look forward for value for his money.

6. See for yourself: Be confident:

It’s your project; therefore just don’t leave everything upon your developer. Test the codes yourself and see whether they are functioning properly or not. Find out if everything has been done according to your specifications and client requirements. The developers are professional and will do their job accurately, but mistakes might occur anytime. Never blame them, but try to fix the problem first of all. Talk to your developer and explain them about the drawbacks and discuss what is expected. Keep the testing job upon yourself and this will help the developers to concentrate upon their job. While testing if you find bugs, fully document them, take screenshots, and decide what to recreate and what should be the required outcome.

Normally developers dislike any type of testing the code. Big organizations appoint Quality Assurance professionals to check the job done by the developers and wish to ensure that there shall be no drawbacks in their projects. So it is better to test the codes yourself. You are the best judge.

Set goals for your team and check on the performance from time to time. Supervise upon your team as how well and quickly they are fixing the bugs and creating new features. Try to fix the bugs at the first instance and regulate any future problem. As the project is yours, you will be purely responsible for any success or failure. Therefore keep yourself at the command line and go on with your project.