09 ・ 媒体と実物
Web・LP
訪問者の目的とページの目的を合わせ、構成、デザイン、実装、プレビューでの確認を経て、案件の承認条件に従って公開できる状態にするガイドです。
- 決めること
- 訪問者の疑問に答える構成と見出し、代表画面のデザイン、画面幅ごとの表示、採用する機能の仕様
- 主な成果
- プレビューで確かめたページ、公開したページと公開後の確認の記録
- 前後のガイド
- 主な画像はキービジュアル・広告・SNS画像、挿絵や素材はイラスト・画像素材、見出しの言葉の検討はネーミング・コピーのガイドで扱います。利用者が繰り返し操作して作業を行う製品の画面は、UI画面のガイドで作ります。
Web・LPの工程と判断
概要
UI画面のガイドは、利用者が製品やサービスの中で繰り返し操作し、目的の作業を行うための画面と状態を作ります。Web・LPは、訪問者が読み進めて内容を理解し、行動を決めるためのページを作ります。主に扱うのは、読む順序、見出し、採用する機能、公開までです。動くプロトタイプのガイドは検証のための試作を扱い、公開を前提にしません。ページに使う主な画像はキービジュアル・広告・SNS画像のガイド、見出しの言葉そのものの検討はネーミング・コピーのガイドを参照します。
構成とデザインを選んでから実装し、プレビューで操作して確かめます。申し込みや問い合わせのフォーム、予約、資料の請求などの機能は、ページの目的に必要な場合に採用し、その仕様を決めます。読んでもらうこと自体が目的のページや、他のページへ案内するページでは、こうした機能を置かないこともあります。公開は、その案件で決められた承認条件に従います。人が判断するのは、構成を選ぶ場面、デザインを選ぶ場面、操作と画面幅ごとの表示を確認する場面、公開の承認を得る場面です。
向いている場面
- 商品、催し、サービスを紹介するページを作るとき
- 既存のページで、訪問者が行動を決める前に離れていそうなとき
- 公開までの確認を、手順として揃えたいとき
このガイドで扱わないこと
- 製品やサービスの中で繰り返し操作する画面の設計。UI画面のガイドで扱います。
- 主な画像や挿絵の制作。キービジュアル・広告・SNS画像のガイドと、イラスト・画像素材のガイドで扱います。
- 公開するかどうかの決定。案件の承認者が判断します。
全体の流れと分担
工程は01から06へ進みます。工程02で人が構成を、工程03でデザインを選び、工程05で操作と画面幅ごとの表示を確認し、工程06で承認を得て公開を判断します。構成が決まったあとは、画像などの素材の制作とページの実装を分担できます。工程05で情報が見つけにくいと分かったら工程02へ、表示が崩れたら工程04へ戻ります。
工程ごとの分担
| 担い手 | 01訪問者 | 02構成 | 03代表画面 | 04実装 | 05プレビュー | 06公開 |
|---|---|---|---|---|---|---|
| 人 | 判断：主な訪問者と、してほしい行動を決める | 判断：ページの構成を選ぶ | 判断：デザインを選ぶ | 判断：仮の部分を把握し、確認へ進めるかを決める | 判断：操作と画面幅ごとの表示を確認する | 判断：承認者の承認を得て、公開を判断する |
| AI | 訪問者と疑問の候補、来た経路を整理する | 構成案と見出し案を作る | デザイン案を作る。環境があればデザインファイル上で作る | 環境があれば実装する | 確認項目を作る。手段があれば機械的に確かめる | 確認項目と手順を下書きする。公開の操作は取り決めがある場合だけ |
| デザイナー | なし | なし | 主な画像やブランドに関わる表現を制作・監修する | 画像などの素材を用意する（並行） | なし | なし |
| 開発担当者 | なし | なし | なし | AIに環境がなければ実装する。採用した機能の送信先や個人情報の扱いを設定する | なし | 本番の設定を行い、公開する |
迷ったときの参照先
手元の状況に近いものから、該当する節を開いてください。
016工程のうち1
訪問者の目的を整理する
誰がどこから来て、何を知れば行動を決められるかを整理し、公開の条件を確かめます。
考え方
ページの目的は運営側がしてほしい行動で、訪問者の目的は行動を決めるまでに知りたいことです。両方を書き、訪問者の疑問を、行動を決めるまでの順に並べます。この順序が工程02の構成の元になります。
公開の条件、承認者、使う更新の仕組みもこの工程で確かめます。更新の仕組みに使える部品の制約があると、あとで構成を変える必要が出るためです。
推奨と理由
訪問者の疑問を、行動を決めるまでの順に並べる
理由運営側が伝えたい順に並べると、訪問者は答えを探して行き来することになり、途中で離れる原因になります。
公開の条件と更新の仕組みを最初に確かめる
理由更新の仕組みで作れない構成を選ぶと、デザインのあとで作り直しになります。
次へ進む目安
- 主な訪問者、来る経路、してほしい行動が、それぞれ一文で書かれている
- 訪問者の疑問が、順序つきで並んでいる
- 公開の条件、承認者、更新の仕組みが分かっている
具体例
料理教室の体験レッスンのページ
説明のための架空の例です。地域の料理教室が、料理を始めたい人に向けて、体験レッスンの申し込みページを作ります。このページは申し込みを目的にしているため、フォームを採用します。以降の工程でも同じ例を使います。
- 主な訪問者
- 料理を始めたいと考え、検索や地域の情報誌から来る人。
- 疑問の順序
- 初めてでもできるか
- 何を作るか
- いつどこで
- いくらか
- 何を持っていくか
- どう申し込むか
- 公開の条件
- 教室が使っているCMSで作り、運営責任者の承認を得てから公開する。
026工程のうち2
構成と見出しを作る
各セクションの目的、見出し、載せる内容、行動への導線を決め、ページの構成を選びます。
考え方
見出しだけを上から読んで、ページの内容と、最後にする行動が分かる構成を目指します。見出しの言葉の印象や覚えやすさが検討の中心になる場合は、ネーミング・コピーのガイドを参照します。
判断の材料は、疑問の順序、掲載できる事実、行動の入口の位置です。見出しだけで行動までの流れが読め、載せる事実が確認済みで、未確認の内容に印がある構成を合格とします。料金や日時など、掲載する事実の確認はこの段階で行います。
推奨と理由
見出しだけを抜き出して読む
理由本文と一緒に読むと、見出しが足りない情報を本文で補ってしまい、流し読みする訪問者に伝わらない箇所が見えません。
料金や日時などの事実は、構成の段階で確認する
理由事実が未確定のままデザインへ進むと、確定したときに分量や表の形が変わり、デザインを直すことになります。
次へ進む目安
- 見出しだけで、行動までの流れが読める
- 各セクションに目的があり、行動の入口の位置が決まっている
- 未確認の事実に印があり、確認先が分かる
具体例
料理教室の体験レッスンのページ
- AIの案
- 料金を冒頭に置く案と、「初めてでも作れる」ことを冒頭に置き、作る料理、日時と料金、持ち物、申し込みと続ける案。
- 人の判断
- 訪問者の最初の疑問に答える後者を選んだ。持ち物は教室に確認中のため、印を付けて進めた。
036工程のうち3
代表画面をデザインする
最初に見える範囲と、最も情報の多いセクションを代表としてデザインし、一案を選びます。
考え方
代表にするのは、訪問者が最初に見る範囲と、料金表や日程のように情報が多いセクションです。この二つで決めた文字の大きさ、余白、行動の入口の見せ方を、他のセクションの基準にします。
判断の材料は、狭い画面幅と広い画面幅の両方での見え方、正式なロゴと素材が使われているか、文字が画像に埋め込まれていないかです。最初に見える範囲で、誰に向けたページで何ができるかと、行動の入口が分かる案を合格とします。
推奨と理由
狭い画面幅から先にデザインする
理由訪問者の多くが携帯電話で見る場合、広い幅で決めた配置を狭い幅に押し込むと、読む順序が崩れます。
文字は画像に入れず、テキストとして配置する
理由画像の中の文字は、更新するたびに画像を作り直す必要があり、読み上げや検索でも扱えません。
次へ進む目安
- 狭い幅と広い幅の両方で、代表画面が描かれている
- 最初に見える範囲で、対象者、できること、行動の入口が分かる
- 正式なロゴと素材が使われている
具体例
料理教室の体験レッスンのページ
- 比べた案
- 大きな料理の写真を中心にした案と、教室の様子の写真に次回の日程を並べた案。
- 人の判断
- 最初に見える範囲で次回の日程と申し込みの入口が分かる後者を選んだ。写真は教室から提供された正式な素材を使った。
046工程のうち4
画面幅に合わせて実装する
既存の更新の仕組みやコードを使い、各セクションを画面幅に応じて実装し、リンクと、採用した機能をつなぎます。
考え方
既存の更新の仕組みを使うのは、公開や更新の手順、フォームなどの送信先がそこで管理されているためです。実装の前に、各セクションの目的、文章、リンク先、素材、画面幅ごとの表示を揃えます。フォームなどの機能を採用した場合は、項目と必須の有無、送信後の表示、送信先も決めます。
実装した側は、プレビューのアドレス、確認する操作、仮の部分、未実装の部分を人に渡します。動くプロトタイプのガイドの実装後に受け取る4項目と同じ考え方です。フォームがある場合、テスト中は実際の受付に届かない送信先にしておきます。
推奨と理由
フォームを置く場合は、仕様を送信したあとまで決める
理由送信後の表示や確認のメールの有無が決まっていないと、申し込んだ人が手続きが終わったかを判断できません。
フォームがある場合、テスト中は実際の受付とは別の送信先にする
理由確認のための送信が実際の申し込みとして受付に届くと、運営側の対応が必要になります。
次へ進む目安
- 全てのセクションが実装され、プレビューで開ける
- フォームなどの機能を採用した場合、テスト用の送信先までつながり、送信後の表示がある
- 仮の部分と未実装の部分が記録されている
具体例
料理教室の体験レッスンのページ
- 実装
- 教室のCMSのテンプレートを使って実装した。
- フォームの仕様
- 名前、連絡先、希望日（3つの日程から選ぶ）を必須にし、送信後に完了の表示と確認のメールを出す仕様にした。
- テスト中の送信先
- 制作用のアドレスにした。
056工程のうち5
プレビューで操作する
公開前のプレビューで、リンク、採用した機能、読む順序、画面幅による崩れ、キーボードでの操作を確かめます。
考え方
確認では、見出しの順に読み進め、ページの目的の行動まで操作します。全てのリンク、採用した機能の動き（フォームがあれば送信と送信後の表示、確認のメールを送る仕様ならその到着）、最も狭い画面幅（320px程度）と広い画面幅での表示、キーボードだけでの操作、画像の代替テキストを確かめます。
見つけた問題は戻り先を分けます。情報が見つけにくい、行動の入口に戻りにくいといった問題は、工程02の構成を直します。表示が崩れる、リンク先が違うといった問題は、工程04の実装を直します。
推奨と理由
最も狭い幅で、キーボードだけを使って行動まで進む
理由広い幅とマウスで確認すると、横へのはみ出しや、フォーカスが見えない箇所を見落とします。
問題を構成と実装に分けてから直す
理由構成の問題を実装の調整で直そうとすると、ボタンを足すたびに表示が崩れ、読む順序の問題は残ります。
次へ進む目安
- 全てのリンクが正しい先へ移動する
- 採用した機能が仕様どおりに動く。フォームがある場合はテスト用の送信先へ送信でき、送信後の表示が出る。確認のメールを送る仕様なら、そのメールが届く
- 320px程度の幅で、ページ全体が横にはみ出さない
- キーボードだけで、ページの目的の行動（申し込み、案内先への移動など）を完了できる
具体例
料理教室の体験レッスンのページ
- 構成の問題
- 申し込みの入口が料金の前にしかなく、料金を読んだあとにページを戻る必要があった。工程02に戻り、料金のあとにも入口を置いた。
- 実装の問題
- 狭い幅では日程の表が横にはみ出したため、実装を直して日程を縦に並べた。
- フォーム
- テスト用の送信先へ送信し、完了の表示と確認のメールが届くことを確かめた。
066工程のうち6
公開に必要な準備をする
掲載する事実の最終確認、承認、公開後の確認手順を揃え、案件の承認条件に従って公開します。
考え方
公開の前に、料金、日時、場所、連絡先などの事実を承認者と最終確認します。ページの名前、共有されたときに表示される説明と画像もここで設定します。フォームがある場合は、本番の送信先への切り替えも公開の準備に含めます。
公開するかどうかと、誰が公開の操作をするかは、案件ごとの取り決めに従います。公開したあとは、本番のページで短い確認を行います。本番のフォームに送信して確かめる場合は、運営側と方法を合意してから行います。
推奨と理由
公開後の確認の手順と担当を、公開の前に決める
理由公開してから手順を考えると、本番だけで起きる問題（送信先の切り替え忘れなど）に気づくのが遅れます。
次へ進む目安
- 掲載する事実が、承認者と最終確認されている
- 案件の承認条件に沿って承認を得ている
- 公開後の確認の手順と担当が決まっている
具体例
料理教室の体験レッスンのページ
- 承認
- 運営責任者が、料金、日程、確認が取れた持ち物を確かめて承認した。
- 公開
- 開発担当者がフォームの送信先を受付のアドレスに切り替えて公開した。
- 公開後の確認
- 運営と合意したうえで1件だけ送信し、受付に届くことと、確認のメールが送られることを確かめた。
成果を渡す先
制作の途中で、画像や言葉の検討を他のガイドへ渡すことがあります。渡すときは、そのページでの役割と表示される条件を添えます。
| 渡す先 | 渡すもの | 渡す時点 |
|---|---|---|
| ネーミング・コピー | セクションの目的と、見出しの候補 | 工程02で、見出しや行動を促す言葉の印象を複数の案で比べたいとき |
| キービジュアル・広告・SNS画像 | 表示される大きさと、重ねる文字の内容 | 工程03で、最初に見える範囲に使う主な画像が必要なとき |
| イラスト・画像素材 | 配置する場所と大きさ | 構成が決まり、セクションに使う挿絵や素材画像が必要なとき |
| UXライティング | フォームの仕様と、表示される条件 | フォームのエラーや送信後の表示の文言を見直すとき |
| 動くプロトタイプ | 構成と、確かめたい問い | 公開の前に、訪問者が行動を決められるかを試作で確かめたいとき |
| UI画面 | 必要な機能と画面の一覧 | 作るものが、利用者が繰り返し操作して作業を行う製品の画面だと分かったとき |
このガイドへ戻るとき
公開後に料金や日程などの事実が変わったときは、工程02で該当するセクションと見出しを見直し、工程05の確認を変わった箇所について行ってから、案件の承認条件に従って反映します。訪問者が行動を決める前に離れていそうなときは、工程01から疑問の順序を見直します。