... And Give This Guide To Your Next Client

These are a series of client-directed notes that I put together following a really poorly-planned project with the intent of communicating how to do better next time. Will each of these items seem obvious to us as developers? Certainly. How about to our clients and designers that are directing the work? Too often, not at all. Read on -->

Tl;dr - Put together a clear design that is complete before the development work gets started. Give all of those details to your developer up front. If they ask questions before or during, give a complete answer. They should not have to make any assumptions or guesses unless you have hired them to do that planning and/or design work in addition to development. Treat them well, and have a clear idea about your budget going in.

Do More With The Design Doc:

• Lay out page designs in such a way that the user flow is clear, and the developer does not have to wonder about how the pages function.
• Add all element states to the design (e.g., provide an image of a mobile nav menu both when opened and when closed).
• Add a Typography key to the design docs with size, weight, color, and style changes for each type of text used on page
• Provide a color palette in the design doc and verify that the hex/rgb codes displayed are correct.
• Think about your overall styles globally, and design the mocks to match. Note those details in your design. This will enable your developer to style the site globally and only restyle smaller changes per component or page rather than having to write out styles over and over again throughout the site.

Make A Cohesive Project Plan:

• Use consistent naming across the design, written documentation, and in communications for site-specific elements. And if those names change, post an update to your developer ASAP.
• Outline the data structure for the site. You may know exactly how the data for a series of pages nests together (e.g. albums, songs, lyrics, & videos), but someone you’ve hired for a short window of time does not. The more they have to look up, ask about, figure out, or do on their own all costs time & money.

The Big Little Things:

• Provide all assets up front. For any that are still pending, alert your dev to what is missing and what the ETA is.
• Give pertinent information directly to your developer up front and upon request. The more your developer has to look up, ask about, figure out, or do on their own all costs money in addition to the actual costs of writing the code. This includes asking them to search through old threads or readme’s rather than grabbing the info yourself and sending it over.
• Establish the channels for communication up front, and stick to them. Keep it professional. If your project chat is all in Slack, don't text their personal number (especially if they never gave you their number!).

Hiring Developers From A Dev Community?

• Developers hired from a particular community are there for jobs using that software/framework/approach. For instance, if you hire a developer from a modern CMS software community, that means they are ready to build reusable components that pull data from the CMS to flesh out the pages. If you decide instead to hardcode the data and build bulkier pages & components, you are not getting the best out of your dev. In fact, you might be forcing them to do more & longer work for a lesser reward.
• That community is probably more closely-knit than you think! Keep that in mind before underpaying, bad-mouthing, or setting completely incorrect expectations up front about the project requirements. Your reputation matters, too.

Keeping The Budget Low?

• Simplify the design as much as you can. Every little bit extra adds up! Examples:
  • When re-sizing, keep your elements in the same order, the same colors, etc.
  • Conditional formatting of elements that you might be building into the design should be kept low or to zero.
  • Consistency keeps it simple and leads to a better design.
• Put copy in the data, not in the code. Dealing with copy in the code is nitpicky and adds time.
• And if your budget is so low that you cannot reasonably pay a developer or are inclined to negotiate them down far below their rate, consider the "no-code" options and hire a developer to build your custom site later once you can afford it. There's no shame in going this route.

Feel free to share this link or copy/paste the items that line up closest with your own project needs in your own communications.

Otherwise, I'd love to know your thoughts! Have you run into these issues with your clients? Have other suggestions to add to the list? Let me know in the comments.

Still here? Great! I'm trying to connect with more developers on Twitter so I can ask the questions and share quick insights and aha's as I find them. See y'all there!

Cover Photo by Visual Stories || Micheile on Unsplash