What To Deliver A Flash Developer

Flash developers are usually the last line of defense (meaning that we are the last ones to touch the project before the client sees it) and there is a lot of pressure put on us to deliver a polished product. At the point we start, chances are the deadline has already been stretched due to hang ups in the process before we ever see what we’re about to get ourselves into and being organized and receiving well-organized assets/direction is the key to success. Ideally, you should really bring the developer in during the kick-off meetings as it will ease the process down the line and make everyone’s lives easier. Even with the list below, it’s always good to explain to the developer during the early stages your vision and concept for the site, the animation style, demographic, and similar items that will aid during the process of development. Sadly, this usually never happens and we’ve got to buckle down and micro-manage everything to make sure all systems are go.

I’ve gone through this on every project it seems. I am ready to code and get the assets/necessary files from a designer/producer/back-end developer. I start opening stuff up and am underwhelmed at how much is provided. I’m missing a bunch of stuff and there are underlying questions about what needs to be done. In the interest of saving time, I thought I’d write a little guide as to what I (personally, at least) would love to get every time I start a new project so I can reference this in the future as well as hopefully get some input on stuff I may have missed or never realized in my process. This is an ideal scenario, of course, and a lot of times you won’t receive this entire list (and in some tragic cases, any of it), but it makes life so much easier on a Flash developer to actually have all of these things ready to go when the project is handed to you for the final stretch and you want to hit that deadline.

Topics include:



Every project has different requirements. You can’t start coding unless you know that the project is supposed to run in Flash Player 8, 9, or 10+. The target Flash Player is huge because it will make the difference between AS2 (8 and below, please don’t do this to us!) and AS3 (9+), which makes a HUGE difference. You also need to know what the target file size is (if you’re doing banners or something that needs to be kept relatively small) and physical dimensions (is this full screen, a set size, liquid, or need to fit into a small part of a hybrid site?). It’s also imperative at this time to make sure the designer is designing for whatever the target resolution is (hopefully nobody is designing for lower than 1024×768 at this point) and what the target audience is.

Copy Deck
No matter what project you’re on, there is a 99.9% chance that you will be adding copy to it (probably closer to 100%, but you get the idea). Lots of times you are handed Photoshop PSD files that have copy in them because the designer obviously used the copy to aid in designing the appropriate sections. Sometimes, however, there is no one single document that holds all the copy on the site. This is problematic for two reasons:

With a separate Word document that has all the copy you can easily make a change and highlight it in a different color or background for the developer to quickly scan the file and find what has been changed. Word-savvy power users can us also use the snappy little comment tool to add comments (only issue I’ve seen with this approach is that after a lot of edits, the file starts to have lines pointing to a bunch of things in the document and is hard to follow, let alone the margins filled with comment bubbles). Be sure to remember to version the file as well, as ideally you’ll want to remove all color changes/highlights when making new revisions and add the newest ones in. That way, if you hand off a bunch of edits to the developer, then make more edits, he can look at each version separately and go back and make the appropriate changes while still easily finding what has been changed by a quick color scan. Even better, if you have a change log at the top of your file (unrealistic usually, but awesome if done right) you can track changes that way as well. If your developer is color blind, however, this causes another issue that is outside of the scope of this article.

Everybody loves fonts! There has not been one single project that I’ve worked on where we have not run into some type of font issues. Whether it’s Mac to PC, PC to Mac, OpenType to TrueType, not delivering the fonts at all, or whatever the heck else, there is always some kind of issue with fonts. Designers have to be absolutely sure they keep track of all fonts used in a set of designs and package those up for a developer. Ideally, you want to use cross-platform fonts that are OpenType, as it works on both Mac and PC.

External Assets
There are all kinds of external assets that get used in a project and it all depends on what the job calls for. Nine times out of ten, however, they will fall into these three categories:

Flash is great and compression is fun (NOT!), but exporting a bunch of transparent PNGs and putting them in your application is bound to cause performance issues. I like to use vectors wherever possible because they preserve their editing capabilities and because I can always set them to act like bitmaps if necessary. A few things to note on this topic:

Rollover States
This is another item that always seems to be forgotten. You should be creating rollover states for all of your interactive objects as you go along. One of the great things about Flash is interactivity, and what better way to go interactive than to show the user some kind of feedback that they’re rolling over an object that is clickable/selectable/etc? Isn’t that the whole point of using Flash in the first place? It’s always very helpful to the developer to show the rollover states of buttons and other such items along with layer comps (see below).

Sadly, preloaders are like the forgotten stepchildren of the Flash world. It’s a shame, really, that they become an afterthought because it’s usually the first thing a user sees when they come to your site and you want to set a good first impression. I’ve been captivated by many awesome preloaders in the past and so have others, so much so that there is a site dedicated to show off the coolest preloaders out there (Pretty Loaded). Most of my projects I never even get designs for a preloader and thus I end up creating the good ole boring line loader when everything else is said and done. Please remember as well that when you talk preloaders you’re not only talking about the main site but external assets that are being loaded in as well. This includes images, sounds, and video, and usually you also need (if different) a buffer animation for those. It’s such a small treatment but can add so much to a site’s overall look and feel.

Error Handling
In today’s day and age a lot of the projects you will be working on have some type of user input, be it a log in page, a registration form, or a contact page. Designers almost always deliver these but do not show scenarios for when errors occur. What happens if the user enters an invalid email address? What happens if the user doesn’t fill in all of the required fields? Where does this error show up and how does it look? Is there different error treatments for different input fields or do they all show up in the same spot depending on what portion the user is currently filling out? Are they inline errors or do they appear when you press submit? These are all questions that the developer will undoubtedly have so they need to be accounted for in the user experience as well as the design process.

“No Flash” Page
Unfortunately, there is still a very small percentage of users who don’t have Flash installed or have Javascript turned off thus not allowing to display Flash content through normal embedding methods used today. There is also the possibility that the user has a version of the player installed that is lower than what the targeted player was for your project so you need to show an HTML page that outlines these points and how to upgrade/download/etc. If there is no alternate content page on the site the user will feel frustrated and leave without trying to remedy the situation. It’s necessary for the designer to provide a page to the Flash developer (or HTML developer if there is a separate one on the project) to incorporate into the site.

Normally, this isn’t a requirement. Some projects are small enough that just looking at the comps is feasible (although not recommended). For larger projects, it’s really handy to have a nice set of wireframes that clearly illustrate the project’s roadmap and are detailed enough so that most of the usability questions are answered within the wireframes themselves. These are like a site map and show processes, such as logging in and the resulting pages for each possible scenario (success, fail, server failure, etc). This is also a great place to show error handling (see above).

Layer Comps
Much like smart objects, layer comps take only seconds to make and could save a developer a ton of showing/hiding layers/folders in a PSD. For those unfamiliar, a layer comp is basically a snap shot of your PSD at the current state. A designer who is familiar with the layers of the PSD can quickly go through and show/hide each set of layers necessary for each state of the application and take a layer comp (snapshot) of it and save it into the layer comps palette. The developer can then quickly show whatever state was defined and see all the states of the application without having to fumble through layers and folders. Of course, you should be organizing your layers as you go along as well, but this is even more effective in the hand-off process. Just make sure to name the layer comps (just like you do actual layers) so you can recognize what’s what at a glance. Of important notice here is also that if you change your design after creating layer comps, you will have to re-create the layer comp or Photoshop gets confused and doesn’t know what has been changed and what it needs to show. In this instance there will be a notification icon on the layer comp in the layer comps palette notifying you that something has been changed and that Photoshop doesn’t know what to render for this layer comp any longer. For this reason, layer comps should ALWAYS be the last thing you do before hand off. Don’t forget to make layer comps for rollovers as well if everything is contained in one file. This will make your developer so happy that you’ll be recommended for future work with them, guaranteed!

Interaction/Motion Guide
Let’s face it. Developers are not super creative, and those that are and have some kind of background in motion/design come few and far between. Most developers come from a computer science background where graphics were just ones and zeros on a screen. Even I have a degree in “Multimedia and Web Design” and experimented with 3D Studio Max, After Effects, and a slew of other programs where motion was a plenty and have lost my touch in animation as I’ve come along as a programmer. It is SUPER helpful to see the designer’s vision in a nice and clear document that possibly shows frames of an animation or even a description of what it should do. You can even send example links of something you may have seen before if applicable to help the developer picture your vision. Just remember, not everything you’ve seen before on another design applies to your design. A flat rectangle in 3D space won’t animate the same in perspective as an oddly shaped image of an animal or some other type of organic shape so make sure to keep those details in mind when figuring out animations for your project.

Scripting Guide
If you’re working closely with a database programmer or a back-end developer in general, it’s always nice to know what methods they are writing, what parameters those methods expect, and what the output results for all operations is. For instance, if you’re sending along some information into a database, it’s good to know what variables you need to send. Then, when those items are added to the database, you normally get a result. It could be an XML/JSON output of a query or something along those lines and seeing that result clearly laid out in an example is extremely helpful to a Flash developer so they know how to treat it and what to expect. This is usually one of the easiest steps to achieve as developers usually speak the same language and can understand each other more clearly.

Asset Organization
If you’re providing external assets, organization is VERY important (it’s always important, but the importance here is even greater). Speak with the developer and figure out a good folder structure/naming convention for your assets so that they can easily pick them up and transfer them right in to the project’s folder structure without having to make many (if any at all) changes. I’ve been in a situation before where I’ve spent literally one or two whole days organizing assets and re-saving things because they were not very easy to find or not compressed properly. Everyone has his or her own preferences on this so I won’t get too specific here, but just know that you will be loved for handling this from the get-go.

That concludes my list of things that you would be considered a genius for if you delivered to a Flash developer at the start of each project. This is certainly open for discussion as well as revisions and I encourage others to give input so I can add them to the list and make this an ever-growing resource for Flash developers to send others at a kick-off to ease the pain.

John Fisher
Jack Doyle

If you found this post useful, please consider leaving a comment, subscribing to the feed, or making a small donation.


Awesome article bro! So true… Definitely showing this to some people today 😉 Thanks!

Can you please make this article title read “What To Deliver _TO_ A Flash Developer”? Leaving out the “To” is driving me mad.

@reyco1: thanks!

@Leif Wells: lol, why is leaving out the “to” driving you mad? It doesn’t really need to be part of the title IMO.

[…] This post was mentioned on Twitter by Chad Udell, Seantron™ McCracken, ActionscriptArtist, Matt Przybylski, John W Fisher II and others. John W Fisher II said: RT @reintroducing: What To Deliver A Flash Developer – http://evolve.reintroducing.com/2010/05/03/tips-n-tricks/what-to-deliver-a-flash-developer/ […]

[…] 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. […]

Nice piece Matt – very well done.

The perfect world for any Flash Developer.
Great article, i will print a copy and deliver it to all my compnay designer’s.

Nuno Ribeiro

@MattP & @reyco1…you fools know each other? What a small world. Hope everything is cool with you Rey….and Matt, I guess we’ll be seeing each other in the coming weeks.

Sorry this comment had nothing to do with your article (which is fantastic btw), just thought it was crazy seeing Rey here and figured I would give a quick shout-out.

Peace fellas! -Jason

@Jason: LOL, how do you know Rey? We talked a few times online, I was even interviewed on his site (not sure if its up anymore?).

Thanks for the kind words about the article. I’ll see you on the 27th 😛

@MattP: Rey and I used to work together down in Florida back in the day. We also have another mutual friend Robert, which you may know from the Fish, but I also think you guys had some connection on some freelance stuff a while back…so weird.

Nice Article

Specially liked the line “the last line of defense”

Very interesting article in the sense that I relate to your frustration. On the other hand, we just do not live in this world. We don’t get any of these things and hope always seems to be a shade of #d2d2d2. I hate to be the dorky guy that casts a shadow but IMO this is very unrealistic.

Having said that, I enjoyed reading it non the less and said to myself several times, “yeah, I feel your pain.”

@Graham: while you’re right, it is unrealistic, there is no reason why it can’t be realistic. The reason I wrote this is because i’d like it to become a reality. If people understood that delaying things like this just takes up more time on the project in the long run and provided it right off the bat it would make things much smoother.

Great article – very useful thanks 🙂

Leave a comment