Setting Project Requirements
Start with the constraint, not the artwork
Every Animate project begins with a short requirements conversation that fixes the decisions you cannot easily reverse later. Identify the audience and delivery platform first: a kiosk, a broadcast bumper, a responsive web banner, an LMS-hosted module, and an in-app tutorial each imply different technical limits. Then lock the document type, because it determines which features exist at all - HTML5 Canvas publishes JavaScript/CreateJS, supports only a subset of filters and blend modes, and runs no ActionScript; ActionScript 3.0 targets Flash Player/AIR with the full scripting API but will not run in modern browsers; WebGL suits GPU-heavy canvas work; AIR is for packaged desktop or mobile apps.
Next define stage size and frame rate. Frame rate is not duration: at 24 fps a 5-second loop is 120 frames, and raising fps does not automatically make motion smoother - it raises file size and CPU load. Follow convention (24 cinematic, 25 for PAL/broadcast, 30 for web and video) and keep one rate for the whole file. Capture the file-size budget, target devices, minimum browser, retina/scale-to-fit behavior, accessibility needs, and brand constraints in writing before drawing anything.
Trap: questions that describe a client need and ask you to pick a document type - read the delivery target, not the artist's preference. Another trap is assuming stage dimensions equal exported pixel dimensions once responsive scaling is enabled.
Rule of thumb: write a one-line brief - platform, document type, stage size, frame rate, size cap - and do not animate until it is complete.
Worked example: a 300×250 news-site banner capped at 3 MB. Choose HTML5 Canvas, 24 fps, stage 300×250, build with symbol instances and short motion tweens, export a sprite sheet, then check the published folder size in a browser before delivery.