by Josh Branchaud on April 4, 2019

Every project is different and every client is different. That means communication and process can vary quite a bit depending on what you are working on and who you are working with. In over 4 years of working at Hashrocket, I've encountered some communication best practices that tend to work across this spectrum. In this post, I'll walk through the why and how of 6 of these best practices.

Communicating is hard. Asynchronous communication is even harder. Keep an eye out for email threads and Slack conversations that start to get out of control. Remember one of those conversations where you are trying to settle on the details of a complex feature or misunderstood bug? Once you've gone back and forth a couple times, you may notice people talk past one another or new scope getting exposed. You've passed a threshold. It is time to cut the back and forth and have a voice/video call to get things straightened out.

During this call you'll likely answer some lingering questions and uncover valuable information. Don't keep it to yourself. Make sure it gets captured in a document or your project management software so that everyone can learn from that conversation.

There is no better way to get your day off to a productive start than to make sure you are working on the right things. Let your client know what you were able to accomplish and what your game plan for the day is. If your plan is out of line with your client's priorities, this is your chance to course correct. If you and your client are on the same page, then you can have confidence in moving forward and your client can be assured that this process is moving them toward their goals.

Stick to these daily standups and keep them brief. Once you start skipping days, it is hard to recover the routine and that shared sense of alignment will take a hit. If these meetings aren't kept brief (10-15 minutes), then the purpose becomes lost and they can become burdensome or frustrating to attend ("how long am I going to be stuck in this?"). Standups running long is also a sign that a topic or question is in need of more extensive conversation — take it offline or schedule a different meeting.

Whether or not your meetings have a fixed agenda, you know when a particular point of conversation has started to go down a rabbit hole. If you have a lot of people in a meeting, these tangents can have a measurable, and sometimes significant, cost. These tangents can also have an indirect cost. If there is pertinent information that needs to be disseminated amongst a group of people, or if there is time-sensitive feedback that you need from everyone, then these tangents can prevent that communication. As soon as you find that a particular conversation is headed into the weeds, stop for a moment. Find out if this is a conversation that needs to happen now, with all of these people. If it isn't, then suggest that it is taken offline. In fact, you can even take this as an opportunity to identify who needs to be in that offline conversation.

When you first start discussing a feature or bug, it is easy to talk at a high-level. In fact, it is often necessary in order to provide the context that brings everyone in. You eventually need to move past the hand waving and imprecision. The software you write needs to be precise and so do the specifications. User stories can help capture the necessary precision.

Find what works for your team, but I highly recommend using the 'Given/When/Then' style. This prescribes that you define preconditions for the feature ('Given'), interactions the user will have with the app ('When'), and postconditions that can be verified as a result of the user's actions ('Then'). Stories written in this way remove ambiguity about what needs to be done. This makes your job as the developer easier. It also provides clear acceptance criteria for the client to determine if the implementation hits the mark or not. Plus, all of this is focussed on the user who will be using this software at the end of the day.

Screenshots are a visual tool that can enhance asynchronous communication. If you encountered a bug in the web interface, take a screenshot and upload it with the bug report. If you have an idea about how to reposition an element in that form, do a quick mock up, take a screenshot, and then include it in your proposal. A good screenshot can preempt a variety of questions and ultimately cuts down on some of the back and forth.

If a still-image screenshot is good, then a moving-picture gif is better. You can convey a lot of information by quickly putting together a gif. In fact, the interactive nature of modern UIs often requires a gif. You aren't just building screens, you are building interactions. First impressions matter, so if you really want to sell your client on a new interaction, give them the full effect with a gif that shows off what you are proposing. If you've encountered a tricky bug, you can show reproduction steps with a gif. This is a two way street. Encourage (and teach) your client to do the same — this will make bug hunting go way faster.

There are many options for capturing gifs, Giphy Capture for Mac is my favorite.

These six practices have served me well across many client engagements. I encourage you to give them a try. I think you'll find that they help you build trust, rapport, and effective communication patterns with each of your clients.

Cover photo: rawpixel