34SP.com Blog

5 Tips for getting EXACTLY what you want from your Web Developer

It happens far too often that a client contracts a web developer with a mental picture of what they want, but six months later, what they have is something quite different. This disconnect often occurs because of two things:

Here are five tips that will make your next website hosting or online project far more likely to turn out exactly the way you envisioned it:

1. Write out your User Stories.

Your site has some purpose; it’s selling a product, or initiating a contact request, displaying work, or presenting information. Create a document where you get into the role of your user, and write down the path that you take through the site. Think about the elements that are needed to catch your eye and draw you into the correct path, then write it as a first person story.

“I land on the home page, which features an informative video and a large button inviting me to request a demo. I click the button, and am taken to a contact page where I enter my name and email address and click submit. I’m redirected to a thank you page that tells me I’ll receive a reply on the next business day.”

Presenting your developer with a detailed user story allows them to map out the required functionality with your mental picture clearly guiding each step. You’ll want to write out a version for each of the following scenarios:

You may also want to include some notes about the differences in mobile interactions. Given that roughly half of all web traffic is mobile, it pays to consider that functionality from the very beginning of your site planning.


2. Create comprehensive mockups of all major views in both mobile and desktop resolutions.

If you’re not providing visual guides to your developer, you’re making them guess at your intentions. That’s practically a guarantee you’re not going to get what you expected. Instead, take the user stories you created in the first tip, and list out all of the associated pages in those stories. Not every single page needs to be mapped out, but at least one example of each of the major views should be represented. With WordPress based sites, you should at the very least include the following:

If you’re using custom post types (like products or events), or custom functionality (forums, online lessons, etc.), you’ll want to include them in your list. You should at a bare minimum have a desktop and phone version of each, but for best results, include a tablet version as well. Your mockups should be as detailed as possible, and include all expected functionality.


3. Create a functional document that explains your mockups.

If a picture is worth a thousand words, then mockups should be self explanatory, right? Wrong. Your illustrations work far better when accompanied by a document explaining how the interactive elements work, and which details the properties of the items included. They also provide a quick reference to questions that a developer may spend billable time hunting through a PSD looking for an answer.

A good functional document should include the following:

Typography notes:

Brand and design notes:

Interactivity notes:

Milestones and timeline:

Work with your developer to set expectations on each of these.

Functional notes:
Clearly outline each of the expected functions in the site. If you want galleries to be presented in a grid, and selecting a thumbnail displays the full sized image in a lightbox, say exactly that. Incorporate each of the user processes contained in your user stories into this section as technical bullet points.

This document not only saves you in development time and cost by providing ready answers to your developer as they are building, it also helps set clear expectations between the two of you as to what the end result will be.


4. Ask your developer about potential risks or complexities, and work out solutions in advance.

If you’re asking for anything more complicated than the most basic cookie cutter site, there are likely complexities or risks associated with that functionality. Complexities can involve achieving custom functionality with existing plugins, complex custom post types, or advanced front end interactivity using JavaScript or similar technologies. Risks can be related to security (vulnerabilities in code or processes), or infrastructure (bandwidth limitations, server hardware, storage capacity, etc.).

Before the build begins, ask your developer the following questions:

Some developers may be confident that they’ll “figure it out” on any complexities that arise during the build, but it’s always best to address where those problem areas are up front, and make sure there is a mutual awareness of them, and a plan to address them as the build progresses.


5. Get updates weekly, and immediately address anything that isn’t going according to plan.

It’s easy to get distracted by your other responsibilities, but during a build, you should be checking in with your developer weekly to monitor progress. Any more than that, and you’re distracting them from the build with meeting requests. Any less, and you may not catch something deviating from the plan before it becomes expensive to fix.

When you see something that doesn’t see to be going to plan, immediately address it in the next update meeting. It may be that the feature or function is in transition during the build, or it may be that there is a misunderstanding of the requirement. Addressing it in a timely fashion will either resolve your concern or redirect the developer to the right path early enough to not have a significant negative impact on your budget and timeline.


Bonus tip: treat your developer like a partner.

Most developers will celebrate just as hard as you do when your project is launched. We tend to be personally invested in the projects we take on. Instead of thinking of your developer as a vendor, think of them as a partner, and interact with them in the same way:

When you take the time to set and manage clear expectations, actively manage your project, and build a partner relationship with your developer, you are far more likely to get EXACTLY what you wanted when you conceived the project.

Developers, let us know in the comments: what other tips will help your clients better set expectations?