Sending a Client Deliverable

You’ve spent all week gathering ingredients. Testing combinations, cooking techniques, and presentations. Satisfied with the result, you shuffle your new roommate into the kitchen, stick a spoon in their mouth, and… stare until they give a response.

Reactions range from shrug to “mmm” plus a nod. Not helpful, (typically) not genuine, and not what you’re looking for to drive the recipe forward — but the fault lies with the chef.

Asking for live feedback from a deliverable is the same as shoving a spoon in someone’s face. The right sort of critique takes consideration, and it should start in an environment separate from the creator.

The delivery is a bit of process that’s remained largely unchanged since Envy Labs began its foray into software consulting. We follow four steps:

• Start with a screencast.
• Follow up with a call, especially for the first delivery.
• Provide a means for in-place comments.
• Transfer to the source of truth.

Start With a Screencast

Crab is pretty great, but handing someone a crab leg for the first time may not leave them with your appreciation (or knowledge) of the meat inside.

While images can tell a story, we anchor our deliveries with a screencast — whether it’s for wireframes, design, or code, the format conveys reasoning without the creator being present. The first line of decision-making defense.

If you’re aiming for the client to actually watch the video, commit to a set of guidelines and a base level of production value. Our tenets include:

• Length: it shouldn’t rival an episode of a television show in length. At the very least, keep it information dense.
• Script: varies by the individual — it should sound natural, but with as few tangents, corrections, and ums as possible. I usually skip a script and record the second take.
• Streaming: upload the video somewhere that makes it easy to consume.
• Walkthrough: provide a quick demonstration of any applications you’ll be asking the client to use in the review process. Don’t assume they’ve used InVision, Marvel, or something similar in the past.

Bonuses

Screencasts bring a few handy bonuses in the software world. Many development tasks — tests, performance, refactoring — aren’t immediately visible in a staging environment, but can be highlighted as part of a video.

For longer projects, they serve as a library of decisions, checkpoints, and visualization of effort.

For designers, screencasts are a good way to reveal bits of unused or outdated work. Clients can be walked through the process, without offering up reviewable versions of old designs.

Best Paired With

Sending a video on its own can be counterproductive. We aim to include:

• Linked project documentation for decisions referenced.
• A separate list of all questions asked in the video.
• Expectation for review deadlines.

Follow With a Call

Assuming everyone taking part in the follow-up has seen the video (which is a useful check to kick the meeting off), we’ve shifted from a presentation to a discussion. Instead of taking time to introduce a solution and the inevitable pause for processing that follows, the focus is on clarification and feedback.

Timing the call after delivery will vary from client to client — everyone needs time to review what you’ve sent beforehand, but waiting too long means the information may not be fresh. We’ve had the most success in setting it within a week.

Taking critique is a separate post unto itself, but comments should be collated. Bonus points if you use the application you’re expecting the client to leave notes in as a method of reinforcement.

Collecting Comments

Two guidelines reign supreme in collecting feedback during and after the follow-up call:

• Have the client appoint a final decision maker to avoid competing critique.
• Seek to limit prescriptive comments (also a topic for a separate post). “This should stand out more” is more useful than “this should be purple.”

Reviewers need the means to convey two types of critique: contextual within the designs or wireframes (InVision, Marvel, etc.), and higher-order notes for the direction as a whole (we usually use Basecamp).

The Source of Truth

As decisions are made or changed, a single source of facts should be updated — the cookbook, if you will, to continue the random food analogies.

Sorting through old prototypes, videos, notes, and emails is a painful process for rediscovering a final feature choice. Whether it’s a ticket-based application, an issue tracker, or a wiki, ensure the responsibility is assigned for translating truth over.

Wrap Up

Screencasts are a great starting point for deliveries — everyone begins on a similar foundation for feedback and questions. Putting the effort in to create one, though, isn’t enough. Additional bits of process, including follow-ups, directed feedback, and a single source of truth are necessary.

This many food metaphors means it’s probably time for lunch.