UI（ユーザーインターフェース）は、人が触れる接点そのものを指します。画面、文字、ボタン、入力欄、配置、操作の反応。見て触れる部分です。この記事では、Webサイトで確認できる設計項目を整理します。
UIで扱う範囲
文字：大きさ、行の間隔、色と背景の差、書体。
配置：情報の並び、余白、区切り。
操作の要素：ボタン、リンク、入力欄、選択肢。
反応：押したときの変化、読み込み中の表示、エラーの示し方。
移動：現在地の分かりやすさ、戻り方、階層。
表示の安定性：読み込み中に配置がずれないか。
文字の設計
大きさ：スマートフォンで無理なく読める大きさにします。制作画面のパソコンで見た印象と、実機は違います。
行の間隔：詰まりすぎると読みにくく、空きすぎると次の行を見失います。
1行の長さ：長すぎると、行の先頭に戻るのが難しくなります。
色と背景の差：薄いグレーの文字は、環境によって読めなくなります。当サイトでは、配色ごとにコントラスト比を記録し、白背景に対して読めない色を文字に使わない運用にしています。
書体：装飾的な書体は、長い文章に向きません。
ボタンとリンクの設計
押せることが分かるか：文字だけで、押せるかどうか判断できない要素があります。
押しやすい大きさか：指で操作する前提にします。
間隔が十分か：近接していると、誤って押されます。
文言が具体的か：「送信」より「無料で相談する」のほうが、何が起きるか分かります。
押した後に反応があるか：何も変化がないと、二重に押されます。
リンクの見た目を統一する：ページごとに違うと、判断のたびに迷います。
入力の設計
必須項目を減らす：入力が多いほど、途中でやめる人が増えます。
何を入れるか分かるか：ラベルと補助説明。
形式を強制しすぎない：電話番号のハイフン、全角と半角。利用者に合わせて処理するほうが親切です。
エラーの示し方：どこが誤りか、どう直せばよいかを、その場で示します。送信後にまとめてエラーが出る形は、離脱の原因になります。
入力した内容が消えないか：エラー時に全部消えると、やり直す人は多くありません。
送信後の画面：受け付けたことが分かる状態にします。
当サイトの問い合わせでも、入力の確認は画面側と受信側の両方で行っています。 片方だけでは、確認を回避できてしまうためです。
移動と階層の設計
現在地が分かるか：サイトのどこにいるか。
戻れるか：一つ上の階層へ移動できるか。
階層を深くしすぎない：目的の情報まで、何回の移動が必要か。
メニューの言葉：社内の用語ではなく、利用者が使う言葉にします。
同じものを同じ名前で呼ぶ：ページによって呼び方が違うと、別のものだと思われます。
表示の安定性
Google 検索セントラルの「Core Web Vitals」では、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標として、3つが示されています。
Largest Contentful Paint（LCP）：読み込みパフォーマンスの尺度。ページの読み込み開始から2.5秒以内が推奨されています。
Interaction To Next Paint（INP）：応答性の尺度。200ミリ秒未満が推奨されています。
Cumulative Layout Shift（CLS）：視覚的安定性の尺度。0.1未満が推奨されています。
CLSは、UIの設計に直結します。 読み込み中に画像や広告が後から入って配置がずれると、押そうとしたボタンが移動します。画像や広告の領域をあらかじめ確保しておくことで防げます。
同じドキュメントでは、Search Console の Core Web Vitals レポートでページのパフォーマンスを確認できることが案内されています。
画面を覆う表示
Google 検索セントラルの「煩わしいインタースティシャルやダイアログを避ける」では、インタースティシャルはページ全体を覆うオーバーレイ、ダイアログはページの一部のみを覆うオーバーレイと説明されています。
そして、煩わしいインタースティシャルでユーザーの閲覧を妨害すると、ユーザーの不満を招き、ウェブサイトへの信頼を損ないかねないとされています。
改善の方法として、インタースティシャルではなく、画面のほんの一部だけを覆うバナーを使用することが挙げられています。バナーを使うことで、ユーザーと検索エンジンは、ページに到達すると同時にコンテンツにアクセスできるとされています。
避けるべきミスとして、インタースティシャルでページ全体を覆わないようにすること、同意や入力のために、ユーザーを別のページにリダイレクトしないようにすることが示されています。
公開前の確認方法
実機で見る：スマートフォンとパソコンの両方。制作画面での確認だけでは足りません。
横スクロールが出ないか：狭い画面幅で確認します。当サイトでは、ページ本体が横スクロールしないこと、表は自身の領域内でスクロールすることを実測で確かめています。
指で操作してみる：ボタンの押しやすさ、間隔。
入力してみる：エラーを起こしてみて、表示を確認します。
読み込み中の様子を見る：配置がずれないか。
社外の人に触ってもらう：制作した人は迷いません。知らない人が触ることに意味があります。
やってはいけないこと
装飾を優先する：読みにくい配色、装飾的な書体。見た目の印象より、読めることが先です。
薄い色の文字を使う：環境によって読めなくなります。
押せるかどうか分からない要素を作る：判断のたびに迷わせます。
入力を増やす：必要のない項目は削ります。
画面を覆う表示を出す：公式ドキュメントで避けるよう示されています。
制作画面だけで判断する：実機の見え方と違います。
一貫性を保つ
ページごとに見た目や操作が違うと、そのたびに判断が必要になります。
同じ役割の要素は同じ見た目にする：ボタン、リンク、見出し。
位置をそろえる：メニュー、問い合わせへの導線。
言葉をそろえる：同じものを、ページによって違う名前で呼ばないようにします。
色の意味を決める：注意を促す色、行動を促す色。意味を決めずに使うと、色が情報として機能しません。
当サイトでは、配色を1つのファイルにまとめて定義し、そこ以外で色を指定しない運用にしています。 ページごとに色がずれるのを防ぐためです。
例外を作りすぎない
「このページだけ特別に」を重ねると、一貫性が失われます。
例外を作る場合は、理由を記録します。 後から見て理由が分からない例外は、単なるばらつきになります。
この記事のまとめ
UIは、文字、配置、操作の要素、反応、移動、表示の安定性を扱います。文字は実機で読める大きさと十分な色の差を確保し、ボタンは押せることが分かる見た目と大きさにします。
入力は必須項目を減らし、エラーはその場で分かるように示します。表示の安定性は Core Web Vitals の CLS に関わり、画像や広告の領域を確保することで防げます。
画面を覆う表示は避け、バナーを使うよう公式ドキュメントで案内されています。公開前は実機で確認し、社外の人に触ってもらいます。
出典と注記
Core Web Vitals の定義と各指標の推奨値、レポートの案内は Google 検索セントラル「Core Web Vitals と Google 検索の検索結果について」に基づきます。インタースティシャルとダイアログの定義、影響、改善方法は同「煩わしいインタースティシャルやダイアログを避ける」に基づきます（いずれも確認日 2026年8月20日時点）。ドキュメントは更新されるため、実務では最新の記載を確認してください。 設計項目と確認方法は当社が支援の現場で用いている整理です。成果を保証するものではありません。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。