デザインシミュレータから入稿データまでつなげるには？

ブラウザ上で商品をデザインできるようにする。
ここまでは、デザインシミュレータの開発としてイメージしやすい部分です。

ユーザーが画像をアップロードし、文字を入力し、色や配置を変更する。3Dの商品であれば、その状態を3Dで確認する。
では、そのデザインが完成した後はどうするのか。

オリジナル商品として実際に販売するのであれば、そこで終わりではありません。

作成されたデザインを注文情報と紐付け、必要なデータを整理し、印刷や製造の工程へ渡す必要があります。

現在、Web上でデザインから注文・入稿までを完結させるサービスも存在しており、デザインシミュレータは単なるプレビュー機能ではなく、商品販売の一連の流れに組み込まれるものになっています。

デザインシミュレータを開発するときに考えるべきなのは、「どうやって入稿ボタンを作るか」ではありません。

その前に、そのデザインを最終的にどのような商品にするのかを決めておくことが重要になります。

【自社の商品なら、どのようなデータ連携が必要になるか相談する】

• 30分無料デモ・開発相談はこちら

画面で見えるデザインと、入稿するデータは同じではない

ブラウザ上でデザインを作る場合、ユーザーが操作した結果を画面に表示する必要があります。

画像を配置した位置、拡大率、回転角度、文字の内容、フォント、色など、画面上ではさまざまな情報を扱います。

しかし、その情報をそのまま印刷や製造に利用できるとは限りません。

画面上で商品にデザインがきれいに表示されていても、実際に印刷するときには、印刷可能範囲や画像の解像度、カラーモード、加工方法など、別の条件が関係してきます。

商品によっては、表面と裏面で印刷条件が違うこともあります。立体の商品であれば、3Dモデル上の表示と、実際の印刷面に展開したデータとの関係も考えなければなりません。

そのため、デザインシミュレータを開発するときには、画面上でどのように表示するかと同時に、最終的にどのようなデータが必要なのかを決めておく必要があります。

「デザインが完成したらPDFを出力する」という仕様だけを先に決めても、商品側の条件が整理されていなければ、そのPDFが実際の入稿に使えるとは限りません。

先に「何を入稿するのか」を決める

デザインシミュレータの開発では、画面から作り始めるより先に、最終的な入稿工程を確認しておく方がスムーズです。

印刷会社へPDFを渡すのか、SVGなどのベクターデータを利用するのか、画像データとして出力するのか。それとも、シミュレータ側でデータを生成し、既存の受注管理や製造システムへ直接渡すのか。

必要になるデータは、商品の仕様や製造方法によって変わります。

実際に、デザインシミュレータで作成したデータをPDFとしてダウンロードして入稿する運用や、シミュレータからそのまま注文へ進める運用があります。

どの方法が適しているかは、デザインシミュレータそのものではなく、その後の業務によって決まります。

現在の入稿方法をそのままWeb化するのか、入稿工程そのものを見直すのかによって、システムの設計も変わります。

商品ごとの条件を、システムにどう持たせるか

オリジナル商品を扱う場合、すべての商品が同じ条件でデザインできるとは限りません。

商品のサイズが違えばデザインできる範囲も変わりますし、印刷位置によって必要なデータも変わります。

さらに、カラーや素材、加工方法によって対応できるデザインが変わることもあります。

こうした条件を担当者が注文後に確認するのではなく、デザインシミュレータの中で扱えるようにすれば、ユーザーがデザインしている段階で条件に合わせた操作をさせることができます。

例えば、印刷できない範囲にはデザインを配置できないようにすることもできます。商品の仕様に応じてデザイン可能な領域を変更することもできます。

ここで必要なのは、単純に制限を増やすことではありません。

商品として成立する条件を、ユーザーがデザインする段階でどこまでシステムに反映するか。

この設計によって、注文後に人が確認しなければならない内容も変わってきます。

3D商品では、さらに考えることが増える

3Dシミュレータの場合、画面上では商品を立体的に表示します。

ユーザーがデザインを変更すると、3Dモデル上にもそのデザインが反映されます。

しかし、製造に必要なデータは、必ずしも3Dモデルそのものではありません。

3Dモデルに貼られているテクスチャやUVマップ、印刷する面の位置、デザインの座標などをどのように関連付けるかによって、必要な仕組みが変わります。

例えば、商品を3Dで見せるためのテクスチャと、実際の印刷に利用するデザインデータを別々に管理し、ユーザーの操作をそれぞれのデータへ反映させる設計も考えられます。

AgWORKSでは、3DCGのモデリングやUVマッピングからWebGLを利用した3D表示まで扱ってきた経験があります。

そのため、3Dモデルを表示する部分だけではなく、「そのデザインを最終的にどう商品へ反映するのか」というところまで含めて設計することができます。

入稿データを自動生成することが、必ずしもゴールではない

デザインシミュレータの話になると、「入稿データを自動生成できるか」という点に目が向きやすくなります。

もちろん、一定の条件で自動的に入稿データを作れるようにすることで、担当者の作業を減らすことはできます。

ただ、すべての商品で完全自動化が必要とは限りません。

ユーザーが作成したデザインをシステム上に保存し、注文情報と一緒に担当者へ渡す。担当者は必要な部分だけ確認し、最終データを確定する。

この運用でも、それまでユーザーとのメールや電話で確認していた内容をシステム上に集約できます。

逆に、商品数や注文数が多く、同じようなデータ処理を大量に行っているのであれば、入稿データの自動生成まで進める意味が大きくなります。

重要なのは、「自動生成できるか」ではなく、現在の業務のどこを自動化すると効果があるのかを判断することです。

【入稿まで含めた開発範囲を整理する】

• 30分無料デモ・開発相談はこちら

印刷や入稿を知っていることが、システム設計にも影響する

Web上でデザインを扱う場合、どうしても画面側の仕様に意識が向きます。

しかし、実際の商品を作るのであれば、その先に印刷や製造があります。

画面上で表示される色と印刷物の色は同じではありません。画像の解像度やデータ形式にも条件があります。印刷方法によって必要なデータが変わることもあります。

こうした条件を知らずにシステムを作ると、完成したデザインシミュレータと実際の入稿工程の間に、人による修正作業が残ってしまうことがあります。

AgWORKSでは、Webシステムだけでなく、グラフィックデザインや印刷物の制作、印刷入稿の経験があります。

そのため、シミュレータの画面を作る段階から、その先でどのようなデータが必要になるのかを考えることができます。

これは「印刷に詳しいWeb制作会社」というだけの話ではありません。

ユーザーが操作する画面から、最終的な商品ができるまでの間に存在する工程を把握したうえで、システムの設計に反映できるということです。

既存の業務を残したまま始めることもできる

すでにオリジナル商品を販売している企業の場合、デザインシミュレータを導入するために、現在使っている仕組みをすべて入れ替える必要があるとは限りません。

現在のECサイトや注文管理、入稿作業を残し、その前段にデザインシミュレータを追加する方法もあります。

ユーザーがシミュレータでデザインを作成し、そのデータと注文情報を既存の仕組みに渡す。

まずはこの部分から始め、利用状況や業務上の効果を確認しながら、入稿データの自動生成やシステム連携などを追加していくこともできます。

デザインシミュレータを導入すること自体を目的にするのではなく、現在の商品販売の流れのどこに組み込むのかを考えることで、必要以上に大きなシステムを最初から作らずに済む場合があります。

「デザインできる」から「商品を作れる」へ

デザインシミュレータの価値は、ユーザーがブラウザ上でデザインできることだけではありません。

• ユーザーが作ったデザインを、注文情報として扱える。
• そのデザインを、3Dの商品に反映できる。
• 必要な情報を保存できる。
• 印刷や製造に必要なデータへ変換できる。
• 既存のECや業務システムと連携できる。
• そして、その商品を実際に製造できる。

ここまでつながって初めて、ブラウザ上のデザインが現実の商品になります。

AgWORKSでは、3DCG、WebGL、グラフィックデザイン、印刷入稿、Webシステム開発と、それぞれ異なる領域で培ってきた経験を組み合わせて、オリジナル商品デザインシミュレータを開発しています。

画面上のデザインだけを作るのではなく、そのデザインが最終的にどのような商品になり、現在の販売や製造の流れの中でどのように扱われるのかを確認したうえで、必要な仕組みを設計します。

すでにオリジナル商品を販売していて、デザインや注文、入稿に関する業務を効率化したい。

ユーザー自身に商品をデザインしてもらう仕組みを作りたい。

ブラウザ上のデザインを、実際の商品として製造できるところまでつなげたい。

そうした場合には、まず現在の商品と業務の流れを確認することから始められます。

【自社の商品で、どこまで実現できるか相談する】

• 30分無料デモ・開発相談はこちら