サイト改善案が増えたら？根拠・保留・変更後の確認を一つずつ結ぶ

改善したいことを、画面の事実と仮の理由に分ける

案ごとに、読者がしたいこと、実際に確認した画面や記録、社内の提案、まだ分からないことを分けます。「こう変えたい」を、そのまま原因や効果の証明にしません。

改善仮説とは、困りごとが起きた理由や、変更でどう変わるかについての、まだ確かめていない見立てです。たとえば「相談入口の近くに対応地域の案内がないことが迷いにつながった可能性」と、「地域の案内を近くへ置く案」は、理由の見立てと変更の案として分けます。

英国GOV.UKの利用者のニーズを調べる手引きでは、既存資料、利用者の観察、現場担当の話などから学び、利用者から出ていない意見や提案は調査で確かめる仮定として扱います。英国行政サービス向けの説明ですが、社内の意見を利用者の実態と混ぜない考え方を参考にできます。

営業担当から「フォームが長いかもしれない」と言われたときも、その提案を記録し、現フォームの内容と必要性を調べます。入力欄を見ていない段階で「長いフォームで離脱している」と書き換えると、未確認の原因を決めてしまいます。

改善箇所が多く時間と予算が限られるという担当者の本人相談や、調査中に早く画面案を求められたという別の担当者の本人投稿もあります。過去の別々の相談で、この記事の会社や改善結果を示す資料ではありません。

地域案内とフォームの二案で、次に確かめる内容を決める

地域案内の案は、現行文と質問を記すメモを読み、掲載できる地域を事業担当へ確認します。フォームの案は、実際の項目と利用状況を調べる段階です。どちらも変更後の成功例ではありません。

ここからは、同じ架空の設備点検会社に届いた、別ページの二つの改善案を扱います。実会社のサービス条件、実顧客の発言、実際の利用調査を示したものではありません。

二つの改善案があるとき、何を確かめてからページを変える？現行文とメモの関係、未確認の条件、次に確認する相手を別々に読みます。

原寸画像を開く

地域案内は事業担当に掲載条件を確認してから原稿案へ進みます。フォームは現項目と利用実態を確かめるまで、短くする変更を保留します。二つの案に同じ「修正する」の印を付けず、次の確認を具体化します。

地域案内の案：まず掲載できる条件を聞く

1. 見た場所とメモをそろえる。

   同じサービス案内の現行文と、質問を記すメモを並べます。「近くに案内がない」という観測を、全サイトのどこにも書いていないという判断へ広げません。質問の背景が記録されていなければ、その点も残します。

2. 事業担当に公開できる地域と条件を確認する。

   実際に対応できる範囲と、案内へ書いてよい条件を確かめます。地域名や例外条件を、Web担当が想像して補いません。現記録には具体的な地域名がないため、この記事にも掲載済みの地域案内は作っていません。

3. 確認後に変える場所を具体化する。

   承認された案内を相談入口の近くで読めるようにする、という変更案を制作担当と検討します。読者が相談前に対応地域を判断できるかを、変更後に確かめる対象にします。案を作ったことと、変更の承認・公開は別です。

フォームの案：項目の必要性と利用実態へ戻る

まず現在のフォームを開き、項目ごとに何を判断するための情報かを、相談を受ける実務担当へ確認します。相談への返答に必要な情報か、後から確認できる内容か、用途が分からない項目かを、実際の欄に沿って検討します。

その上で、利用者がどこで迷うかを見る必要があるか、利用目的と権限を確認した集計を調べる必要があるかを決めます。社内の提案だけから、実際に長い、特定の欄が不要、項目を減らせば相談が増える、という結論には進めません。

公開できる条件を確かめ、調査・保留・変更を分けて進める

確認不足の案には、次に聞く内容と相手を付けて変更を保留します。条件と根拠を確認できた案は、承認された対象へ絞って原稿や画面を変えます。案の多さだけで、一括変更へ進めません。

二つの案を同じ確かさで並べないことが、次の行動を決める出発点です。この架空例では、地域案内の案は事業条件への照会、フォームの案は現状と利用実態の確認が必要です。どちらの変更を先に公開するかは、その確認結果と読者への影響、実施できる範囲を踏まえて決めます。

この例での進め方：地域の掲載条件を事業担当へ照会し、その回答を待つ間にフォームの現項目を確認する、といった進め方ができます。これは確認作業の組み方の例で、地域案内の変更を必ず先に公開する、という順位の決定ではありません。

制作担当への依頼は、「問い合わせを増やすように全部改善する」より、「事業担当が確認した地域条件を、相談入口の近くで読める案内へする。その後、相談前に対象地域を判断できるか確かめる」のように、対象・理由・条件・確認する用事をつなげます。現記録では承認内容が未確認なので、これは確認後に具体化する依頼の考え方です。

フォームも、用途を確認した後に必要な変更範囲を決めます。項目の数だけを目標にせず、相談への返答に必要な情報を受け取れるか、入力時の説明は足りるか、入力後の扱いが合っているかを担当と確かめます。今回の記録から実際の項目名や数を作ることはできません。

実際に送信できないなどの不具合が別に確認された場合は、その対象と影響を担当へ伝え、通常の改善案の検討と分けて扱います。仮説の検討だけを理由に既知の不具合を放置するものではありません。今回の二つの記録には、送信不能を確認した結果はありません。

変更後は同じ用事で確かめ、新しい事実で案を見直す

変更した箇所を開き、最初に挙げた読者の用事がどう進むかを確認します。公開できたことと、読者が判断・入力できたこと、相談の成果は分けて評価します。結果がなければ未確認のまま残します。

変更前に、対象ページと現行文、確かめたい用事、何が分かれば判断できるかをそろえます。変更後も、その用事と対象へ戻ります。ページの版、使った端末や画面、質問の仕方などが変わった場合は、その違いを結果と一緒に残します。

GOV.UKの使いやすさを比較する手引きでは、利用者が課題を進める様子を見て、後の回でも課題や質問の一貫性を保つことを説明しています。ここでは同じ用事で確かめ直す考え方を参照しています。同手引きの参加人数や課題数を、すべての企業サイトに必要な数として当てはめません。

同じ人が答えを覚えた後の確認と、初めて読む人の確認は条件が異なります。対応地域そのものが変わった場合も、文章の配置だけを変えた場合とは分けます。変更後に質問が減ったとしても、利用者や時期、案内内容などの違いを調べずに、その変更だけが原因と決めません。

内容の伝わり方を詳しく調べる質問や記録の方法は、記事をユーザーテストで確かめる記事へ進めます。本稿は、複数の案について根拠と公開条件を分け、次に確かめる内容を取り違えないことに絞っています。

新しい質問や条件が出たら、同じ案の根拠へ戻る

新しい質問、現フォームを確認した結果、サービス条件の変更があれば、案と次の行動を見直します。地域案内を作ったという作業記録だけを残さず、承認した内容、公開ページでの確認、読者の用事の結果を区別します。効果が分からない場合は、何の情報が足りないかを次の確認へつなげます。

クリックやスクロールの資料から調べる場所を選ぶ方法は、ヒートマップの種類と読み方の記事で扱います。SEOの数字と相談などの結果の区別は、SEOの効果を測る記事で確認できます。今回の二案には、離脱率や変更後の成果値はありません。

まとめ：一つの案から、次に確かめる内容と相手を決める

改善案は、読者の用事と、確認できた根拠に結び付けます。未確認の掲載条件や原因は残し、調査すること・保留する変更・承認後に変える箇所を分け、変更後は同じ用事で確かめます。

架空のサービス案内には「ご相談ください」という現行文と、近くに地域案内がない観測、質問があったというメモがあります。フォームの案は営業からの提案で、項目も利用実態も確認していません。同じ会社の別の案であり、片方を直した後の結果ではありません。どちらも掲載・変更の承認、変更の実施、変更後の同じ用事の結果は未確認です。

最初の行動：いま届いている改善案を一つ選び、対象ページの現状と、案が出た根拠を並べてください。分からない掲載条件か現状を一つ挙げ、「誰に、何を確かめるか」を決めます。回答が必要な変更は保留し、確認できた内容から具体化します。

確かさの異なる案を同じ「すぐ修正する」にまとめず、次の確認と公開の条件へ結び付けると、案が増えたときも一件ずつ見直せます。この記事は実施済みの改善効果や、国内の検索量を示すものではありません。

サイト改善案の根拠と、確認する範囲を相談する