目次 / 情報設計・仕様設計 / 仕様設計
ユーザ環境定義(マルチデバイス)
10秒でわかる!要点まとめ
-
「私のPCでは動きました」は通用しない。数千種類の端末での動作を保証する契約
-
アクセシビリティは「福祉」ではなく「品質」。検索エンジンも評価する重要指標
-
IEは終わったが、次は「古いスマホ(iOS/Android)」をどこまで切るかの決断が必要
1. 概要:サービスが利用される「場所」と「人」の範囲を決める
ユーザ環境定義とは、Webサイトやアプリが「どのようなデバイス(PC/スマホ/タブレット)」「どのようなブラウザ(Chrome/Safari等)」で閲覧されることを想定し、どこまで動作を保証するかを定める業務です。
さらに近年では、高齢者や障がい者を含むあらゆる人が情報にアクセスできるかを定めた「ウェブアクセシビリティ」への対応レベルも、ユーザ環境の一部としてここで扱います(何をどこまで約束するかは 033 ウェブアクセシビリティ を参照)。2024年4月の改正障害者差別解消法の施行により、民間事業者にも「合理的配慮の提供」が義務づけられました。Webサイトそのものへの直接の義務ではありませんが、企業姿勢を問われる領域になったため、「A・AA・AAAのどのレベルに準拠するか」を要件として明記する案件が増えています。「誰が、どんな環境で使っても、情報が正しく伝わる状態」をどこまで担保するか、プロジェクトの品質基準(非機能要件)を策定するプロセスです。
2. なぜ重要なのか:機会損失と社会的信用のリスク
もし「最新のiPhoneでしかレイアウトが崩れずに見られないサイト」を作ってしまったら、AndroidユーザーやPCユーザーという巨大な市場を捨てることになります。特にBtoBではまだ古いブラウザが使われていることもあり、ターゲットの環境を見誤ることは致命的な機会損失に繋がります。
また、Webアクセシビリティへの対応は、SDGsやコンプライアンスの観点から企業の社会的責任として求められています。文字が小さすぎて読めない、色が薄すぎて見えないといったサイトは、ユーザビリティが低いだけでなく、企業ブランドを毀損するリスクさえあります。
3. 実務のポイント:ブレイクポイントと「切る」勇気
実務では、無限にある端末すべてに対応することは不可能なため、現実的なライン引きが必要です。
-
ブレイクポイントの規定:レスポンシブデザインにおいて、横幅何pxでレイアウトを切り替えるか(例:SP=〜767px, PC=768px〜)を定義します。
-
サポート範囲の明記:「推奨環境(表示・動作ともに保証)」と「互換環境(表示は崩れても情報は読める)」を分けます。特に古いOS(iOS 15未満など)をサポート対象外にすることで、開発・検証コストを大幅に下げることができます。
-
アクセシビリティの基本:最低限守るべきラインとして「画像へのalt属性設定(音声読み上げ用)」「文字と背景のコントラスト比(見やすさ)」「タップ領域の確保(WCAG 2.2 では AA で 24×24 CSS px 以上、AAA で 44×44 px 以上)」などを仕様書に盛り込みます。
-
アクセシビリティの要件レベル:どこまでを約束するかは、必ず 033 ウェブアクセシビリティ を読んでから決めます。「準拠」と「配慮」は別物です。
4. スキルアップのヒント:Lighthouseとスクリーンリーダー
Google Chromeの検証ツールにある「Lighthouse」を使ってみてください。ボタン一つで、そのサイトの「アクセシビリティ」や「パフォーマンス」が点数化されます。これで100点を目指す修正を行うだけで、知識が身につきます。
また、スマホに標準搭載されている「VoiceOver(iOS)」や「TalkBack(Android)」といった音声読み上げ機能をONにして、目を閉じてWebサイトを操作してみてください。「画像にaltがないと何が起きるか」を体感することが、誰にでも優しい設計をするための第一歩です。
参考
関連
- yuheiy氏(PLAIDデザイナー)PLAIDデザイナーアドベントカレンダー
- デザインカンプで定義されないモバイル〜デスクトップの「間」をブレークポイント手動調整で埋めるのは保守性が悪い
- CSSのvw単位等で数値を線形変化させる「フルイドタイポグラフィ」で間を機械的に処理する
- Figmaのグリッドは静的な目安にとどめ、実装は内容に応じ調整する「コンテンツアウト」発想に転換する
- 元記事: https://yuheiy.com/blog/2025/designing-the-in-between/DiSAの紹介: https://note.com/disa_pr/n/nb04c4e41be92