Q.なぜ入稿データを Illustrator ではなく Figma で作ったのか
参加団体数が最後まで動く前提で、行数・列数の変更にオートレイアウトで耐える必要があったから。
印刷物の入稿は Illustrator が定石で、Figma で入稿データを作るのは業界的には非推奨です。それを承知の上で、今回は Figma を選びました。理由は共同編集機能ではなく、オートレイアウト の一点に尽きます。
このプロジェクトは、参加団体数が確定しないまま走り出していました。最終的に 60〜70 団体まで膨らみ、制作中も増減する可能性が高い状態です。
Illustrator で「3 列 9 行」のような固定フォーマットを先に組んでしまうと、「3 列のまま 12 行に増やしたい」という変更が入った瞬間に、全レイアウトを手で組み直すことになります。Figma のオートレイアウトなら、カードを足す / 引くだけで行数も紙面の高さも自動で追従する。直前でベストなレイアウトが変わり得る、という今回の不確実性に柔軟に対応するための選択でした。
実際には、カード自体を「文言を差し替えるだけで完成する」コンポーネントとして設計しました。住所・電話・営業時間・料金といった各要素をコンポーネントのプロパティ(上図の bill_button / adress_button / phone_button / time_button など)として持たせ、団体ごとの原稿をプロパティに流し込むだけでカードが組み上がる状態にしています。これが「団体数が最後まで動く」不確実性への、オートレイアウトと並ぶもう一段の備えでした。
今回の構成要素はすべて SVG で作れる見込みがあったので、最終的に Figma から SVG で書き出し、Illustrator に配置して入稿しています。アウトライン化されてテキスト編集はできなくなりますが、入稿用途では許容範囲でした。
Figma の本質である共同編集を使ったわけではありません。ただ、Illustrator では実装が重かった「流動的なレイアウトへの追従」を Figma 側で解き、入稿は Illustrator に戻す、という役割分担で、定石から外れる判断に実利を持たせています。
+More_Decisions
