Technical delivery document

Over the years I’ve been lucky enough to work on lots of build projects, during which time I’ve learnt that one of the most crucial parts to any build project is communicating with the client (and their dev-teams) the way in which we work and what to expect. Web development moves pretty fast – one day you’re writing simple HTML and CSS and the next you’re using SASS, Jasmine, Grunt, ARIA… the list goes on. So, we don’t expect the client (or even their dev-teams) to be up to date with all of the technologies we use on a daily basis. This is why we now send our clients’ a Technical Delivery Document (TDD) at the start of each project.

The Technical Delivery Document is designed to aid the client’s understanding of the way we work and what the outcome is on the end user. This certainly isn’t something new in the industry but we felt it was beneficial to try and communicate our approach at the start of a project and better manage the client’s expectations at the same time. The approach detailed in the TDD is by no means set in stone and therefore gives us an opportunity to discuss and change our approach, where necessary, to better meet the client’s needs.

So what exactly is in this document?

For us, it outlines the various specifications we follow, the tools we use and contains a few examples of how this might affect the user. For example, our Front-end development document (we have TDDs for back-end too!) details:

• Our approach to responsive design;
• What technologies are used (e.g. HTML5, CSS3);
• The specification we follow (e.g. HTML5, WCAG 2.0);
• Tools used as part of our process (e.g. Grunt, Bower);
• Any 3rd party libraries used (e.g. jQuery, Modernizr);
• What testing we carry out (e.g. Jasmine, cross-browser);
• What effect our approach might have on the user’s experience AKA “Today’s web”.

All of the topics we cover are intended to inform the client and/or their dev-team, before we begin a project, as to the way we work. The tools and libraries aspect is predictable if you are a developer, but it is useful to be specific about it, just in case there are any legacy libraries the client needs to continue supporting (e.g. a specific version of jQuery, or if they want to be library free). 

Today’s web

Quite often the decision makers involved in a project are, understandably, not up to speed with the more technical aspects of how the web or browsers work. For that reason we include the “Today’s web” section. This section is designed to explain what impact our approach might have on the user experience of the site. For example, we illustrate rendering differences in the browser for things such as web fonts and form elements as well as answer those classic questions like “Where are my rounded corners?” or “Why does it look different in Internet Explorer 7?”. And yes, we do have clients who use IE7!

Why do this?

As mentioned, there are several reasons why we are doing this for our technical projects. Firstly, it is to try and set the stage regarding our technical approach. Very few development teams take exactly the same approach; so we try to explain ours in the hope that it better communicates what to expect from us. Secondly, it is to try and help manage the client’s expectations early in the project – the more we can communicate at the start, the easier it is for the client to make informed decisions when it comes to deciding if they really need those rounded corners in IE7. Finally, by documenting our approach, the Technical Delivery Document can be used to define a standard and steer any work carried out on the project in the future.