レスポンシブデザインを確認する方法

レスポンシブデザインのチェックリストで確かめたいのは、異なる画面サイズでも作業を完了できるかです。整ったモバイルのスクリーンショットは有用な証拠ですが、メニューを閉じられるか、比較の意味が保たれるか、送信ボタンがキーボードに隠れないかまでは分かりません。

タスクから始め、実行しながらレイアウトを確認します。マーケティングページなら、内容を理解し、プランを比べ、次の手順を見つけることかもしれません。製品の画面なら、レコードを探し、一つの値を変え、結果を確かめることかもしれません。画面幅を変えても同じタスクを使えば、どの変更が助けになり、どれが問題を別の場所へ移しただけかを見分けられます。

問題を見つけられるページを用意する

意味のある確認になるよう、十分な種類の要素があるページを選びます。ほぼ空のランディングページは簡単に通っても、料金ページは崩れるかもしれません。ナビゲーション、ある程度長い見出し、画像、繰り返す内容、重要な操作があるものを選びます。フォームやデータテーブルがあるサイトなら、それらを含むページも対象にします。

都合よすぎるサンプルは、確認前に置き換えます。「Team」というカード名では、「Regional operations and customer support」と同じ問題は出にくいでしょう。現実的な説明文、通常使う中で最も長いナビゲーション名、被写体が片側の端にある画像を使います。ばかげた内容で無理に壊すのではなく、確認用の入力を用意するのです。

何ができる必要があるかを書きます。架空のワークショップ予約ページなら、日付を読み、会場を理解し、開催回を比較し、予約を始められる必要があります。狭い画面で場所を節約するため会場を隠したら、見た目がすっきりしても、タスクに必要な情報を失っています。

確認する幅を決め、その間も見る

デスクトップ、タブレット、モバイルのプレビューは、実用的な出発点です。ただし、ページが遭遇する条件のすべてではありません。サイズ変更できるブラウザー、タブレットの分割表示、拡大したページでは、どの端末プリセットにもない幅になります。

狭い幅、中間、広い幅の確認点を決めます。具体的な数字より、対象者に関係する条件を含むことが重要です。最初は、例えば360、768、1440 CSSピクセル前後を確認し、その間をゆっくり変えられます。

構造が変わる直前を、とくに見ます。広い確認点では余裕があり、狭い確認点では正しく折りたたまれるヘッダーでも、切り替わる直前には窮屈になるかもしれません。三列のセクションが、中間幅で親要素より広い場所を必要とすることもあります。問題は、ブレークポイントそのものより、その手前に出ることがよくあります。

web.devのレスポンシブデザインのガイドは、端末名ではなく、内容の必要性に合わせてレイアウトを変えるよう勧めています。コンポーネントを無理なく使うことができなくなる最初の幅を記録して、この考え方を使いましょう。変更の理由と、修正後に再確認する場所が得られます。

参考例：読む作業を保つGOV.UK

GOV.UKのレイアウトの指針は、小さい画面では一列から始め、広いページの多くでは、読む内容に3分の2の列を勧めています。公式の3分の2／3分の1の例では、狭くなると同じ内容が縦の順序になります。

借りるべきなのは比率ではなく、関係です。主な説明が先にあり、補足が続きます。自分のページでは、支払い前に必要な法的条件がサイドバーにきれいに収まるからといって、補足情報になるわけではありません。優先順位を下げるレイアウトをまねる前に、役割を決めます。

これなら、「列が縦に並ぶ」より鋭い確認ができます。補足列の一文を選び、どの操作の条件になっているかを特定します。縦にした後、その一文を見ないまま操作に出会うことはないでしょうか。あるなら、幾何学的には正しくても、情報の伝え方として間違っているかもしれません。条件を操作と一緒に移すか、依存する関係を明示します。

キーボードでページをたどるのも有用です。見た目を並べ替えても、ソースの順序は変わらないことがあります。画面では説明の後にある操作へ、説明より先にフォーカスが届くなら、レイアウトと読む順序の両方を確認する必要があります。スクリーンショットだけでは、この不一致は解決できません。

タスクに基づいてレスポンシブをテストする

次の確認項目を記録の出発点にし、ページにない行は削除します。レビュー前に期待する結果を書きましょう。見た後では不具合を正当化しがちです。以下はテスト条件で、すべてに使うブレークポイントの設定ではありません。

すべての観察を、一つの合格率にまとめてはいけません。装飾用の図注が切れることと、支払い操作に到達できないことは、同じ失敗ではありません。まずタスクを阻む問題、次に誤った情報や欠けた情報、その後に読みやすさと見た目を直します。未完のレビューですべての端末への対応が証明されたふりをせず、小さなチームでも現実的な公開判断ができます。

実際に使いながら、ページをたどる

ナビゲーション：開く、選ぶ、閉じる、開き直す

レイアウトによって変わるナビゲーションの操作を、すべて開きます。アイコンが完璧に揃っていても、開いたパネルが使えない場合があります。開いた状態を見て、移動先を選び、閉じ、また開きます。階層があるなら、一段目だけで終えず深い項目も試します。

ワークショップの例なら、広いヘッダーにはSessions、Speakers、Venue、Book a placeがあるかもしれません。狭い表示では最初の三つがパネルに移ります。Venueが残っているか、ラベルが読めるか、パネルを閉じると透明なオーバーレイが邪魔せずページへ戻れるかを確認します。

メニューと画面全体の関係にも注意します。背の高いパネルには独自のスクロールが必要かもしれませんし、ページのスクロールを許す必要があるかもしれません。どの方法でも、最後の項目と閉じる操作に到達できるべきです。画面の高さが十分なときしか使えないパネルも、レスポンシブの問題です。

キーボードで同じ作業を繰り返します。レイアウトの変更で操作が取り残されたり、現在のフォーカスが隠れたりしていないかを確かめます。修正の対象を絞れるよう、問題が起こる正確な手順を記録します。

読む順序：モバイルでの流れを追う

列が一つの縦並びになるときは、読む順序を改めて見直します。デスクトップで頼っていた位置関係が、なくなるかもしれません。説明の横にあった価格が、説明から数画面分離れることもあります。画像のキャプションが、前の画像でなく次の画像の説明に見えることもあります。

デスクトップの配置を見ずに、狭いページを上から読みます。各セクションが、次を理解する準備になっているかを考えます。予約ページでは、開催回を選ぶ前に、その詳細が必要です。選択と説明の間に大きな装飾画像があると、操作が切り離されて感じられます。

デスクトップで左右を交互にするセクションには注意します。画像が左・文が右の次に、文が左・画像が右が続くと、ソースを単純に縦積みしたモバイルでは順序がばらつきます。画像が文章を導入するのか、後から例示するのかを決め、同じ役割の内容では関係を揃えます。

はみ出し：隠す前に原因を特定する

ページ全体をスクロールし、コンテナを越える内容を探します。ボタンの文言の欠け、画面から出るカードの端、隣の内容を押し出すフッターリンクなどが手がかりです。オーバーレイや展開した内容も見ます。通常は収まっていても、開いた操作は収まらないことがあります。

意図しないはみ出しと、意図したスクロール領域を分けます。 幅の広い比較表が、自分の領域内で横スクロールするのは妥当かもしれません。一つの大きすぎるイラストで、ページ全体が横に動くのは別の問題です。横スクロールを意図するなら、先にも内容があると気づけて、何を読んでいるかを見失わない必要があります。

全体にはみ出し非表示の指定を付けただけで、修正完了にしないでください。外側はきれいでも、原因だった項目が切れることがあります。まず責任のある要素を特定し、幅、折り返し、位置、コンテナのどれを変えるかを決めます。変更後は、役立つ内容が単に消えていないかを確認します。

ワークショップのページに、長い会場名が入るチケットカードがあるとします。役立つ修正は、名前を折り返してカードを伸ばすことかもしれません。カードの文字をすべて小さくしても収まりますが、原因でない情報にまで読みづらさを負わせます。

切り抜きごとに、画像の意味を確認する

画像は、枠に収まっていても伝達に失敗することがあります。形が変わった後、何が残るかを見ます。入口を示すなら、入口が見える必要があります。機能を説明するなら、その画面の関連部分が、判別できないほど小さくなってはいけません。

写真なら、被写体を保ちながら切り抜きを変えられるかもしれません。操作説明のスクリーンショットでは、ラベルを切ると説明が失われます。別々の判断が必要です。狭く切り抜く、別の画像にする、専用の大きな領域にする、そのどれを選ぶかは、画像の目的から考えます。

周囲の文章も確認に使います。「強調した開催回を選ぶ」とあるのに、表示サイズでは強調が見えないなら、その画像は文章を支えなくなっています。全画面を縮めるより、該当する操作の拡大が役立つかもしれません。

元の寸法だけでなく、実際に配信された画像を見ます。高解像度でも小さく表示すれば読めません。 適切な表示サイズでも、違う画像バリエーションが読み込まれていればぼやけます。どちらを観察したかを記録します。実装する人が、配置を変えるか、画像を変えるかを選びやすくなります。

判断材料と操作を、一緒に保つ

レスポンシブな配置でも、情報と、それを使って判断する操作のつながりを保ちます。料金なら、プラン名、関連する制限、価格、操作が一つの選択肢として識別できること。予約フォームなら、最後の操作に到達したときも、選んだ開催回が明確なことです。

繰り返しのボタンは丁寧に見ます。親のカードが視覚的に分断されると、同じ「続ける」が三つある場合は混同しやすくなります。まとまりの強化、明確なプラン名、より説明的な操作名が必要かもしれません。すべてに強い装飾を足すより、最小限の変更で関係を取り戻すことから始めます。

ラベルが折り返す状態も試します。二行のボタンでも、余白、整列、隣の操作との関係が保たれていれば問題ない場合があります。大切なのは、行動を見分け、無理なく操作できるかです。最初の一語で切れるラベルは、少し背が高くなるボタンより重大な失敗です。

固定表示の要素も含めます。予約の固定バーは主な操作を使いやすくしますが、価格の注記や最後の入力欄を覆うかもしれません。最下部へスクロールし、セクションを展開し、入力欄にフォーカスします。仕上がった冒頭の一枚だけでなく、こうした状態でも、占める場所に意味が必要です。

状態が変わった後のフォームを試す

フォームは操作で内容量が変わるので、別に確認する価値があります。エラー文、選んだ項目、確認の通知で、高さや入力欄の関係が変わります。空欄だけを見るのではなく、現実的な入力と、少なくとも一つの修正可能なエラーで確認します。

可能なら実機の狭い画面で、画面上のキーボードを出します。入力中の欄が見えるか、次の操作へ到達できるかを確かめます。デスクトップのプレビューは配置の確認に役立ちますが、すべてのモバイルブラウザーのキーボードとビューポートの扱いまでは証明しません。

通常認められる欄では、長い値も使います。正式な組織名、複数の部分がある姓、長いメールアドレスなら、短いサンプルで見逃した欠けが分かるかもしれません。見た目のレビューで入力ルールを変えることが目的ではありません。受け付けた入力が、画面で理解できるままかを確かめます。

エラー後も、何を直すかが伝わることを確認します。ほかのセクションが動いたために、エラーと入力欄が離れてはいけません。要約を使うなら、個別の欄とのつながりも確認します。適切な担当者が対応できるよう、配置、文言、フォーカス、実際の入力確認のどの問題かを記録します。

収まりの問題と、内容の問題を分ける

レスポンシブの不具合に見えても、場所不足でなく内容の不明確さが原因の場合があります。見出しを繰り返す段落で、モバイルのページが無用に長くなるかもしれません。六つの操作が並ぶのは、優先順位が未決だからかもしれません。圧縮する前に、それぞれの内容に明確な役割があるかを考えます。

ほかには、明らかにレイアウトの問題もあります。現在の部品が硬直的だからといって、重要な条件を削るべきではありません。構成が複雑になっても、予約の取り消し条件は不可欠かもしれません。いつ必要かに応じて、場所を変える、展開する説明にする、縦の余裕を増やす、といった対応が考えられます。

どの幅でも情報が必要か、という区別が役立ちます。必要なら、表現を改善します。今のタスクや状態によって本当に関連性が変わるなら、条件付き表示が適切かもしれません。すべての端末で同じ判断を支える情報を、幅だけを理由に消すのは根拠が弱いのです。

MDNのレスポンシブデザインの概要は、柔軟なレイアウト、メディア、タイポグラフィ、ビューポートの振る舞いを組み合わせるものと説明しています。修正を割り当てるときに有用です。小さい画面の一つの失敗は、ページ全体を作り直す必要を意味しません。

観察を、小さく検証可能な修正に変える

一つの指摘は、一つの失敗に絞ります。コンポーネント、条件、期待する振る舞いを示します。例えば「中間幅のプレビューで、VenueとBook a placeが重なります。接触する前にヘッダーを折りたたみ、ラベルと予約先は維持してください」。「タブレットのレイアウトをよくして」より有用な依頼です。

OpenDesignを使っているなら、デスクトップ、タブレット、モバイルのプレビューから比較を始められます。コメントやチャットで観察を伝え、更新後のHTMLを見ます。必要な変更が具体的なら、対応するテキスト、リンク、画像、スタイルの手動編集も役立ちます。

構造を変えるなら、維持するものを示します。ヘッダーの別配置が必要なら、内容と移動先は固定して修正します。画像の切り抜きが必要なら、同時に周囲の文章まで変えないようにします。変数を揃えると、記録した問題が解決したか判断しやすくなります。

失敗した条件を先に試し直し、その後、近隣の幅と関係する状態を見ます。一つの幅で収まる修正が、別の幅のヘッダーを窮屈にするかもしれません。ボタンが高くなり、固定高のカードの問題が出るかもしれません。この短い回帰確認は、任意の仕上げではなく、元の修正の一部です。

別の人が使える確認記録で終える

レスポンシブの確認を完了とする前に、各確認点で主な作業を最初から最後まで繰り返します。読み、操作を開き、結果に到達します。その後、配置が変わる確認点の間の幅を、少なくとも一つ見ます。きれいな静止状態を三枚だけでなく、重要な展開状態や開いた状態の証拠を残します。

最後のメモは短くてかまいません。どのページ、幅、ブラウザーを確認し、どの作業が成功し、どの条件が未確認かを示します。実際のモバイル端末がなければ、その点を伝えます。テーブルを意図して横スクロールさせるなら、次の担当者が見落とされた不具合と誤解しないよう、その判断を記します。

残る問題は、何を妨げるかで優先順位を付けます。隠れた操作や読めない必須条件は、タスクを止めます。不自然でも読める見出しは、通常それより後です。見た目の品質を軽く扱うのではなく、細かな仕上げで、利用を止める問題が埋もれないようにします。