Invo Playbook

Guide for all Invo'ites

Table of Contents


Code of Ethics

Speak the Truth. We tell the truth to others, with the intention of trying to do the most possible good.

Make the World Useful, Beautiful and Delightful. We exercise the discipline required to produce ideas and things that are useful and beautiful in the world.

Learn, Share & Build. We are curious, open creators who welcome new ideas and the input of others.

Be Vigilant. Identify and respond to inequality, protecting and serving the ideas, communities, and people in our world.

Go Like Hell. We are driven and committed to what we do, putting in extra effort in our quest for exceptional results.

Tangible Targets

Studio citizenship is founded in the Code of Ethics and is expressed through these actions (and many more). These are the practical asks that we have for you; learn, use, and evolve these tenets.

1. Work

Provide remarkable service to your customer and your team. Meet your deadlines. Keep your promises. Respond to client communication within 2 business hours. Your clients should never be treated as uneducated patrons. They’re usually smarter than us.

Focus your focus. Sharpshoot and prioritize! Don’t divide your attention between too many things, you lose focus and direction.

Know your numbers. Know the cost of projects and the studio operation, track your time, and make informed decisions.

Don’t stop moving. Don’t just talk about ideas in generalities. Even exploratory conversations should end with concrete next steps. The amount of energy to keep something moving is far less than the amount of energy to get something off the ground. However, if it isn’t to be, be humane and kill it quickly.

Take small bets. Risks are a form of experimentation. Test your idea and study the results. What worked? What didn’t? Repair it, refine it, and then try again. The more tests you do, the more material you have to work with and the better your chances are for success. Implement your experiments in the real world.

2. Culture

Staff as entreprenuers. Take an ownership mindset. Lead. Set goals. Cultivate side projects. Challenge yourself — if you’re not challenged you’re not growing. Propel the studio mission — always keep the big picture in mind and look for opportunities to make the studio better.

Everything is a design project. Communicating with your client is an opportunity for design; think about how you interact with clients, why you are doing it, and the potential impact. The studio is an experiment! Be a part of its evolution.

A policy of openness. We believe that making all aspects of our business open promotes trust and better decision making among our staff. At the studio, transparent data means you have the power to participate in the studio’s direction. With clients, open information leads to trust and stronger relationships. Supporting and creating opensource software democratizes the creative process and eliminates barriers to innovative content. Be open and share with others — it’s how we all grow stronger collectively.

Publish or perish. Print out your work. The physicality of having your work in the real world, instead of just living on your computer, allows you to see your designs more clearly and track the maturity of your creative process. Make it as accessible as possible! Open up for others to see and absorb their feedback. Revel in the free advice and ad hoc collaboration that comes with visibility.

3. Growth

Build and evolve your skills. Try new things. Accumulating a variety of skills adds to your creative arsenal, enables you to collaborate effectively with others, and helps you become a more well-rounded individual. Don’t be afraid to ask for help when you need it.

Find a mentor, be a mentor. Pair coding, pair designing, and group critiques increase the flow and exchange of ideas, amplify the quality of our output, and raise everyone’s design IQ. Give a tech talk, create artifacts, and share your knowledge.

Actively develop your own vision. Find the work that you are meant to do. Don’t accept Spaceship Earth as is — it needs your activism, ideas, and vigilance.

Bring in new work and new talent. Find or create at least one job opportunity a year. Help hire others who are better than you.

Be afraid, just a little. New paths can be daunting, but that’s where discovery and excitement are born.



Old Staff

First Day

Old Staff

New Staff

By Week 3

New Staff

By Month 1

New Staff, Group Leader, and Creative Director


New Staff



Begins with a signed Statement of Work (SoW) from the client.


If you haven’t been a part of the sales process for the project then review the SoW and discuss the project with the Sales team to understand the background of the project and client.

Spend 2 hours doing the following research to understand the industry, business, and team:



Create an email listserv for the Invo team working on the project. Format should follow An example is Setup listserv with Google Groups. An admin of the Google Business account will need to set this up. Just ask if you need help.

Add project to StaffPlan. Check if the project already exists in StaffPlan, sometimes we’ll do pre-planning of staff prior to a signed Statement of Work (SoW). Add all team members for the project and their planned hours for the duration of the project. If the client does not exist, then add the client.

Setup Slack channel for the project. Channel name should follow proj-client-name. An example is proj-dataxu.

Setup dropbox for internal team following this structure. Dropbox example.

Two Weeks before Kickoff

Schedule kickoff date(s), times, and location with the client.

Craft the kickoff agenda.

Tuesday, 3p - 5p

* Team intro
* Organizational background
* 3 most important organizational goals
* Review SoW, 5m

Service Overview
* Where Triliant is now, where Triliant wants to go in 6m/1y/5y.
* Where is the Kala software now, where it needs to go in 6m/1y/5y.
* Review survey responses.

Product Vision
* Business objectives for people, for retailers.
* Rules of Kala Citizenship
** Demographics
** Roles and use cases
** What drives becoming a Kala apostle?
* Key screens walkthrough
* If you could communicate a singular message about this project, what would it be?
* How do you want people to react to your product/service? Core values, design principles.
* Competitive landscape.

Wed, 9a - 12:30p, additional time if needed till 2p

Features + Functions
* Basic mapping of key features, workflows
* What's in v.02, v.03
* What's out, identifying constraints
* Concept sketching

* Current service architecture
* v.02 plans, stack

Aesthetics, Loved Experiences
* Examples you love
* Graphic design favorites

Measuring Success
* Buyer, Retailer, business, project success = ?
* In 3 + 6 months, what do we have?
* In 1 + 2 years, where are we?
* Goals, Challenges
* Instrumentation (how are we gathering data, evidence-based design)

Evolve SoW, short term deliverables, next steps
* Next week, next 3 weeks
* Communication, project plan
* How we design together, critiques, meetings
* Feedback loop with customers?

For shorter kickoffs, here’s an abbreviated version:


Company / product background
* Tell us about your company, its history, its structure.
* Tell us about your system, the audience you want to reach and the goals you want to help them achieve.

Product suite
* The ins and outs of the poroduct
* System relationships
* Where to focus efforts in the project

Short and long term goals
* Where you want to be at the end of this project
* Where you want to be five, ten years down the road.

Project overview, vision, design priorities 
* Solidify key priorities for the project. 
* Sketching may be involved.
* Share examples, inspirations, and aspirations.

High level product architecture exercise
* Identify user base, roles and common workflows
* Design priorities for this project
* Key screens/areas in the application
* Define technology used, constraints, requirements.

Schedule of work
* Project roles
* Project schedule
* Logistics, meeting times and places

Send kickoff agenda to the client.

Subject: Kickoff Agenda, <dateTimeKickoff>


Here is our agenda for the project kickoff.
If you have any thoughts or edits, let us know.

Also, we have a survey we'd like you and your team to fill out prior to kickoff. We'll send the details over on <insertDaySent>.




Send client and stakeholders the Kickoff Survey and ask for this to be completed within 2 days. Make sure you’re sending this enough in advance where we’ll have time to review the responses prior to kickoff. Here is an email template to send to the client. At this point, you may not know all the stakeholders, so sending to the client lead and asking to distribute to their team is fine.

Subject: Project Survey


We’d like to hear each person's perspective on the project prior to kickoff and then refine that into a single message during the kickoff.

Can you and your team individually fill out this 7 minute survey by <insertDeadline2businessDaysIdeal>?


One Week before Kickoff

Create Basecamp project. Project name should follow ClientName: ProjectName (ex. DataXu: Forecasting). An admin of Basecamp will need to set this up. Just ask if you need help.


Get familiar with handling invoicing for the project.

Subject: Invoice #<invoiceNumber> Involution Studios / We Create Goodness LLCs


Please see attached Invoice #<invoiceNumber> in the amount of $<invoiceAmount> for <nameOfService - example design consulting> on the <nameOfProject> Project. This is the <currentNumberInvoice> of <totalNumberOfInvoices> invoices you will receive for this project. Payment terms are net 30 days upon receipt of this invoice. 

Please make checks payable to our parent company, We Create Goodness LLC, EIN #<insertEINNumber).







Send message to client about communication channel. If we’re using multiple lists, Slack, or Basecamp, then outline that in the message.

Subject: Project Comm Channel


We've put together an email list for contacting the Invo team. 

People on this list are:

Please use this list to keep the Invo team in sync.


Send kickoff notes to client within 24 hours. This can be posted on Basecamp.

Subject: Kickoff Notes, <kickoffDate>


Here are our notes from the kickoff.




Send schedule of deliverables to client within 24 hours. This can be posted on Basecamp.

Subject: Schedule v01


Attached is the schedule for the project.

Our weekly rhythm for reviewing the latest deliverables is:

<day>, <timeWindow> @ <location>

Our first meeting will be <date>.


Invite all stakeholders to Basecamp project. Add Invo’ites to Our Team and client team to The Client.

Identify appropriate billing contact and send out first invoice.

Weekly Meetings


Meet once a week. Face to face is preferred. For remote meetings, use your preferred communication channel: GoToMeeting, Google Hangout, Skype, Phone. Duration: 1 to 1.5 hours. Adjust as needed.


Post deliverables on Basecamp 2 hours prior to meeting or the night before. Some clients review the deliverables in advance and come to the meeting already with feedback. Others use the scheduled time during the meeting to review the latest deliverables. Adjust as needed. Message structure on Basecamp for deliverables:

If meeting face to face, then print the deliverables using the large format printer and bring to the meeting. Printed deliverables are helpful for everyone to circle around, discuss, and mark up with feedback. Often, clients will hang these posters in their office for the entire company to have visibility into the design, see progression, and mark up as well. Writing feedback on printed deliverable Passerby feedback in client office

Meeting Agenda Template

  1. First 5 minutes: Overivew of what you’ll be reviewing and what you’d like to get out of the meeting.
  2. Next 50 minutes: Review designs, receive feedback, ask questions.
  3. Last 5 minutes: Summarize what you heard during the meeting and what you’ll be working on for next week.

Post Meeting

Immediately document your notes and post to Basecamp after the meeting. Message structure on Basecamp:


Take photos of the team and client engaged a few times throughout the project. These will be used to document the project and possibly for marketing.

Project Assessment

Done by the project lead

For each quarter of the project completed, at the end of the meeting do the following with the client:



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



Before the End

At 75% Completion of the Project

Hi all,
As we discussed today during our meeting, this project will be finishing on Friday, December 18. We will have our final meeting on December 16.
Based on the feedback from today's meeting, here is how we will focus during this last 4 weeks.

* Task 1 discussed at meeting
* Task 2 discussed at meeting
* Task 3 discussed at meeting.

Please let us know if you have any questions.


One Week Before the Project is Complete

Hi all,
We will be posting the final deliverables next Wednesday, and we are available for a wrap-up meeting next week Monday, Tuesday (except 2-3), or Wednesday.

As we have discussed, for the final deliverables, we will be providing:

* Style and functional guidelines in context of the component breakdown
reviewer and submitter workflows
* Final pngs and a link to final PSDs (most likely to large to post)
* Prototype code for the with 3 scenarios we outlined

Let us know your availability for a wrap-up meeting next week. 

Thank you, 

Generally, the deliverables for the project are outlined in the Statement of Work (SOW). Here is the common list of deliverables and formats.

For Design Projects:

For Projects involving Code:

On the Final Day of the Project


Our engagement with ACME ended last week. This week we were finishing up a Web Based User Interface Design Guide for ACME. The design guide is made up of 3 sections – Principles, Process and Examples. 

To close out our engagement, we have included all the final deliverables in a dropbox folder that includes the following:

* Prototypes: The code for the prototypes we developed during the engagement.
* Web Design Guide: The HTML and CSS for the design guide we prepared.
* User Reearch Report: including all of our findings from the user research.
* Product Ecosystem diagram 
* Screen designs which we have delivered throughout the engagement

Thanks and we look forward to working with you again. 

Web-based User Interface Design Guide can be found at: 

Final Deliverables Dropbox folder: 



Tasks for the Team

Tasks for the Lead


We'd like to get your honest feedback on how Invo did for the project.  
Can you fill out this 5 minute survey by tomorrow?

Today we are wrapping up our latest gig with ACME Corporation.

Reshma, Eric and I started working with ACME at the start of February and we've had 2-3 people working on research, design, prototyping, and production code for most of the time since then. 

In the first part of the engagement, Eric led an effort to help ACME re-envision the future of their platform and identify an approach for a scheduled rollout which will take place over the next 2-3 years. To help validate the design and sell the new vision internally and externally, Ivan and I built a series of prototypes which they are still using today to sell their future to important customers.

Danny and Michael began work on in July on the first set of production code. In addition to executing on the design vision, they have worked with ACME to define the next technology stack(Angular as a client side MVC separated from their API server) that will be used on all their future UI development. They did a good job of involving the UI dev team in the large architectural decisions. Despite the project being understaffed from ACME's side, Michael and Danny were able to deliver a top-notch experience.

Feedback on the new screen from some of ACME's bigger customers has been very positive thus far and the Product team is very excited about what this new screen will provide. Additionally the team we have been working with have universally echoed the sentiment that this project has been one of the smoothest that they have worked on.

Here are links to a few videos of the app on the demo environment. I have also attached some screenshots of the before and after.
[Link 1]
[Link 2]

Congrats to all that have been involved with ACME over the last 8 months.



Version Control

Involution frequently develops software as part of a client engagement. This might be code for an internal project, a prototype for a client, or production code for a client. Using version control is a studio requirement for any project involving software development

Before Creating a Repository

There’s a few things to consider before creating a rpository. Primarily, based on information from early meetings and interactions with the client, we need to determine whether the code lives in one of our repositories or needs to be in theirs.

Client Hosted Version Control

If you are working with a client, ask the client if they prefer that we use their version control system (VCS). A client may need us to work with their VCS due to the proprietary nature of their software, privacyobligations to their clients or members, or myriad other reasons. If this is the case, follow up with the client contact on how to gain access to this system, any documentation they may have on their VCS or process, and possibly a good time to get a walkthrough of their process. In this case, the client will need to create a repository for us to work with.

Invo Hosted Version Control

If the project you are working on is internal or the client does not request that we use their version control system, we will use a git repository hosted at Github. This should be our preferred way of working, so we can offer a consistent experience from client to client and project to project.

Some other useful questions to ask up front include:

Creating a Repository on Github

Github has some good documentation on how to create a repository. Here are a few things to note.

(If you’re using Github for Mac you can use CMD+N and proceed as outlined at the URL above)

Private vs Public

Because of Involution’s commitment to open source software, we default repositories to be public whenever possible. When working on an internal project, quickly double-check with the powers that be whether it is okay to make the repository public. Always check with the client before creating a public repository on their behalf.

Open Source Licenses

If the repository is public, make sure to include a License. We generally use Apache 2.0, but check out this site from Github for some help.

Naming Conventions

When naming a repository on Github, make the name Pascal case (camel case with the first letter capitalized).

Client Repository Names

The repository name should start with the client’s name and contain their product name (when relevant) as well as the project. Below are some examples:

Internal Project Repository Names

For projects that are owned by Invo, it is not necessary to include Invo in the repository title. In this case, give the repository a name which describes the software as a product. For example:


Git Workflow

Branching and Merging

We generally model our branching and merging strategy for projects off of the model outlined in this article. Unless you have a strong reason to deviate (i.e. a client prefers a different workflow or you aren’t using git), you should probably use this workflow.

Releasing Source Code

Whenever you release source code to a client, or push it to a production server, you should tag that release in git. It is tedious to tag releases, but it is almost always a good idea. If there is some sort of additional work done as part of a “release” (i.e. adding .mobileprovision files or packaging an iOS application as an IPA), use the release functionality of Github to upload those extra dependencies.

Evaluating APIs

These are some things we should check for when reviewing APIs to provide feedback.


Request/Response Data Structure

API Functionality


Tips on Communication

Other Useful Tools

Validating APIs

When developing and debugging API based applications it is sometimes useful to test the API independent of the UI codebase. There are a few tools which help make this possible:


Postman provides a free Chrome extension which lets you execute HTTP requests from your browser. At its core, it is an in-browser wrapper for curl. A few things to note that makes Postman especially powerful:

If you are having trouble making an API request within your application, it is useful to try to test it from Postman. This can isolate whether it is an issue with your code or an issue due to CORS configuration.


Charles is a cross-platform HTTP monitor and proxy. It will capture all network traffic on your computer and allow you to inspect the individual HTTP requests that are being made by your application. A few notes:

Chrome Developer Tools

I find that the Chrome Developer Tools are feature rich and friendly than the Safari or Firefox developer tools. There’s a bunch of documentation online about how to use them.

Creating UML Diagrams

A UML Sequence Diagram is worth a thousand words (or an hour on the phone). They can very quickly show high level concepts of communication as well as surfacing the details. UML Class diagrams are also really useful for showing relationships between objects.

Formatting and Validating JSON

Scraping Data from Websites

Sometimes, you might want to scrape data from a website or web request to look at it more closely. Here are some techniques for doing so:


Determine the Purpose

When starting to work on a prototype, it is important that the client and the Involution team are clear on the purpose of the prototyping endeavor.

Based on the purpose, you need to take different approaches.

Goal A: Validate and Improve the Design

If your goal is to validate and improve the design, it is important to focus on rapid iteration. There is a lot of value in prototyping as part of the design process. It forces the design team to think about micro-interactions (i.e. hover states, transitions, labels) that they might have overlooked while designing on paper. It also lets you experience a design in its native format. Some designs that looks great on paper fail horribly when they start living and breathing.

If the goal is really to let the design team (including the client’s core team) validate and iterate on the design, then the prototype might not need to be as polish or as complete. For instance, if evaluating a workflow, you might not need to implement each of the steps in order to evaluate the success or failure of the design. In some cases, though, these steps might be critical to evaluating the success or failure of a design.

Some of the best prototypes in this scenario have razor-sharp focus on specific areas of functionality. You can save a lot of time by building a bunch of small prototypes rather than one large prototype.

Goal B: Sell the Design to Customers or the Organization

Oftentimes, a client needs help communicating the new design throughout their own organization or to their customers. Prototypes can be a great way to achieve this. In some cases, our clients’ sales teams have used our prototypes to sell the future of the product while the production system is still in development.

When building a prototype with the goal of the client using it for demos to customers, it is critical to work with the client to define the story or stories they will tell while using the prototype. When scoping the prototype, the story will be used to decide what is critical to nail, what can be faked, and what doesn’t need to be included.

Goal C: Identify Technical Feasibility

If your goal is to test the technical feasibility of a design (or a portion of a design), it is important to make sure you have a good understanding of what the final technology stack might look like. Is there an API? Is it a native application? It is going to be built in the style of a single page application?

Determine the Scope

It isn’t possible to prototype everything and rarely does it make sense to. You should be prototyping for a purpose.

Technical Questions

General Rules

Common Pitfalls

Incorrectly Attributing Feedback

Sometimes clients (or Invoites) see a prototype that is a bit laggy or doesn’t quite feel right and take it as a failure in the design. When incorporating feedback from a prototype, it is important to understand the root cause of the feedback. For instance, if someone is having trouble using inline editing, it could be because inline editing doesn’t make sense in this context or it could be because the specific code implementation of the inline editing isn’t right. It is easy to incorrectly evaluate feedback on a prototype and end up making bad design decisions.

It isn’t that the feedback isn’t valid… it just indicates where a little more attention might need to be focused. For instance, if the feedback loops (for submitting items) feel laggy in a prototype, it might mean that you need to pay more attention in how the saving of items is handled in the production application.

Mistaking the Prototype’s Performance for the Expected Production Performance

Focusing on Details that Don’t Matter

The scope of prototypes can explode if you focus on details that don’t matter. When you are building a prototype, you need to constantly ask whether what you are working on adds value towards the goal of the prototype. If it doesn’t, it might not need to be implemented or it might be able to be faked.

Not Enough Technical Architecture

You don’t want to spend too long on technical architecture for the prototype, but if you don’t spend enough time you will find yourself with a fragile and stapled together system which is hard to maintain. Some common pitfalls with this:


When someone is evaluating a design they use the data as well as the design elements in the screen to understand the design. As such, it is important that your prototype contains real data which tells a story.

Properties of Real Data

In your prototypes it is important to use real (or at least realistic) data. The best option is to have get real data from the client. In cases where this isn’t available, you can craft a dataset.

At the most basic level, consider these:

Some Techniques

InDesign DataMerge

Adobe InDesign (and Illustrator) have a feature called DataMerge. It allows you to turn a design file into a template and batch generate InDesign files with the data provided in a CSV file. These files can be linked to other designs (using the Place command) or exported as images.

In javascipt, you can then do something like this:

//Assume we've placed our generated images in images/ directory.
var i, html;
var numItems = 150;
for(i=0; i<numItems; i++){
	//Better to use a real templating language.
	html = '<div class="singleItem"><img src="images/item_'+i+'.png"></img></div>';

Then you can add some interaction with some CSS


You can also add some javascript interactions. Assume that we also exported item_expanded_1.png, item_expanded_2.png, etc. When we select a row, we want it to expand.

A Mustache template:

<script type="text/html" id="rowTemplate">
	<div class="singleItem" data-expanded="no">
		<img src="img/item_{{num}}.png">
		<img class="expansion" src="img/item_expanded_{{num}}.png">

We can populate it for our 150 images like so:

var numItems = 150;
var i=0;
var allObjects = [];
for(i=0; i<numItems; i++){
	//Make this an object so we can add more properties in the future if we want.
var template = $('#rowTemplate').html();
var generatedHTML = Mustache.render(template, allObjects);

	var isExpanded = $(this).attr('data-expanded') === 'yes';
		//We are expanded already, so let's close it.
		//First, close everything else.

		//We aren't expanded, so let's open it.

Add a bit of CSS

.singleItem[data-expanded="no"] .expansion{
//Don't show the expansion image if we are not expanded.

Now, we’ve built an expandable table with only a few lines of code. You could even add a CSS transition to make it animate on expansion.

File Management

We use Dropbox so backups are automated, file-sharing is easy, and all of our work is accessible to the entire organization.

Default Project Directory Structure

When starting a new project, use this dropbox structure as your starting point.


Every project we work on exists here. Any documents you place here are visible to the entire organization.

Contains all the projects for a specific client. You’ll be working inside of this directory.

All material received from the client. It’s helpful to place documents received via email, basecamp, etc, in Dropbox for a central location for all.

Any information from the client to understand the business, industry, product.

Any research provided by the client.

All material created by Invo.

All material we’ve delivered to the client. Typically PDFs, but can also include spreadsheets, PSDs, prototypes, and other documents that make sense.

All files used to create our deliverables. Typically InDesign, Photoshop, Illustator, Omnigraffle, Sketch, Keynote, or other files used to create. Prototypes could also live here if for some reason storing on Github doesn’t make sense.

Any research Invo has done.

Use subfolders at your discretion if you’re needing another level of organization than the default structure provided.

Good Project Directory Example

Using project directory template. Files in logical location. Design documents are logically named and versioned.

        401-Tech Training IV - Smartphone - Mobile Health Manager.pdf   
        Care4Today Mental Health Solutions-for overview with Involution.pptx  

Multiple Projects Directory Structure for a Single Client


Use a logical name that defines the project.

Multiple Phases Project Directory Structure


Rarely needed. Use your discretion. This can be flexible for phases or weeks.

Filenaming Convention

Minimally use for our production files and deliverables.

clientname + _ + projectname + _ + descriptive_deliverable_name + _ + v + versionnumber

Each piece of the name is connected with an underscore _ and is written in lowercase. A version number should look like v01 and not v1. It’s acceptable to append _draft after the version number if it’s an incomplete document.

Good Example:

Bad Example:

Invoice Directory Structure Example


If there are multiple projects for a client then create separate project folders and group invoices in their respective project folder. Optional: If we’re billing for any expenses (ex. Travel, Equipment, Software) then create an expenses folder and place in any receipts. For visits to a clients office, create a sub-folder (ex. trip-2Nov-5Nov) within /expenses for each trips expenses.

Protected Health Information

As many of Invo’s clients are in the healthcare space, it is important to be aware of restrictions related to handling Protected Health Information (PHI).

What is PHI?

US law has restrictions about how Protected Health Information in general, and more specifically how Individually identifiable health information, can be transmitted.

Health Information

First we must consider the definition of Health Information.

“Health information means any information, whether oral or recorded in any form or medium, that–

(A) is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and

(B) relates to the past, present, or future physical or mental health or condition of any individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual.”

From the Health Insurance Portability and Accountability Act of 1996: Administrative Simplification, accessed via the HIPAA website (emphasis added by Invo)

Note that this is a very broad definition of what consitutes health information. Just about anything which can be related to health is considered Health Information.

Individually identifiable health information

HIPAA Also defined Individually identifiable health information. In particular, HIPAA states that this is health information which also meets the following criteria.

(i) That identifies the individual; or

(ii) With respect to which there is a reasonable basis to believe the information can be used to identify the individual.

From the Health Insurance Portability and Accountability Act of 1996: Administrative Simplification, accessed via the HIPAA website (emphasis added by Invo)

The key point here is that the information does not have to specifically name the person to be individually identifiable. For instance, a piece of health data with an address (but no name) is still considered to be individually identifiable and therefore Protected Health Information.

Working with PHI

PHI may not be transmitted unsecured over the internet or stored on unsecured devices. Involution has the following specific policies that you must follow when working with PHI:

Personal Health Information CANNOT be uploaded, sent or transmitted to any person or service. So the following cloud based services CANNOT be used with personal health information…

Generally, a client which works with PHI will have specific policies and training on these policies. This might include tools which can be used to transmit PHI (such as secure e-mail)

Review this developers guide to HIPAA compliance and application development for more information.

Checklist for Starting a Project involving PHI

De-identifying PHI

It is possible to de-identify PHI so that it may be transmitted and stored. HIPAA provides guidelines about what must be changed for PHI to be considered de-identified.

(A) Names;

(B) All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code if, according to the current publicly available data from the Bureau of the Censue:

(1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and

(2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000.

(C) All elements of dates (except year) for dates directly related to an individual, including birth date, admission date,, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;

(D) Telephone numbers;

(E) Fax numbers;

(F) Electronic mail addresses;

(G) Social security numbers;

(H) Medical record numbers;

(I) Health plan beneficiary numbers;

(J) Account numbers;

(K) Certificate/license numbers;

(L) Vehicle identifiers and serial numbers, including license plate numbers;

(M) Device identifiers and serial numbers;

(N) Web Universal Resource Locators (URLs);

(O) Internet Protocol (IP) address numbers;

(P) Biometric identifiers, including finger and voice prints;

(Q) Full face photographic images and any comparable images; and

(R) Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section; and

From the Health Insurance Portability and Accountability Act of 1996: Administrative Simplification, accessed via the HIPAA website (emphasis added by Invo)

Note that the above fields apply to the individual described in the data as well as relatives, employers and household members.

From the above list, it should be clear that it is not sufficient to just remove the name from PHI to make it de-identified.

HIPAA also specifies restrictions around any re-identification code (i.e. an ID that can be later used to re-apply the personal information associated with the PHI).

More Resources