Build the bill of materials for the quote.
List every printed piece and every item that affects the complete set. Give each component a clear name, state how many belong in one game, and distinguish a shared component from one supplied per player. Include boards, decks, rulebooks, reference cards, score sheets, dividers, inserts, bags, trays and packaging even when some artwork is still in progress.
Record finished sizes and sides, not just file names.
For each component, note its intended finished size, orientation, count, front/back relationship, fold or assembly need and whether there are language or version variations. A folder called “final files” does not say whether a board folds, whether a deck shares a back, or whether a player aid appears once per game or once per player. Those distinctions shape the scope.
Plan components as tools at the table.
Cards, boards and paper pieces need to be usable during play as well as attractive in a flat mock-up. Check information hierarchy, symbols, reading distance, orientation, edge-sensitive text and any front/back pairing. Make a note of components that are frequently handled, shuffled, compared or referred to during setup so their function is visible in the project brief.
Put rules, reference aids and packaging in the same conversation.
Rules and quick-reference material should help players find setup steps, icon meanings and turn information without hunting through a decorative layout. Packaging should be planned around the complete component list rather than a box-cover image. If pieces need separation, protection, quick access or room for later content, record that requirement clearly for project review.
Control the handover and proof review.
Use consistent version names and keep a single current component list with the artwork. Approval check, check the final count, front/back matches, sequence, page order, box copy and the relationship between the components and the proposed packing direction. Any non-printed components, specialist inserts or technical requirements should be confirmed in writing for the specific project, not assumed from a prototype or reference game.