Building of a web-project is usually a collaboration between a developer and a designer. Usually, these people are from very different worlds – they think differently as designers are more interested in the artistic elements and the sort of emotional responses that the design will create in users. Developers, on the other hand, are more interested in the logical functionality – the coding (or programming as many people call it). So, you are looking at two very different personalities, with different priorities, which can often lead to professional clashes if there isn’t effective communication.
This article gives you some practical tips on how to avoid a big bust up in the office (the advantages are great – you don’t get insulted, you don’t lose your job, and you avoid arrest – yay!). On a serious note, both designers and developers have a common agenda – and that is the overall quality of product. It makes sense to work together effectively.
Where are the potential problems?
It often starts when a developer, who has to transform PSD files to an HTML markup, sees the design for the first time. The worst scenario is when she/he sees it too late in the design and development process – when almost the whole design process is finished, and there was little or no communication during the design process. This is a recipe for disaster and understandably frustrating the developer. This frustration is very quickly felt by the designer, especially if a designer has included some uber-cool ideas with no thought about the development impact e.g. the inclusion of non-standard radio buttons, drop-down menus and/or transparent effects. The developer may feel it is impractical and the designer may feel that the long hours of hard work are at risk of being changed to suit the quiet guy (developer!). The developer, on the other hand is frustrated as all the “cool” design features may require jQuery coding, which usually much more time-consuming than simple HTML. The quiet guy with the funny hair is not happy as he had no warning of things to come his way.
Another classic scenario is when a designer prepares the files in a non-standard way. For example, as a developer, I received the designs in Adobe Illustrator files – If only the designer had spoken to me during the process my entire response would have been different.
Additionally, the design and development process can be derailed when dealing with graphic layers, designers are sometimes insensitive to the fact that they have to be designed in a way which makes it easy for the developer to extract separate images or backgrounds.
Solution: Talk to me baby!
It’s really as simple as that.
But let’s dig a little deeper – what do I have in mind. The point is to get a designer and a developer to talk from the very beginning, ideally with a project manager or a client participating. All players in the total process ought to discuss and reach a clear and common understanding of the end goal of the project. Further, each team member must be clear about individual roles, both their own and that of the others on the team. It really helps everyone, and the more importantly, the creative and production process as a whole if expectations are expressed by both the developer and the designer. browser shots . Basically, some ground rules are set outlining the frequency of the communication process, keeping all parties happy from the outset.
A simple and very effective mechanism is to share the results of work completed as soon as they are completed so that you don’t get to the end of a long process and one party discovers that what they expected and what the final product is, is different. This is vital to avoid unnecessary work later on.
Quality of work saves time (and money)
Let’s look at it from a perspective of a client, who is looking to hire a team for his project. Obviously, the client desires quality, often while seeking the most cost effective development solution. Both designers and developers often encounter clients that fall into this category – the client aims high calibre work for minimal money. We know from experience that very rarely can the two exist together. Clients often fail to realise (or pretend that don’t realise) that the less experienced designer and/or coder is often the cheaper alternative. The inexperience can be a costly mistake if they do not communicate at every critical milestone in the process. Work may have to be redone.
The designer and the developer are two halves of the same coin, and if at least of them fails, the project is highly likely to fail in general – consequently placing the reputation of both in jeopardy. So the advice here is not try just to save money blindly – look for professionals that are matched in skill and are open to communicating when building a team. If you are a developer, don’t try to find the cheapest designer and vice versa.
*With prior permission from the author, the article was edited by the Despreneur editorial team.
Did you enjoy this post?
Never miss a blog post. Subscribe below to get more posts like this sent straight to your inbox as soon as they're published.