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:

• The client hasn’t provided a complete picture of their desired end result.
• The developer hasn’t done an adequate job of filling in those blanks during discovery.

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:

• Each type of conversion on your site: a contact request, a purchase, information access, etc.
• Each major user role on your site: a customer, a prospect, an administrator, etc.

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:

• Landing page
• Inner content page
• Contact page
• Blog page or archive view
• Single post

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:

• Font families used
• Font sizes for each of the elements on page

Brand and design notes:

• Hex values for each of the colors in the content, including graphical content like logos
• Padding and margin values for standard elements
• Content notes related to how your brand is presented, for example, “Our company name always appears in all caps in text.” (This is an actual note from one of my clients.)

Interactivity notes:

• Hex values and description for link or graphic hover effects
• Description of any expected animation during page load or scroll
• Any required redirection (for example, “users are redirected to the home page on login”).

Milestones and timeline:

• What should be completed at the end of each week?
• What is the total build 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:

• What do you think the most complicated part of this project is from a development perspective?
• Are you comfortable that you have a solution for that worked out, or is more research needed?
• Do any of the requirements present any risks (security, functionality, otherwise), and how will we mitigate that risk?

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:

• Spend some time educating them not just about the specific project, but your company in general. Make sure they have a solid understanding of how you do business, and what your product is. Help them understand your business culture and values.
• Make it clear you value their professional opinion, and solicit their input on every part of your project. If you bring in your developer during the requirements phase of your project, their input will help you build a better set of requirements. Their expertise during this phase can streamline user processes, and solve problems you didn’t even see existing yet.
• Respect their time. You’re paying for it, so try not to waste it. Don’t call when an email will do.

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?