Introduction

A guide for designers and project managers.

The world of development can seem like a complex and distant area for most of you. Developers that are not part of your familiar team or office can appear even more alien. A common situation, which is destined for much unclarity and friction.

This site however, is meant to reduce the haze and to give you an insight into the pre-development experience. By becoming aware of the approach you will gain a better understanding of your (freelance) developer and your own influence along the way. Mastering this path will result in delivering better end-products, smoother and more pleasant processes, and increased chances to achieve fruitful professional relationships.

01.

Check developer availability first

Many projects, few developers. Book a developer in advance to increase the probability of availability. Be aware they have multiple projects and clients that all need their work finished on time.

Tips

Book your developer about 2 months in advance. It gives them the ability to plan 2 or 3 projects ahead with more accuracy. In addition, it allows them to predict their future income, have a more stable business and calmer state of mind.
Give the developer a longer period for finishing the project than the estimated hours. Web projects can have unexpected issues or the need for some extra functionality. Having a longer period creates space for fluidity when scheduling one project after another. As a guideline you can schedule 8 weeks for a 160-hour project.
Agree upon an internal deadline before the actual deadline, which you have promised to the client. This creates room for the designer to give feedback and have it applied before the final presentation.
If possible, estimate time based on previous projects you have done together.

Negative pitfalls

Nobody likes to say no to really cool projects. Be on time and your favorite developer won’t get hurt emotionally.
Short deadlines increase the chances of overlapping projects, which give extra stress, increase the probability of flaws, chaotic code, bad website performance, and can eventually lead to a disappointed client, an unhappy team and poor relationships.

02.

Check scope with developer

The web can be very complex and not all developers have the same skills or knowledge. Check with your developer whenever a feature seems technically challenging and find out if it is within the skillset and what consequences it would have for the timeline.

Tips

Many skills can be learned on the job. Give the developer the ability to share his technical vulnerabilities so you can predict difficult situations in the timeline or find a backup solution for a specific skill.

Negative pitfalls

Not communicating technical challenges can turn into an unexpected cancellation of the booking. These challenges can simply turn out to be unachievable in such a short time or are not aspiring to learn for them.
Tackling an unexpected difficult technical challenge in the middle of a project can cause the developer to lose too much time on one specific task. This can result in not reaching the deadline. Or worse, not finishing the project at all.

03.

Estimating with final wireframes

For the most accurate estimation of development time your developer needs to have the final design. Since this is not always possible, you should use the final wireframes that are signed off by the client. An incomplete overview of the work will naturally lead to incomplete estimations.

Tips

Make sure the developer goes over the wireframes with the UX designer. Interactive parts or animations can be very time consuming and are easily overlooked in the wireframes.
Work with time references from previous projects.
Use references of animations and effects from other websites to give a better overview of the workload.

Negative pitfalls

If the design or wireframes are not final, the developers estimate will not be final either. This results in extra rounds of estimations and extra meetings for elaboration.
Extra iterations could be prevented and can therefore cause bad spirit. It is not fun to do and it is a loss of time and resources to do something twice, unnecessarily.
If there is no correct estimation it will also be impossible to promise future deadlines to other clients.
No meeting with the UX designer can cause unwanted surprises in the middle of the project, cause a miscalculation in time and threaten the deadline and budget.

04.

Recalibrate planning, confirm start date

With a complete overview from the final wireframes, check if the timeline that was initially set still works. Recalibrate with your team and make sure everyone is aware of their individual deadlines. This is essential to have fluid flow of deliverables per phase and prevent any team members to be unable to start their work.

Tips

Make a fair recalibration together with your developer so everybody is on the same page and you are able to communicate this with the client ahead of time.

Negative pitfalls

When freelance developers cannot start on the planned start date and this is not communicated on time, it will directly affect their income. It will be difficult to find a new project that will not interfere with the timeline of future work and on such a short notice.
When the deadline moves, future projects need to be rescheduled. Informing clients about moving the timeline can cause uncomfortable situations and force you to come back on promises you have made. It can affect your credibility in the long run.
In addition, a developer might have turned down various other cool projects, which now hurts even more than before.
Your developer might start to book other projects at the same time because you have turned out to be unreliable. This could lead to messy deadlines, chaotic projects and bad relationships with clients and team members.

05.

Design phase check-ups

Designers can have wild ideas with layout, interactivity and animation. The web, however, is a restricted place technically and achieving certain results can easily become very time consuming. Discuss your intentions with your developer to increase the chance of realisation.

Tips

Every developer has its own limitations of knowledge and skills but a lot can be learned as you go. The faster you communicate, the more time to learn.

Negative pitfalls

Designers could present ideas to the client that the developer cannot recreate in code. This ends up in false promises and a disappointed client.
Some ideas take more time to develop than others. It might be possible with some extra budget and then everybody is happy.
Some ideas might be technically possible in a slightly different way. With some adjustments you could present something more realistic to the client and prevent disappointment.

06.

Explain the final design

A design isn’t always fully self-explanatory. Let the designer go over every page and component and give the developer the chance to ask about technical specifications for a more complete picture of the work.

Tips

The designer should show references of effects or interactive elements to accurately communicate what he wants to achieve and if that is possible within the budget.
When there are differences between the final design and final wireframes there might be room for a tradeoff. For example, a cool page transition instead of the second contact form on the about page.

Negative pitfalls

No explanation by the designer could lead to a personal interpretation from the developer. This rarely turns out into the desired outcome and will most likely produce angry designers.
If the interpretation of the developer was incorrect he might be forced to do things all over again. This could lead to angry developers, a messy code-base that is not cleaned up correctly after a few of these encounters. Messy code is bad for the website’s performance and makes future development harder, longer and therefore more expensive.
Differences between design and wireframe could require a new estimation, which is significant for the timeline and budget.

07.

The more variables in design the longer the development

08.

Don’t start development without the final design

Changing a design is technically easy, changing the code is not. When done right, development is a precise and carefully crafted job. Best results come from only putting in there what needs to be in there. There is a thought-out structure and specific strategy to turn the design into a perfectly functioning site. When the design is not yet final, it means that things can change. These changes can have big effects on the developer’s strategy, structure and time.

Tips

Ask yourself (designer or project manager), how fast does the client respond to feedback? And is there a chance development is scheduled too close to the design phase? It can prevent doing double the work unneccesarily.
Use dummy images to have the client sign off on the design first. Do not wait or focus on the client to sign off on illustrations or images, these are irrelevant for developers. They just need to know that a visual is required in a certain place.

Negative pitfalls

Starting the project without the final design is more likely to make your project and timeline longer instead of shorter.
A change in the design could mean a totally different fundamental structure of the code. There are very high possibilities that you need to start over a large part of your project. Or in the worst case, your entire project.
The code needs to stay clean. When you need to change pieces of your code you need to carefully check what you want to keep and what you want to delete. Keeping code that is not relevant anymore in your project will turn your project into a “Frankenstein”.
The more code, the more difficult to navigate. Not keeping your code clean will always result in a more time consuming headache project, if not now, it will be in the future when the client requires changes.

09.

No interference during the development phase

Every developer has its own way of creating the final product. A lot of this process is behind the scenes and not directly visible. One could spend an entire week fully working on a website, without seeing anything change on the frontend. It is therefore key to not have a client or designer interfere in this process. It could lead to an incorrect image of the progress that has been made.

Tips

Don’t share a staging url with the client until the website is almost done. It could affect his thoughts and spark new ideas, which are out of scope.

Negative pitfalls

Giving the client the ability to interfere will give him more time to think about things and create new ideas. The client will say that he has become absolutely sure that this is how he wants it now and that this is the last “tweak”. Let’s not do this, since these situations rarely fit the budget or schedule.
When the client feels that nothing is showing up on the staging url he could get worried and lose faith in the project. He could feel that he spends a lot of money and nothing is happening.

10.

Communication between developer and designer

The web is dynamic and has its own rules. During the transition from design to a working website there can be a lot of issues or uncertainties. It is key to keep communication channels open so that developer and designer can solve problems together where needed.

Negative pitfalls

If it is not possible to discuss difficulties with the designer, the decisions of the developer may not comply with the designers intention.
If the developer is in a tight spot with timing there might be a quick decision to be taken to reach the deadline.

11.

Prevent communication with the client directly

Clients can be very enthusiastic and demanding. Their ideas keep flowing and thoughts and questions popup all the time. These thoughts and questions can lead to a direct communication line with the developer because it seems easier at first. This however, will will only turn the role with the project manager around. The developer will now: speak to the client, organise the task, check the budget with the project manager and if he eventually gets to it, actually start developing.

Negative pitfalls

A project manager will lose track on the general overview of the project because she does not have control over the incoming tasks that might be out of scope.
There is a chance the developer will charge you for these extra hours where he is managing the project. Or charge overtime because he could not finish the work.
Developer will lose energy on project management instead of putting it in the quality of his code

12.

Prevent trying design changes directly in the code

Can you try this? Can you try that? This game is commonly played and can be a big time stealer.

13.

Big changes as independent iterations

It could happen that a client wishes to add extra functionalities or changes. Big changes however require a new plan and are best treated as a separate new project.

Tips

Plan big changes as soon as possible so it can be produced right after the project delivery.
Some developers find it hard to say no, so give them the space to elaborate if they do not have time and work with them instead of against them.

Negative pitfalls

Developers are scarce and they will probably have other projects scheduled right after. Be fast or accept the situation.
Pressuring developers into extra work, which they don’t have time for, can feel unfair, uncomfortable and harm your relationship.