ウェブページを開いたとき、私たちの目には数秒、あるいは一瞬のうちに文章、画像、ボタン、メニュー、背景などが表示されます。しかし、ブラウザはサーバーから受け取ったHTMLをそのまま画面へ貼り付けているわけではありません。実際には、HTMLを解析してページの文書構造を作り、CSSを解析して各要素へどのような見た目を適用するかを判断し、さらに「どの要素を本当に画面へ表示する必要があるのか」を整理したうえで、位置や大きさを計算し、文字や画像を描画しています。利用者からは一瞬に見える処理の裏側で、ブラウザは複数の段階を非常に高速に実行しているのです。

その一連の処理の中で重要な役割を持つのが、レンダーツリーです。レンダーツリーは、HTMLから作られる文書構造とCSSから作られるスタイル情報を組み合わせ、実際に画面へ描画すべき要素を整理するための構造です。つまり、HTMLやCSSという「ソースコードの世界」と、利用者が実際に見る「画面の世界」をつなぐ重要な中間地点と考えることができます。

ソフトウェアテストというと、「テストケースを作成する」「テストを実行する」「自動化する」といった工程に注目しがちです。しかし、実際の品質保証では、テストを実行したこと自体よりも、実行によって得られた結果を何と比較し、どのような条件を満たせば正常と判断するのかという部分が非常に重要です。どれだけ大量のテストケースを実行していても、合否判定基準が曖昧であれば、本来検出すべき不具合を正常として扱ってしまう可能性があります。

例えば、ECサイトで「商品を購入する」というテストを実行し、購入ボタンを押した後にHTTPステータス200が返ってきたとします。通信という観点だけを見れば成功しているように見えます。しかし、注文金額が誤って計算されている、在庫が減っていない、クーポンが正しく適用されていない、決済処理だけ失敗している、同じ注文が二重登録されているといった状態であれば、ビジネス上は明らかに正常な購入処理とはいえません。

つまり、テストでは「処理が動いたか」だけでなく、「処理後の状態が本当に正しいか」を判断する必要があります。その判断を支える考え方が、**合否判定基準（Test Oracle：テストオラクル）**です。

ECサイトの売上を改善しようとすると、アクセス数や購入率へ意識が向きやすくなります。より多くのユーザーをサイトへ呼び込み、その中から購入する人を増やせば売上は伸びるため、この考え方自体は間違っていません。しかし、売上を構成する要素は集客と購入率だけではなく、一回の注文でどれだけの金額が購入されているかも大きく影響します。同じ1,000件の注文でも、一回あたり5,000円購入される場合と7,000円購入される場合では、売上全体に大きな差が生まれます。

この一回の注文あたりの平均購入金額を確認するために使われるのが、**平均注文額（AOV）**です。例えば月間売上が500万円、注文数が1,000件であれば、平均注文額は5,000円になります。注文数を増やさなくても平均注文額が6,000円まで上昇すれば、同じ1,000件の注文でも売上は600万円になります。そのため平均注文額は、新しい顧客を獲得するだけではなく、現在すでに購入意向を持っているユーザーから生まれる一回の注文価値を理解するための重要な分析軸になります。

ECサイトの商品検索では、ユーザーが商品データベースに登録されている正式な商品名を正確に入力してくれるとは限りません。検索時には、一文字の入力ミス、文字の抜け、カタカナとひらがなの違い、全角と半角の違い、ブランド名の英語表記とカタカナ表記、一般的な略称、ユーザー自身の記憶違いなど、さまざまなズレが発生します。特にスマートフォンからの利用では、小さなキーボードによる入力ミスも発生しやすく、ECサイト側が「正しい商品名を入力できること」を前提に検索機能を設計すると、本来見つけられるはずの商品が検索結果に表示されないケースが増えてしまいます。

例えば、商品データ上では「ワイヤレスイヤホン」と登録されているのに、ユーザーが「ワイヤレスイヤフォン」と入力しただけで検索結果が0件になれば、ユーザーから見ると「このサイトには欲しい商品がない」ように見えます。しかし実際には商品が存在しており、検索システムがユーザーの入力と商品データの小さな差を吸収できていないだけかもしれません。ECサイトでは、このような検索失敗がそのまま商品発見の失敗につながり、さらに検索離脱、サイト離脱、購入機会の損失へつながる可能性があります。

ユーザーが画面上でボタンを押した直後に何も変化しなければ、「押せていないのではないか」「もう一度押した方がよいのか」「処理が止まったのか」と迷い始めます。保存操作の後に完了表示がなければ、本当に保存されたのか確認するために同じ操作を繰り返すかもしれません。長い処理で残り時間も進捗も分からなければ、正常に動いているのか、それとも停止しているのかを判断できません。このような問題は、機能そのものが壊れているから発生するとは限らず、システム内部では正しく処理されているものの、その状態がユーザーへ伝わっていないことによって発生します。

UI設計では、ユーザーが行った操作に対してシステム内部で何が起きているのかを、適切なタイミングと粒度で外部へ表現する必要があります。操作を受け付けた、処理を開始した、処理中である、何％まで進んだ、完了した、失敗した、再試行が必要である、現在は操作できない、といった状態が明確であれば、ユーザーは画面を推測しながら操作する必要がありません。反対に、状態が見えないUIでは、一つひとつの操作についてユーザー自身が「今どうなっているのか」を考えなければならず、認知負荷、不安、誤操作、重複操作などが増加します。

プロダクト開発におけるプロトタイプは、完成画面の見本を作るためだけのものではありません。本来は、実装へ大きなコストを投入する前に、現在の設計に残っている不確実性を具体的な形で検証するための手段です。そのため、プロトタイプを作る際には「できるだけ完成形に近づければよい」と考えるのではなく、何を確かめたいのかに応じて、必要な忠実度を選択する必要があります。

要件、情報構造、画面遷移などがまだ大きく変わる可能性がある段階では、低忠実度プロトタイプを使った方が効率的です。一方、基本的な画面構成や主要なユーザーフローが固まり、「実際のUIに近い状態でユーザーが操作できるか」「視覚的な優先順位は適切か」「エラーやLoadingなどを含めて体験が成立しているか」といった、より具体的な問題を確認したい段階では、低忠実度だけでは十分な情報を得られません。

この段階で有効になるのが高忠実度プロトタイプ（High-Fidelity Prototype / Hi-Fi Prototype）です。高忠実度プロトタイプでは、実際のカラー、タイポグラフィ、画像、アイコン、コンポーネント、コンテンツ、画面遷移、場合によってはアニメーションやマイクロインタラクションまで再現し、ユーザーが完成版に近い条件でプロダクトを体験できる状態を作ります。

新しいサービスや機能を設計するとき、最初から完成形に近いUIを作り込むことが、必ずしも最も効率的な進め方とは限りません。実装前の段階では、ブランドカラー、細かな余白、タイポグラフィ、影、アイコン、アニメーションといった視覚的な完成度よりも、「そもそも必要な情報が揃っているのか」「ユーザーが目的の機能まで自然に到達できるのか」「現在考えている画面遷移でタスクが成立するのか」といった、より根本的な設計上の不確実性を確認する必要があります。こうした骨格部分が固まっていないにもかかわらず高忠実度の画面を作り込むと、後から構造そのものを変更することになり、大きな手戻りが発生しやすくなります。

この段階で有効なのが、低忠実度プロトタイプです。低忠実度プロトタイプは、完成版UIを精密に再現することを目的とするものではありません。むしろ、必要最低限の情報、画面構成、操作要素、画面間の関係だけを可視化し、情報設計、機能配置、ユーザーフロー、操作経路など、設計の骨格が成立しているかを低コストで検証するために利用されます。紙に描いたスケッチ、簡単なワイヤーフレーム、クリック可能なグレースケール画面など、形式そのものよりも「変更しやすく、検証したい構造が見えること」が重要です。

UXリサーチでは、ユーザーがプロダクトをどのように操作しているか、どの機能を利用しているかといった行動だけでなく、その体験をユーザー自身がどのように評価しているのかを継続的に把握する必要があります。タスク成功率、エラー率、利用頻度、継続率、解約率などの行動指標は、プロダクト上で何が起きているかを理解するうえで重要ですが、それだけではユーザーがサービス全体に対してどのような態度を持っているのかまでは十分に説明できません。こうしたユーザーの態度や評価を定量的に観測するために利用される代表的な指標の一つが、NPS（Net Promoter Score）です。

NPSでは一般的に、「この製品やサービスを友人や同僚に薦める可能性はどの程度ありますか」といった質問を利用し、0から10までの尺度でユーザーの推奨意向を測定します。質問が比較的シンプルで、計算方法も理解しやすく、同じ条件で継続的に測定すれば時系列変化を追いやすいことから、プロダクト、SaaS、EC、金融、通信、サブスクリプションサービスなど、多様な領域で顧客体験を観測する指標として利用されています。

Webサイトやアプリのデザインでは、色、余白、タイポグラフィ、レイアウトなど、視覚的な要素に注目しがちです。しかし、すべてのユーザーが画面を視覚的に確認しながら操作しているわけではありません。視覚障害のあるユーザーをはじめ、画面を見ることが難しい状況にあるユーザーは、スクリーンリーダーなどの支援技術を利用してデジタルサービスを操作しています。

スクリーンリーダーは、画面上の情報を単純に「上から順番に読み上げるソフト」ではありません。Webページやアプリに設定された見出し、リンク、ボタン、フォーム、画像などの構造を読み取り、それぞれの役割や状態をユーザーへ伝えます。そのため、デザイン上は問題なく見えていても、実装構造や情報設計が不適切であれば、スクリーンリーダー利用者にとっては非常に使いにくいUIになることがあります。

UI/UXデザイナーにとって重要なのは、コードを書くことだけではなく、視覚情報がなくても意味や操作方法が伝わる設計を考えることです。

本記事では、スクリーンリーダーとは何かという基本から、どのように画面情報を認識するのか、デザイナーが設計時に確認すべきポイント、よくあるアクセシビリティ上の問題、デザインレビューやテストでの確認方法まで詳しく解説します。

Webサイトやアプリケーションを利用しているとき、ユーザーは画面上に表示されているすべての要素について説明文を読んでから操作しているわけではありません。多くの場合、ボタンの形や色、入力欄の枠、矢印、アイコン、配置、余白、過去に使ったサービスでの経験などを手掛かりにしながら、「ここは押せそう」「ここには文字を入力できそう」「このカードは横方向へ動かせそう」「この部分をタップすると詳細が開きそう」と瞬間的に判断しています。

反対に、見た目から操作方法を理解できないUIでは、ユーザーは画面上の要素を一つずつ確認し、「これは押せるのか」「この文字はリンクなのか」「どこから次へ進めばよいのか」と考えなければなりません。機能そのものは正しく実装されていたとしても、ユーザーがその存在や操作方法に気づけなければ、実質的には利用できない機能になってしまうことがあります。

このような「ユーザーが対象を見たときに、どのような行動が可能なのかを理解できるか」という問題を考えるうえで重要になるのが、**アフォーダンス（Affordance）**という概念です。