Naming Deliverable

At the bottom of every document, include the client name, project name, deliverable name, version number, Invo team names (alpha order of last name), date (format 19.Feb.15 which InDesign automates for you using the documents last modified date), and Invo logo. Naming a document

Numbering and Naming Screens

If there are multiple screens or ideas within a page then each screen or idea should be numbered and named appropriately. Numbering helps people identify which comp to look or are referencing on the page. Naming helps people understand what that comp is generally about. Numbering and naming screens

Annotating Screens

It’s helpful to annotate your documents so others can understand the details behind the images and to guide people through the workflow. Annotating a document

Comp Template

This Adobe InDesign template includes the styles (paragraph + object styles) to mark up deliverables: labels, annotations, and branding. Download InDesign Template

Common Deliverables


Project Proposal

Project proposals are sent to a potential client we’re in discussions working with. The proposal provides background on the company, the team, and what the design process and schedule could look like for the project, and cost. The proposal starts the conversation to refine the engagement and ultimately create a Statement of Work (SoW). PDF Example 1

Statement of Work (SoW)

The Statement of Work outlines our engagement with the client. It describes what the project is about, the weekly schedule, deliverables, team size, and cost. To begin the project, the client will need to agree to and sign the SoW. Doc Example 1



Every project has a schedule and should be roughly based on the Statement of Work: goals and duration. During the kickoff is where the schedule should be finely detailed with the client. It should state clearly what is delivered each week until the end of the project. PDF Example 1

Project + Product Spec

Describes the project and product in a short 1-2 pager. This document has 3 main sections: Vision, Background, Goals. Each section has a specific description for the project and product.

First draft is created based on the client kickoff survey responses. During the kickoff we’ll use that draft as a converstation starter to flesh out a v01 that all stakeholders agree to. This guides our purpose throughout the project. This is subject to evolve over time, so this document may need to be revised. PDF Example 1 | Pages

Product Questions

PDF Example 1


Market Research


Needs Map

PDF Example 1 | Illustrator

Pixel Perfect Comps

Exact perfection in UI details. These comps will provide guidance and the assets for a UI Engineer to align the software with. Whenever handing PSDs to others, make sure the layers are appropriately named and organized. PSD Example 1 PSD Example 2


At times, we create specific presentations tailored to the clients needs. Sometimes we present to key project stakeholders, clients customers, or the entire company. PDF Example 1: Project Progress Summary | Keynote

Process Map

Maps out the process of the service. This could map out all parts of the process, even if we’re not designing it, because we should know the entire lifecycle of a person using the service. PDF Example 1

Product Ecosystem

Inventory of all the clients products plus their relationships and overlaps between products. PDF Example 1

Product Blueprint

PDF Example 1


A demo of part(s) of the software we’re designing. Highly iterative. Each prototype should have a clear intention to test. Prototype formats can vary based on needs but can be: Keynote, Flinto, HTML, Native. TBD

Production Code

Using our designs, we’ll work with the client to develop the new software. TBD


Sometimes we’ll share our sketches if we’re looking for quick feedback and have not yet started to digitally create the concepts. PDF Example 1 PDF Example 2

System Diagram

High-level architecting of the main components of the service, relationships, and actions. PDF Example 1

UI Workflows

Many of our deliverables are UI Workflows. These show the screens, how people will use the software through a series or screens, and any details to describe the experience. PDF Example 1 PDF Example 2 PDF Example 3

User Research Report



Implementation Analysis

Details an estimated effort to build the design we’re working on. Includes amount + type of people, time, and releases. Typically created towards the end of the project where we’ll have a good sense of the product. This exercise takes about 2-3 days internally and then we’ll review with the client and their engineering team. It’s expected to have a revision or two based on feedback. PDF Example 1 | Keynote PDF Example 2 | Keynote

Technical Recommendations


Validation Process