Day To Day Client Communications
Work with the garage door open
We know that building software is a process of iteration, and a lot of that iteration happens inside the web browser or mobile app during the development phase, not inside Figma during the design phase.
Whilst we do have a check-in call on most days, we've still found it very beneficial to seek feedback on tickets that have any amount of ambiguity as you're working on them.
What This Looks Like
What this means in practice: If you're working on a ticket and you're not 100% sure on some of the details, you should open a thread in Slack and ask the client for their feedback.
Be generous with details, make digesting and responding very easy
Try to put yourself in the client's shoes, give them the context, screenshots or context they need, and preempt information they might request or questions they might ask, so that they don't have to ask you and wait for another response. If the average response takes 2 hours, leaving out details can cause conversations that could have been a quick back-and-forth to lag into the next day.
Terrible:
"Hi Sophie I'm not sure how to do the search functionality"
Puts the onus on the client to figure out what task you're talking about. Not clear
Bad:
"I'm working on the search feature but I'm not sure about the user experience. Can you clarify?"
Doesn't specify which search, what specifically is unclear, or show options
Ok:
"Hi Sophie, I'm working on ticket #156 (product search on homepage). I'm not sure if the search should show results as you type or only after hitting enter. Could you let me know your preference?"
Identifies the specific ticket and component, asks a clear question, but doesn't show the trade-offs
Good:
"Hi Sophie, I'm working on ticket #156 (homepage product search) and have a quick UX question: - Option A: Results appear as you type (like Google) - about 2 more hours to finish - Option B: Results appear after hitting enter - about half a day to implement properly Both work well, just different time investments. Which approach would you prefer?
Shows both options clearly, explains time trade-offs, asks for direction
Great:
"Hi Sophie, I'm halfway through ticket #156 (homepage search) and want to check the UX approach:
Simple version: Results after hitting enter [Loom of demo] - 2 hours to finish
Fancy version: Results as you type [Loom of demo] - half day to full day
Both work great, just different time investments
Respond with 👍 for simple/fast / 👎 for fancy/slower"
Shows working demos of both approaches, clear time estimates, makes it super easy to choose
Slack over Asana:
We used to say "Keep all discussion on the ticket" but we've found that the benefits of being able to get real-time feedback (which organically happens far more in Slack than Asana) outweigh the benefits of imposing a strict "all comments on the ticket" policy.
Caveats
The biggest danger of working with the garage door open is that text chat is a very inefficient method of communication, and if you're not careful you can end up spending too much time in conversation around minor details, and not enough time coding.
The only way to combat this is to recognize that it will happen unless actively opposed. When noticing that further discussion needs to be had over video, we should lean heavily towards "let's talk about this on the call tomorrow" vs. "let's jump on a call now to discuss it."
Skills & Tools
Developers and non-technical team members should be using CleanShot and should be in the habit of: hitting the keyboard shortcut to grab a screenshot of a section of screen, annotate it if necessary, and then drop it into a Slack chat alongside a question. If you learn how to do this frictionlessly it becomes second nature and you can do it without taking yourself out of flow.
Wispr Flow is also brilliant for converting thoughts to nicely formatted text.
Last updated