今回、寄稿のお話をいただいた際の最初の切り口は「レスポンシブWebデザインについては検索してもさまざまなことが書いてあり、表示速度などを考えるとどれが正解か分からないから、ある程度技術的なガイドラインになるものがあるといい」ということでした。 ヒアリングを続けると、それは技術的な問題ではなく要件整理の段階で検討しておくことだな、というお話も多くありました。
そこで企画を2回に分け、「レスポンシブWebデザインを採用するにあたっての準備」として前回の記事『「レスポンシブWebデザインで行こう!」の、その前に』を書かせていただきました。
技術だけでは成功しない要素がたくさんあるので、本記事の前にぜひ前編もご覧ください。
本編はその2つ目となる「ある程度技術的なガイドラインになるもの」を目指します。
いざ着手してみると「情報が多くて何をどこまでやったらいいのか分からない」となりがちなレスポンシブWebデザインについて、制作の現場はどう対応しているのか、ディレクションと制作技術のポイントをご紹介します。「この辺りが標準的な対応かな」という判断の指標にしていただけると嬉しいです。
まずは、ディレクション(進め方)で押さえておきたいポイントを2つご紹介します。
「対応デバイス/ブラウザ」の決め方
前回の記事でも触れましたが、レスポンシブWebデザインは、あらゆるスクリーンサイズで一定の優れたUXを提供するために汎用化する技術です。
「どのサイズでも見られる」ように作る方法なので、きちんと「対応デバイス/ブラウザ」を定義しておかないと、あらゆるデバイス/ブラウザが対象になってしまうことになります。
よくある例が、
- スマホとPCの対応でいいと言われた(思っていた)が、タブレットの対応も必要で、予算もスケジュールも厳しい状況になった
- 「うちの子がゲーム機でサイトをみたらメニューが開かなかったよ」と言われて頭を抱えた
などです。
さらに、「対応デバイス/ブラウザ」を決めるだけでは十分ではありません。「メジャーなデバイスに対応」と言っても、全てを実機で確認することは(専用サービスを利用しない場合は)できないからです。 「特定のデバイスで表示が変だ」と報告があっても、そのデバイスが手元にないと再現ができないため、修正することは困難です。
「仕様上の対応デバイス/ブラウザ」と「検証するデバイス/ブラウザ」を定義する
このような状況でもプロジェクトメンバー間に認識のズレが出ないよう、私たちは「仕様上の対応デバイス/ブラウザ」と「検証するデバイス/ブラウザ」の2つを定義するようにしています。
仕様上の対応デバイス/ブラウザ
「仕様上の対応デバイス/ブラウザ」は、Web標準で定められた仕様に沿っていれば、問題なく表示・動作するであろうと思われるデバイス/ブラウザを指します。
案件では、アクセス解析を元にターゲットとするものが「仕様上の対応デバイス/ブラウザ」になります。特殊な環境・仕様でなければ対応できます、という範囲ですね。
検証するデバイス/ブラウザ
「検証するデバイス/ブラウザ」は、実際に表示と動作を検証するデバイスとブラウザです。多くの場合、制作チームまたは個人が所有するデバイスが検証機になります。時にそれは実機ではなくエミュレーターの場合もあります。
弊社ではAndroidの所有率が低いので、Androidの確認にはエミュレーターを指定します。IEの場合も、IE10以下は各種ツールを使って検証をすると定義します。
そして大事なのは、「検証するデバイス/ブラウザ」での表示・動作が問題なければ、試験(テスト)はクリアとする、という合否ラインを共有することです。
もちろん定義されたもの以外で何か症状があり、それを再現できる場合は可能な限り対応をしますが、その優先度は低く、次のステップに進むことを止めるものではないという扱いになります。
モバイルファースト/デスクトップファースト
レスポンシブWebデザインでの制作時に、モバイルを基準にコンテンツや操作性を設計する方法を「モバイルファースト」、デスクトップを基準にする方法を「デスクトップファースト」と表すことがあります。
モバイルファーストを意識する
モバイルファーストでは、小さな画面の中でいかに重要なメッセージを伝え、分かりやすいステップで操作に支障なく手続きを完了してもらえるかということを重視して設計するため、レスポンシブWebデザインで課題となりがちな、モバイル閲覧時の次のような症状を回避することができます。
- コンテンツ分量がモバイルで見るには多すぎる(精査がされていない)
- どこを押せば目的のページに行けるか分からない(遷移設計がモバイルに合っていない)
また、設計の流れのままモバイルサイズのデザインを先行させると、デザインがモバイルに合っていない(見にくい)といったことも起こりません。
デスクトップサイズはスクリーンが広いため、思いつく限りの情報を詰め込みがちです。情報量が多いことは良いことのように思えますが、整理されていない情報はユーザーを混乱させる可能性も高く、たとえデスクトップで閲覧しても「分かりにくい」かもしれません。
このように、モバイルファーストの考え方はデスクトップでの見やすさや操作性を犠牲にするものではなく、Webサイト全体の質を高める重要な考え方だと言えます。
必ずしもモバイルサイズから設計しなくてもいい
モバイルファーストの考え方をダイレクトに制作工程に反映した場合、モバイルサイズで作成した設計やデザインをデスクトップサイズに展開するフローになります。
このアプローチは制作工程として理にかなっていますが、プロジェクトメンバー間での合意形成が難しいため、特に関係者が多いと進行が止まりがちです。
「モバイルファースト=モバイルサイズから設計しなければいけない」という考え方もありますが、デスクトップサイズから設計しても、並行してモバイルでの見え方・操作性を意識していれば、モバイルファーストの考え方を取り入れることはできるもの。そのため私たちは必ずしもモバイルサイズから設計しなくてもいいというスタンスで取り組んでいます。
なお、デスクトップサイズから設計する際は、次の点に注意するとより安心です。
- ナビゲーションを設計する際は、デスクトップサイズとモバイルサイズを並行して作成・レビューする
- ワイヤーフレームは、モバイルで実寸操作できるものを用意する(モバイルサイズ版は、ナビゲーション部分を含む数画面を作成)
- コンテンツエリアは、グリッド構造(ブロックを積み上げてレイアウトを構成する仕組み)を意識して要素の配置を決める
ここまでは、プロジェクトの進行に関してディレクションのポイントを2つご紹介しました。
曖昧になりがちな「対応デバイス/ブラウザ」の定義の仕方や、結果として表示速度にも影響する「モバイルファースト」の取り入れ方について、参考にしていだけたら嬉しいです。
次回以降、より具体的に、制作フェーズで課題となりがちな「表示速度の改善」と「画像の取扱い」について、技術的なガイドラインとなるものをご紹介したいと思います。