How to Effectively Communicate With Your Web Developer
Let’s talk about how to set yourself up for success by learning to communicate with your web developer. When you’re working with a developer, getting what you want can be frustrating, and I believe all the trouble is associated with communication. While skillsets vary, the developer’s competency should not be an issue if you properly interviewed your developer.
Before I was a web developer I was faced with this exact challenge. I hired a web development company and ended up with a bad website. The website was terrible, and I was out of budget. The result of my site troubles eventually led me down the road to my current development career! Over time, I came to the conclusion that the development team may not have been the most skilled (I was on a tight budget), but my communication as a client undermined their ability to do their job the right way.
How Do I Set My Project Up For Success?
The first thing you should know (even before speaking with a developer) is when you need the project completed and/or published. If you have a lenient timeline (like “sometime this month” as opposed to a specific day only a couple weeks from today), give the developer a little less cushion than you need. If you’re looking to hit a very near-term deadline, go with an expert. Expert web developers typically have experience with the many random/unexpected issues that come up on web projects. They can overcome these issues quickly, at least much more quickly than a beginner or intermediate developer could, and are more likely to hit a deadline regardless of what kind of unexpected troubles they may hit. If an intermediate or beginning developer encounters these same issues, your timeline may be in jeopardy.
Long Deadline? Create a Faster than Necessary Timeline to Completion
If you are working with a longer timeline, you have a little bit more wiggle room. I highly recommend putting a week or two in between your “want” deadline and your “need” deadline. Tell the developer you want the project done a couple of weeks in advance of when you really need it done, so in the event of an issue, you can knock that deadline back and still end up very happy with the outcome. Frustration seldom accelerates a website build and having a little wiggle room will help to minimize timeline-based conflict. Leniency is always appreciated by developers when the unknown comes up, and if they are like me, the forgiveness on a timeline will push them to complete your project much more than someone who is already upset.
Define What Will Make Your Project a Success
Defining your wants and needs for what would make the project a successful outcome requires excessive detail. Lack of detail is a killer because when you don’t provide details, the developer is forced to improvise. In the absence of guidance, the developer is going to do their best at building a site (which often leads to a site based on the developer’s preferences instead of yours), and that’s not necessarily going to be what you want. As a developer, I have been stuck in this situation and had to hope for the best. It creates unnecessary stress and often leads to extra revisions. As a rule I try to fix communication errors like this as fast as possible, and if the client can’t provide sufficient details, they become ineligible for long term work together.
Being over-detailed, talking about your content goals, talking about what kind of pages you want, what color scheme you want to use, and what websites you like is a great thing for a developer. For instance, I always ask my clients what websites do you like, and why (because the why gives me insights into their content/function/design preferences). When you want a website created, give examples from all over the internet – not just industry-related websites. Examples and gratuitous detail gives your developer a clear picture to work with, and without being too micro about your wants and needs, you can give a developer a great toolkit to start your web project on the right foot.
What About Revisions?
Even if you’re completely detailed with the project, revisions are a must and make sure to be very open and honest with the developer. Do your best to course correct rather than condemn the developer for getting something wrong at this point because first drafts are often created with “risky” content that may not make its way to the published final product.
I set up the communication with my clients with the following expectations: I finish the first draft of your website, and I think it looks great. Now, with that in mind, I expect fully for you to take a look at this and like some things, but also really not like other things. I don’t want you to pull punches. If you tell me what you don’t like, I have the opportunity to fix that and improve it now. So, as a client, it is your job to be honest. If you don’t like something, speak up and try to explain why you don’t like something. If you don’t like a header because it takes up too much space, say that. Don’t say, “I just don’t like this.” It doesn’t provide context, and the developer needs context in order to improve something to your liking.
What may seem to you like too much detail may be exactly what the developer needs to know, and that’s a really important aspect that will set both of you up for success.
Budgeting for Success
Know your financials before even starting your website. I made the mistake of blowing my entire budget on a project and it became a huge waste of money due to my inability to plan. This should help you plan effectively and not find yourself in the position I put myself in.
A great developer might seem to cost a little bit more, but it’s not always the case. If you are investing in a developer and you go the budget route, you will see developers who offer a low hourly rate but take more time to complete a project. I personally charge premium rates but have seen where other companies charge less and take hours more, so you end up paying just about the same amount. You feel like you save money for a great website from a less experienced developer, but often you end up spending more money for a worse website.
One of the ways you can avoid skillset breakdowns is to set up up a fixed cost project by saying, “My budget’s $2,000. This is what I want and when I want it.” The project is done when you get it done. But the problem with that is if you poorly define your initial goals and you miss something, you’re going to have to increase that budget. So, instead, I highly recommend setting up what I usually do for my clients, which is “not to exceed” hours estimate. So you find a developer that has defined their hourly pay rate and you say, “I expect this project to take about 20 hours, and I would like to just, on the safe side, say that if the project takes 30 hours, you will not exceed that rate and take the project at the fixed cost equivalent of this max.”
What setting a “not to exceed max rate” does is it puts the developer in a good position to succeed. If the project takes the amount of time allotted, they get the hourly rate. If the developer doesn’t see what’s in it for them, a bonus for a project coming in under a certain number of hours is a great way to push for efficient work. The key takeaway is that both you and the developer have skin in the game here. An experienced developer should be able to estimate the amount of time to get a project complete and not worry about that not to exceed time. But if someone makes a mistake, the developer is still incentivized to get the problem fixed right and quickly, so that way the dev doesn’t waste your time or theirs.
So just ask for a not to exceed hours limit and expect the project to come in at the max rate, and then also make sure to say that, “All of the details of the project are here.” Major deviations will reassess the hours limit for that kind of project. This way if the project comes in under the hours, you end up getting a great deal on your website and your developer feels good about doing the project well.
Remain in Consistent Communication
When you’re working on a project, it is important that you communicate early and often. If you want to set up a regular meeting with a developer, that’s a great way to go, but also along the way, be communicative. For instance, if you’re building a website and you can’t quite judge the skill level of the developer, give them a small portion of the project to start. You could have the dev build a single page of the site on one of their own servers as a quick test to see how efficient they can be. Give them a time limit in order to get a sense of their output capability. So, if you benchmark how much production they’re able to do in a certain amount of time, what they’ve got after one page, you’ll get a very good idea of their efficiency, of their output, of how you like it, what you like and dislike, and you can course-correct appropriately from there and get a really good idea of what you’re getting for your money.
So, communicating early and often will effectively help you save money and time, and also gives the developer crucial information on how they can help you to succeed in your goal. So, that’s communicating early and often, and then there are a few other things which kind of run in line with that, which is setting incentivized benchmarks. I am a big fan of working with clients that put me on a time challenge. If the project is done in X hours I will pay you 120% of the agreed on hourly rate, but if your take Y hours, the rate is going to be lower.
There are ways to give a developer a little bit more skin in the game. When you get creative, and you make it a little bit more like you can earn a little bit more if you do a little more for me, like advancing a timeline, or if you prioritize this project and, you know, you make certain things happen that are a little bit above and beyond the call of a standard development job, it’s a great way to get the developer’s head focused on your project as opposed to being one of the many projects lacking in communication.
The incentivized project style works especially well when a project scope blew out of proportion, and they’re overwhelmed, but they get to work with your project, and it’s straightforward and easy, and they know what they need to do to succeed. It’s frictionless. When you work with the person that you like to work with, they’re incentivized to spend more time doing it the right way with you.
Respect The Developer’s Time
So, the last thing and most important is to be respectful of the developer’s time. They’re probably working on more than one project, so understand that their communication timelines may be a little bit variable because when they’re working on projects, they’re also probably looking for other jobs.
They’re also working with other clients that may have similar expectations, so if you can, schedule appointments to meet with your developer either over the phone, Zoom, in-person, or whatever is working for you. Also, if you can send something in an email and give an action list, that’s the best, and let that communication be frequent, but not overwhelming. I’ve had clients that send me 50 1-sentence emails, and that’s the last thing I want to see. But when I get a client who sends a single 150-sentence email, it’s great because I usually print it out and use it as a checklist to make sure that I make their result great.
So, again, setting timeline goals, being overly detailed, budgeting appropriately, communicating early and often, setting benchmarks, and being respectful of the developer’s time are all crucial keys to having a successful communication and outcome with your project.
Request a Strategy Consultation
Contact us today to learn more about how This Web Developer can help you create the best site for your business. We will reach out to schedule a meeting and answer any questions you might have.