Skip to content

Instantly share code, notes, and snippets.

Last active May 9, 2016
What would you like to do?

Project Starter

An outline for starting any new client project. This guide can also be used for internal projects by omitting or revising any client-centric bullet points.

Initial Setup Questions and Expectations

  • Does the client have their own development team? If so, define what languages they will mainly be developing in. Do they have any preferences on file architecture, coding practices or build processes? Do they have any preset expectations for frameworks (JS or CSS) that need adhered to or are they open to recommendations?

  • If the project is an application, define the smallest screen sizes that this application could effectively be used on. If an application is meant to be used on all screen sizes, keep in mind that some features and layout patterns would need to be revised for optimal small screen usage. Plan on setting up frequent (weekly) wire frame and design check ins to make sure that all screen sizes are being taken into consideration.

  • Define deliverables. We typically do not write application business logic and we normally deliver static HTML, CSS and DOM manipulating JavaScript (jQuery) to denote functionality and user experience. If there are any other deliverable expectations, define these up front and make sure they are in line with the SOW and do not fall beyond the scope of what our organization is equipped to provide.

  • Confirm browser support. Typically Latest Firefox, Chrome, Safari and IE10+ for desktop. Android 4.1 and iOS Safari 1 version behind for mobile.

  • Confirm device support. Will this be the project that a Windows Surface is the preferred device of choice? Probably not, but we can only find out if we ask...

  • Define level of documentation. Are we delivering a style guide, feature specs, formal code documentation as separate READMEs, or will in-line commenting suffice?

  • Are there any branding assets we can get up front? Branding guidelines, Typekit font access (if applicable), APIs and documentation that we might need?

  • Define method of delivery. BitBucket, GitHub, FTP, Zip?

Setup Environment and Initial Documentation

  • Install an instance of Corkscrew with the common mark-up patterns that are global to all projects (forms, typography, buttons, etc.). Use this as a means to showcase reusable patterns and will act as a guide for the designers to make sure they have designed all states of individual elements.

  • Configure any aspect of your coding style guide to accommodate for requirements that are unique to this project.

  • If applicable, create a performance budget for this project using. Here is an example of a performance budget.

  • Modify our Development Document to outline our process and deliverables in a uniform and easily digestible manner for the client.

Steps and Questions to follow and ask during the project

  • Review wire frames and designs with the team frequently (frequently be a relative term that should be defined by the project team). Identify elements or patterns that would require the greatest level of development effort and understand what the expected deliverables are for those pieces.

  • Have discussions about design and layout decisions that may affect accessibility and create abnormal DOM patterns. Try to work out plans to achieve the design and experience we are aiming for, while not having to write 'hack' code.

  • Do rights for any third party plug-ins, fonts or images need to be secured (purchased) by the client? Let them know sooner than later.

  • Define weekly tasks to meet internal and external expectations. Make these public as need be through GitHub issues, BaseCamp to-dos, or by other means defined during the project's life cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment