レスポンシブ
1 つの HTML ソースで、画面幅(PC・タブレット・スマホ)に応じてレイアウトを自動変更する設計手法。CSS のメディアクエリで「ある幅以下になったら 2 カラムを 1 カラムにする」「メニューをハンバーガーに切り替える」といった見え方の切替を行う。PC 用とスマホ用で別 URL・別 HTML を持つ「セパレート型」に対する反対概念。
2010 年代後半以降、Google がモバイルファーストインデックス(MFI)でスマホ版を主評価対象にしたため、レスポンシブ実装はほぼ標準。スマホ版だけ情報量を削る設計は、SEO 上「コンテンツ不足」と評価される穴になりがちで、本書では PC ・スマホで本文の量を揃える方針を推奨する(Lesson 1-6)。
担当者が見るべきポイントは 3 つの幅(スマホ縦・タブレット・PC)で、それぞれヘッダ・ファーストビュー・ボタン位置・フォームが破綻しないか。実機(自分のスマホ)でのチェックが理想で、ブラウザのデバイスエミュレータは「ざっくり確認」用と割り切る。タブレット幅でレイアウトが半端になる事故は、デザインカンプだけ見ていると見落としやすい(Lesson 4-4)。
注意点は、レスポンシブ ≠ スマホ最適化。「画面が縮んで全部入る」だけで、スマホで指で押せる大きさ、片手で届く位置、入力負担の軽さまで考慮されていない実装はよくある。レスポンシブ実装の有無ではなく「スマホで CV が取れるか」を最終評価軸にするのが本書の立場。
言葉をよく利用する人
- デザイナー
- コーダー / フロントエンドエンジニア
- Web 担当者(発注側)
- ディレクター
会話上での使用例
業者から「PC 版優先で作って、スマホは後で」と提案された場面
-
業者ディレクター
まず PC 版のデザインを固めて、後でスマホにレスポンシブ展開します
-
Web 担当者
スマホ流入が 7 割なので、スマホ版を先に固めてから PC を作る順番でお願いします。MFI もありますし
-
業者ディレクター
了解です。スマホ縦のワイヤーフレームを最初に出し直します
実機チェックで担当者がコーダーに連絡する場面
-
Web 担当者
iPhone 実機で見たら、ファーストビューの CTA ボタンがキーボード呼び出し時に隠れます。レスポンシブの表示自体は崩れていないんですが、UX としてアウト
-
コーダー
了解。ボタンを sticky にせず、フォーム下に再配置します。タブレット幅でも崩れないか確認のうえ修正版を出します