パーツ設計とは、デザインを項目に分解する作業

パーツ設計を一言で表すと、「デザインを、適切な粒度の項目に分解する作業」です。

デザイナーから上がってきたワイヤーフレームやモックアップは、画面のレイアウトとして表現されています。これをそのままCMSに入力させようとすると、運用者は画像編集ソフトのような自由度を求められて、品質が保てません。

設計者の仕事は、画面に並ぶ要素を「タイトル」「画像」「本文」のような項目に分解し、運用者には項目に値を入れるだけで画面が出来上がる仕組みを用意することです。デザインから項目への分解、これがパーツ設計の本質です。

パーツ設計の3つのステップ

実務では、パーツ設計を次の3ステップで進めると整理しやすくなります。

ステップ1：実コンテンツでモックアップを作る

最初に作るのは、ワイヤーフレームではなく実際のコンテンツが入ったモックアップです。

ダミーテキスト（「ここに見出しが入ります」「ここに本文が入ります」）でモックアップを作ると、設計時に必要な項目を見落とすことが多くあります。実際のコンテンツを入れてみて初めて、「タイトルが想定より長い」「画像のサイズ感が一覧と詳細で違う」「複数行になるとレイアウトが崩れる」といった問題が見えます。

実コンテンツで作ったモックアップは、後のステップでパーツに分解するときの基準になります。

ステップ2：ページを大きなパーツに分割する

実コンテンツのモックアップができたら、ページを大きな単位のパーツに分割します。

たとえばサービス詳細ページなら、次のような分割になります。

  • ヘッダー
  • パンくずリスト
  • サービス概要パーツ（メインビジュアル＋サービス名＋導入文）
  • サービス特徴パーツ
  • 料金パーツ
  • 導入事例パーツ
  • 関連資料パーツ
  • お問い合わせCTAパーツ
  • フッター

この段階では、パーツの中身（項目）はまだ決めません。「ページの中にどんなブロックが並ぶか」を決めるだけです。

ヘッダー・フッター・パンくずのような共通領域も、ここでパーツとして認識しておきます。これらをCMSで管理するか直書きにするかの判断は第6回で扱いますが、設計上は同じくパーツの一種として捉えます。

ステップ3：各パーツを項目に分解する

最後に、各パーツの中身を項目に分解します。

たとえばサービス概要パーツなら、次のような項目に分解できます。

  • メインビジュアル（画像）
  • サービス名（1行テキスト、50文字以内）
  • サービスのキャッチコピー（1行テキスト、80文字以内）
  • 導入文（複数行テキスト、500文字以内）

各項目には、入力の型（1行テキスト・複数行テキスト・画像・日付・選択肢など）と、必要に応じて文字数制限などの制約をつけます。これらの詳細は次回（第5回）で扱いますが、パーツ設計のこの段階で、項目の数と大まかな型を決めておきます。

3ステップを踏むと、デザイン上の見た目が、運用画面で扱いやすい項目の集まりに変換されます。

適切な粒度とは

項目に分解するとき、どこまで細かく分けるかは判断が必要です。粒度が粗すぎると入力の制御が効かず、細かすぎると運用者の負担が増えます。

判断の目安として、次の観点を持っておくと整理しやすくなります。

観点1：その情報を独立して使うか
「住所」を1項目で持つか、「郵便番号・都道府県・市区町村・番地」に分けるかは、その情報を独立して使う場面があるかで決まります。都道府県別に絞り込みたいなら、都道府県を独立項目にします。単に表示するだけなら1項目で構いません。

観点2：入力のばらつきを抑えたいか
自由記述の項目を1つにまとめると、運用者によって書き方がバラつきます。書き方を揃えたい情報は、項目を分けて入力させると品質が揃います。たとえば製品概要を1つの自由記述にするより、「特徴1・特徴2・特徴3」と分けると、書き方が揃います。

観点3：表示場所ごとに使い分けるか
詳細ページではフル表示、一覧ページでは短縮表示、というように表示場所で長さや形を変えたいなら、それぞれ別項目を用意します。「概要文（500文字）」と「短い説明文（80文字）」のように、用途別に項目を分けます。

これらの観点で項目の粒度を決めていくと、画面の都合だけで項目を増やすのではなく、コンテンツに必要な粒度で項目を持つことができます。

パーツの種類は意図的に絞る

各パーツを項目に分解していくと、似たような項目構成のパーツが出てくることがあります。これらは1つに統合できる候補です。

たとえば「見出し付きテキスト」「画像付きテキスト」「2カラムテキスト」を別々のパーツとして用意してしまいがちですが、項目で見ると「見出し（任意）＋画像（任意）＋本文＋レイアウト指定」という1つの構造に統合できます。1つのパーツとして設計し、項目の値（画像の有無、レイアウト指定の値）によって出力が変わる形にすると、運用者は迷わずに済みます。

設計時の目安として、サイトで使うパーツの種類は10種類以内に抑えるのが現実的です。種類が増えると、運用者は「どれを使えばいいかわからない」状態になり、結局1〜2種類しか使われなくなります。新しいパーツを追加したくなったら、既存のパーツで代替できないかを必ず検討します。

ネストは原則禁止する

「パーツの中にパーツを入れられる」設計は、運用の難易度を一気に上げます。

ネストを許すと、運用者は「どのレベルにどのパーツを入れるか」を考えなければなりません。階層が深くなると、ページの構造を把握できなくなります。

原則として、ネストは禁止する設計をおすすめします。「カラム分割の中に他のパーツを入れたい」というニーズが出たときは、最初からカラム分割込みのパーツとして設計します。「2カラムテキスト＋画像」というパーツを1つ作っておけば、ネストせずに済みます。

ネストが必要に思えるケースは、たいてい「共通パーツとして独立させるべきサイン」でもあります。複雑な構造のものを共通パーツとして1つ作り、ページ内では1パーツとして配置する形にすると、ネストの問題が消えます。

出力デザインは設計側で決め打つ

パーツの出力デザインを、運用者に選ばせる仕様にしないことをおすすめします。

「文字色を選べる」「文字サイズを選べる」「背景色を選べる」「アライメントを選べる」など、運用者がデザイン要素を選べる仕様は、運用品質を下げます。運用者によって判断がブレ、サイト全体の見た目がバラつきます。

デザインのトーン＆マナーを保つには、設計時にパターンを決め打ち、運用者は項目に値を入れるだけにする設計が確実です。

どうしても複数のデザインバリエーションが必要なら、それぞれを別のパーツとして用意します。たとえば「カード型のCTAボタン」と「バナー型のCTAボタン」が必要なら、それぞれ別のパーツにします。同じCTAボタンの中で「カード型／バナー型」を選ばせるよりも、運用者は迷いません。

この回のテスト観点

パーツ設計が適切かは、次の観点で確認できます。

  • 実コンテンツでモックアップが破綻しないか：ダミーではなく実コンテンツを入れて、レイアウトが崩れないか、項目が不足していないか確認する。長いタイトル・短いタイトル・画像なしのケースなど、想定される全パターンで確認する
  • 似たパーツが複数ないか確認する：項目構成がほぼ同じパーツが複数あるなら、統合できる可能性があります。「微妙にレイアウトが違うだけ」「項目が1つ違うだけ」のパーツは、統合の候補です
  • 運用者役の人にパーツの選択をしてもらう：用意したパーツを並べて、運用者役の人に「このコンテンツを作るならどのパーツを使う？」と聞いてみる。迷ったり、「どれでも作れる」と感じる場合は、種類を絞る余地があるサインです
  • 項目の粒度が運用者の手に馴染むか：項目が細かすぎて入力負担が大きくないか、逆に粗すぎて品質がバラつかないか確認する

検証の方法論については第7回で詳しく扱います。

まとめ

パーツ設計は、デザインを適切な粒度の項目に分解する作業です。実務では、実コンテンツでモックアップを作る、ページを大きなパーツに分割する、各パーツを項目に分解する、という3ステップで進めると整理しやすくなります。

そのうえで、パーツの種類は意図的に絞る、ネストは原則禁止する、出力デザインは設計側で決め打つ。この3つの指針を守ると、運用者に迷わせない仕組みになります。

次回（第5回）は、ここで分解した項目の名前と説明文をどうつけるかを扱います。同じ項目でも、名前と説明の付け方で運用のしやすさが大きく変わる、という話です。

著者

STSD株式会社代表 鴻田孝雄。製薬企業のWebサイトを中心に、BtoB向けCMSの開発・設計に20年以上関わっている。長期運用を前提とした設計と、運用負担を最小化する仕組み作りに関心がある。