Planning the production of an interactive project
Posted on 2010-05-03
As a creative developer and an interaction designer, I need to either produce or guide the production of interactive projects. Needless to say, to non technical people such as designers, producers and account managers, we do some black magic and create the most amazing things. But what are the ingredients of this magic? Mostly organizational skills I would say.
I have originally planned to help and guide students and beginners with this blog, to use the posts as notes and references for some tutorials I have given at Concordia University in Montréal. I strongly believe that it is the responsibility of senior developers and creatives to provide newcomers to this overwhelming field with the proper tools to learn to work efficiently and professionally.
Because, let's face it schools and universities fail in this domain. These institutions do not aim "to create mindless production drones for the interactive industry blah blah blah..." This is such a hypocritical argument that could be easily refuted by looking at how computer engineering or administration programs teach students how to be organized in their thoughts and workflow. Others have actually had confrontations much stronger than I and have lived to tell about it.
For my part, I have chosen to provide Sid Lee, where I currently work, with information and references to good practices in the form of a wiki. A wiki is easy to update and it is a well known way to organize information, so most people can navigate quickly.
Also, most things in many people's jobs do not need to be remembered by heart. Hell, I hope nobody says stuff without references, especially technical references necessary for a project! That is why such references are useful, especially for training newcomers and simply for keeping inline with company policies.
In the wiki, I presented what is needed for a project from many players in the process of the production, such as producers, designers and interactive developers. This is an internal tool not available to the public, but today I stumbled upon an article, What to Deliver a Flash Developer, which highlights a lot of the similar points that I have brought up to many kick off meetings. Since this blog is aimed at helping developers to learn good practices, I thought it would be a good idea to republish and comment on the post.
Note that I am careful in not utilizing the term "Flash developer" as the authors of the post did, as I believe this is plain wrong. Do we call designers "Photoshoppists"? Flash is just a tool currently used often in the creation of RIAs, but it is not and will not always be the case. Some of us work with ActionScript, some others with PHP, with CSS, with HTML, with Objective-C, with Android, with Java, with OpenFrameworks, etc. Specialists exist indeed in all fields, but workflows for RIAs, games and other interactive projects are not confined to Flash development.
Whatever rant or complaint I may seem to voice here, the article aforementioned is a great read for anybody who wishes to manage development of projects, or simply to make sure that parts are not forgotten along the way.