ユーザーインターフェイス設計（UI設計）について思ったことや気付いたこと、教えていただいたことなど、自分用の思考振り返りメモです。Twitterへの投稿やノートのメモ書き、いただいた質問への回答、チームメンバーにお伝えしていることなど、繰り返し発信していると思ったことをまとめています。

目次の序盤にある項目ほどデザインについての考え方や情報設計など、全体像に関する内容です。終盤に向かうにつれてデザインやコンポーネント設計など、より細部の内容になっていきます。今後も気付いた点があれば追記していきます。

基礎部分のスライド資料「ユーザーインターフェイス設計の基礎を振り返る」（2023年1月22日追記）

このページに記載した前半の情報設計の基礎について内容を抜粋したスライド資料を公開しました。

デザインの統一感、拡張性、耐久性

• ユーザーインターフェイスのデザインや使用感が統一されているか？
• ユーザーがある画面で学習したことを他の画面で活かせるか？
• 要素の増減に耐えられるデータ構造、コンポーネント設計、レイアウトになっているか？

ユーザーインターフェイス設計時には、そこに表示するデータの数が増減しても成り立つかを想定して進めていくと拡張性や耐久性を高めやすくなります。例えば、データが1個の場合、10個の場合、100個の場合、1000個の場合、0個の場合はどうなるのか、双方向のアクセス性が維持できそうかを思い浮かべながら進めます。

トーン&マナー

Webサイトやアプリケーション内で統一されたデザインが、ユーザーの使いやすさを高めると考えています。配色、余白、タイポグラフィ、インタラクションなど、統一感のあるデザインが維持されることで違和感が少なくなり、ユーザーが内容に集中しやすくなるはずです。

トーン&マナーから外れた要素が増えるほど、バラバラな印象になっていきます。ユーザーの集中力の妨げになったり不安につながってしまうと考えます。多くの場面で主役はコンテンツなので、主役を活かすデザインが適している場合が多いはずです。

要件ではなく目的の段階から関わる（デザイナーが仕様設計にも関わる）

デザイナーに限った話ではないですが、解決方法の範囲を広げるために要件の前段の「目的や要望」を聞いたうえで、長期的に何をどのようにすれば良いのかを考えることが重要だと考えています。これまでの経験上、目的に対してデザイナーが仕様設計の段階から関われると、品質向上につながる良い点が多くあると感じています。例えば次のような点です。

• 機能を増やさずに、ユーザーにとってより良い価値を提供できる方法が見つかるかもしれない。
• ビジネス要件やシステム要件、ユーザーインターフェイスとしての使いやすさ、見た目の印象、統一感などのバランスを維持しやすくなる。
• そもそも機能を増やすのではなく、今の運用方法を変えたりアップデートすることでより価値を提供できる方法が見つかるかもしれない。
• そもそもやろうとしていることがユーザーの希望からずれていて、やらないほうが良いかもしれない。全然違う解決方法があるかもしれない。

ユーザーインターフェイスデザインは仕様設計と表層のデザインが地続きだと考えています。デザイナーが複数の要件を横断して設計したほうが一貫性を維持しやすく、ユーザーにより良いものを提供しやすくなると感じます。

仕様設計段階から関わることで、ビジネス要件、システム要件、ユーザーインターフェイスの使いやすさや完成度など、複合的に何をどうすれば良いかの改善点が見つかりやすくなる実感があります。

ユーザーは全ての機能を使いたいわけではない

娯楽ではない限り、ほとんどのユーザーはソフトウェアの全ての機能を知りたいと思っているわけではなく、ユーザーがやりたいことを最小の労力かつ最短でできることを望んでいるのではないでしょうか。

ユーザーからすると、望んでいることが「確実にできる！」という確信を持てることは少ないはずです。「これを使ったら何となくできそうかも？」という期待や予想、もしくは疑念の元にソフトウェアを使っていることが多いと思います。

その期待や予想、疑念に対してどれだけわかりやすく親切にサポートできるかが、インターフェイス設計に求められているはずです。ユーザーの決断力や労力の消耗をどれだけ減らせるかも意識したいです。例えばよりわかりやすい初期状態（Default State）のあり方を考えるのも1つの改善です。

データ構造の初期設計が重要

データへのアクセス導線や双方向性の維持、一元管理化、共通コンポーネント化は、ユーザーインターフェイスの改善や拡張につながります。特に長期的な使いやすさを高めるためには、データ構造や仕組みの根本を再設計したほうが良い場合もあります。

根本部分の変更は影響範囲が広く、既存ユーザーへの負荷を強いることになってしまいます。一方でユーザー全体の長期的な利益につながりそうと判断できる場合は、根本改善に進みたいです。一気に変えるのはユーザーをはじめ多方面に影響が大きいため、段階的に移行できる方法で改善につなげたいところです。例えば次のような項目を意識したいです。

• データへのアクセスのしやすさ、行き来のしやすさ（双方向性）。
• 編集や削除のしやすさを維持するためにどう関連付けるか。
• 検索のキーを何にするか。
• 並び順をどうするか。

オンスクリーンのデザイン（デジタルのデザイン）には、試行と検証が繰り返しやすい利点があります。初期の構造設計や情報整理がしっかりしていると、改善を重ねやすくなります。

一般的なユーザーインターフェイスの挙動と比較する

例えば新しい機能のユーザーインターフェイスを設計する際、macOS、iOS、iPadOSなどのOS標準のユーザーインターフェイスやインタラクションがどのようになっているかを参考にすることが多いです。例えばどこからデータを変更できるか、変更を伝えるアニメーションは何秒程度か、どのような表現かなど。

特にアプリケーションなどのシステム設計では、データの作成（Create）、読み出し（Read）、変更（Update）、削除（Delete）の4つのアクションが基本であり、それらのアクションをユーザーが手軽におこなえることが重要です。そのためデータに対するそれらのアクション、データ構造、導線、インタラクションなどが使いやすく心地の良いものになっているかを注意して検証します。

データ構造の参考例として、WordPressの管理画面はデータを管理する情報設計で検索や編集機能に不足がないか、使いやすいかの比較検証に活用できます。例えば次のような点で参考になります。

• 記事（オブジェクト）の作成、表示、編集、削除
• タグによる情報分類（属性付与）
• タグ（オブジェクトの分類属性）の作成、表示、編集、削除
• データ登録日時の概念、時系列によるソート
• 公開日時の概念
• 記事の公開ステータス概念：公開、非公開、パスワード保護
• 記事がどのような属性を持っているか
• 記事の一覧性
• オブジェクトの一括選択、一括削除
• オブジェクトの検索方法、フリーワード検索、タグによる検索
• ページネーション

スライド資料「WordPressからデータ構造設計のヒントを得る」（2023年2月19日追記）

データ構造やオブジェクトに焦点を当てて、アプリケーション設計時に意識したい点をまとめました。コンテンツ管理システムのWordPressからデータ構造のヒントを得ることを目的としています。

ユーザーの記憶力に依存しない

• ユーザーの記憶力に依存しない。ユーザーが記憶しなくても情報へアクセスしやすいようにする。
• ユーザーがシステムの仕様や構造などの前提知識を持たなくても操作できること。もしくは操作できるための知識をその場（そのユーザーインターフェイス）から学べること。

特に入力フォーム画面では、「ユーザーが前の画面の情報を覚えておく」という状態を避けられる情報設計や画面構成にすると、ユーザーの負荷を減らせます。ユーザーの集中力をなるべく奪わないようにできると、それが使いやすさや心地良さにつながると考えます。例えば以下のような点です。

• ページ遷移をせずに参照したい情報をすぐに見られる。
• ページを戻る、行き来する動作を省略できる。
• 確認したい情報を同一画面内もしくはデュアルディスプレイで見比べられる。

要素を増やすときこそ慎重に

アプリケーションのユーザーインターフェイス設計は、要素を増えすときこそ慎重にレイアウトを検証したほうが良いと考えます。特にボタンが増えるときにはアプリケーション全体の整合性、画面が変わったときの他のボタンやテキストと整合性にも影響するためです。

例えば1度付けた要素（例えばボタン）の場所を変えると、ユーザーに再学習を強いてしまいます。特にその操作に慣れているヘビーユーザーになるほど変化へのストレスが高いと考えます。操作の熟練度が上がっていたり、その操作へのショートカットを身に付けていたりすると考えるためです。

1度付けた機能やボタンを後から削除すると、その機能やボタンを使っていたユーザーが困ってしまいます。要素増やしたいと思ったときこそ、まずは本当にその要素を追加するべきなのかどうかを慎重に検討したいです。

機能を減らす提案が必要なことも

ユーザーの使いやすさを高めるために、機能を減らす提案が必要な場面もあります。機能が減ることで、ユーザーが覚えることや選ぶことが減るメリットがあると考えるためです。できれば機能性を維持したまま、複雑さを減らしてシンプルにしたいところです。

「高機能」と「多機能」は近い意味で受け取られがちなのかもしれないですが、別の概念として捉えています。「機能が優れている」ことはユーザーのメリットですが、「機能が多いこと」はユーザーに選択や学習を強いることにつながるので、デメリットもあります。

ユーザーインターフェイスを設計するときには、高機能かつ少機能（より少なく、しかしより良く）を目指して、ボタン1つ、テキスト要素1つ、境界線1本に至るまで、それらを少しでも減らせないか考えたいです。

ユーザーの手間を減らして、表示速度を速くする

ユーザーにとって手間が少ないことと反応が速い（例えば画面表示までの時間が短い）ことは、ほとんどの場合ユーザーのメリットにつながります。品質を検証するときの項目にもなります。

丁寧なコーディングによるディテールの追求で、デザイン品質を高める

Webサイトの場合、デザインの反映精度はコーディングの追求度によって決まると感じています。なぜならユーザーが触れるデザインはブラウザの表示結果（レンダリング結果）であり、それはコーディングによって実現されるからです。

画面上のデザイン品質を高めるには、コーディングによるディテールの追求が必須です。意図したデザインを再現するための丁寧なコーディング調整、表示検証の繰り返し、インタラクションの心地良さの検証などが求められます。

デザインのディテール（ブラウザの表示結果）を追求するコーディング過程で良いコンポーネント設計が身に付いたり、新たなリファクタリング観点に気付いたり、相乗効果で色々と発見があるのも面白さの1つだと感じています。

Webアプリケーションの改善点の見つけ方

Webアプリケーションの改善点は、実際に使って試して仕様を探りながら疑問点を書き出していくと明確化されやすくなります。要素（オブジェクト）に対する属性や関連性、権限によってできることや表示される内容の違いも書き出してみると、情報整理の起点が見つかりやすくなります。

その際に一般的なユーザーインターフェイスと比べてレイアウトや挙動、インタラクションの違いや違和感を感じたら、それも改善につながるかもしれません。自分の感覚を疑いつつも、自分がユーザーとして使って感じた違和感や疑問を書き出しておくことで、改善のきっかけになります。

より良い情報分類とタグ付けのために考えたこと

• 要素には属性がある。
• 設計者が要素にタグを付ける際、属性の粒度（汎用性、詳細度、認知のしやすさ）を比べて、粒度の近さやユーザーの検索時の便利さでタグを付けているはず。
• ゆえに属性の粒度の比較は、指標の1つに使えるかもしれない。
• 属性の粒度はユーザーの解釈によって変わるはず。
• 一方で複数ユーザーの共通認識がある程度把握できれば、タグを便利に使える場面が出てくると考えられる。
• その共通認識（解釈）が何なのかを探すことで、ちょうど良い属性分類やタグの粒度を決めやすくなるのではないか。

要件定義で意識したいこと

• 目的、課題、解決方法（案A、案B、案C…）、リリース期日を明確化していく。
• 仕様で疑問に思ったことは自分が納得できるまで仮説と質問を繰り返して、疑問を明らかにする。
• ユーザーにとってわかりやすい設計になっているかの問いを繰り返す。
• より一般的なシステムの仕様に近いかを確認する。独自のシステムになればなるほどユーザーにとって使いにくくなっている可能性が高いので、一般的に多くのシステムで採用されている仕様、データ構造、導線に近いかを確認する。
• これらを関係者全員がいつでも見られるように共有ドキュメント化する。
• 誰でも常時編集可能なドキュメントを共有することで、改善点や反対意見をいただけたり議論がしやすくなったりする。

理想形を思い描いて今できることをやっていく

長期プロジェクトでは、理想形を思い描いてそこに向けて現実的に今できることや効果的だと思うことを試したり、検証したりするのが大事だと思います。理想形に向かっていれば、回り道することになっても長期的に良くなっていく期待が持てます。

プロジェクトを円滑に進める要件定義書

状況によって内容は増減しますが、以下の内容をプロジェクトのなるべく早い段階でまとめたり共有できたりすると、プロジェクトがスムーズに進みやすくなる印象です。

要件定義書に含めたもの

• プロジェクトの経緯
• これまでのミーティング議事録
• 要件の概要
• 背景と目的
• 公開希望時期
• ゴールと道のり
• 必須ではない要件
• ワイヤーフレーム
• 画面設計の補足説明
• 画面遷移の動画
• 今後の対応範囲

打ち合わせの際に意識したいこと

自分はまだまだできていないですが、次のことをなるべく心がけたいです。

• 打ち合わせ前に議題を用意しておく。何を決めるのかをなるべく明確化する。
• 打ち合わせ後に議事録を残す。次に何をするのかを記録する。
• 意見する際には根拠を述べる。資料に書く。
• 提案時にはメリットとデメリットの両方を伝えたうえで、その案を提案した根拠に結論づける。

ボタンを押したら何が起きるかを想像できるか？

ボタンは、押したときにどんな挙動になるのかユーザーが想像しやすい（想像した状態と一致する）状態が理想です。一方で解釈を限定するために全ての説明を盛り込んでしまうと、1画面内の情報量が増えすぎてしまいます。

特にWebアプリケーションの場合は1画面内の情報量が増えがちで、ユーザーが同じボタンを繰り返し使う可能性が高いです。であれば情報量を減らしてユーザーの学習に委ねたほうが、長期的な使いやすさにつながる場面もあります。

改善方法として、ユーザーの学習を邪魔しないことやユーザーが学習したことを他の場面に活かせるように設計することが挙げられます。以下、改善例です。

• ボタンを押したときに何が起こるかわかりやすい名称（ラベリング）にする。
• アイコンで意味を補足する。
• 統一された操作方法・操作体系にする。
• アイコンのみのボタンの場合、マウスオーバーしたときにツールチップで補足説明を表示する。タッチデバイスの対応は別途必要。
• 見つけやすい場所にヘルプを用意しておく。
• チュートリアルを用意する。

エンプティステート（Empty state）を設計して、ユーザーをサポートする

エンプティステート（Empty state）画面とは、「データがまだ存在しない状態」の画面のことです。例えば以下のメールテンプレート（オブジェクト）を検索する画面でメールテンプレートが1件も登録されていない状態は、「データがまだ存在しない状態」です。画面に何も表示されなければユーザーは何をしたら良いかわからず、迷ってしまいます。

その状態を改善するためにエンプティステート画面を制作し、「データがまだ存在しないこと」と「この画面で何をしたら良いか」を明確にします。これによってユーザーが次の行動を取るためのきっかけができて、より使いやすくなると考えます。

コンポーネント設計のルール決めと進め方

コンポーネント（再利用されるパーツ）設計は、グラフィックとしてのわかりやすさや美しさもそうですが、運用できる仕組みづくりやルール決めも含めての設計が重要だと考えます。例えば以下の点です。

• どこでどう使われるか。
• 例外的な使用をどこまで対応するか。
• そもそも例外を許容するか。

現時点では次の内容を基本方針としつつ、例外対応が必要になりそうなタイミングで全体最適と例外対応を調整しながらルールをアップデートしていく方針で進めることが多いです。

• 配色ルールはある網羅して設計。なるべく例外をつくらない。例外をつくるときは要検証。
• 余白は基本ルールは決めつつも、コンテンツや文脈によって既定値から選択できるようにする。例外にやや寛容気味。
• タイポグラフィは基本ルールを定め、秩序を維持して設計する。例外をなるべく許容しない。

実際には事前にすべてのルールを定めてから全体をつくるよりも、全体を設計してから共通要素をパーツ化していったほうが、サービス全体として自然なデザインになり秩序を維持しやすいです。そのためページのレイアウトとコンポーネント設計は双方を行き来しながらアップデートを繰り返していくのが良いと考えます。

デザインシステムを活用していただくために

• ルールを明確に決めて、ドキュメントに詳細に書き込む。特に判断の迷いそうなところは詳細に書く。
• なぜこのルールにしているのか、このデザインの意図は何なのかをドキュメントに明確に記載する。
• 「こういう場合にどうするの？」という疑問をQ&Aとしてドキュメントに書いておくのも良さそう。
• 自分がドキュメントの読み手として読んだときに、単一の解釈に絞れる内容になっているかを意識して読み直してみる。複数の解釈ができるのであれば、より詳細に書く必要がある。
• 定期的にドキュメントを見直して、アップデートする時間を設ける。あらかじめ予定化しておくとさらに良い。

色彩を人間の脳がどう解釈するか

『Design Elements』の色彩心理の項から気になった部分を引用します。

赤や黄などの暖色の光は波長が長く、したがって目から脳へと信号が伝わる過程でより多くのエネルギーを必要とする。それに伴うエネルギーレベルと新陳代謝の上昇が、“興奮”と解釈されるのである。反対に、青、緑、紫などの寒色の色は波長が短く、脳に伝わる過程でさほどエネルギーを必要としないため、新陳代謝率を下げ、その結果、沈静効果が生まれる。

Design Elements

『Design Elements』には、その続きに“色彩の心理学的属性は、見る者の文化的・個人的経験によるところも大きい”とも書かれています。光の波長（色）を人間の脳がどう解釈するかの物理的な反応と、文化や個人の経験による解釈などが複合的に組み合わさって印象がつくられるのが面白いなと思います。

要素や余白を8の倍数で設計する

以下の記事にまとめました。

8の倍数ルールでデザインする理由とメリット・デメリット

余白の設計（スペーシング）

WebサイトやWebアプリケーションなどの余白設計で意識していること。

• 要素と要素における関係性によって、統一された整合性をや秩序を維持する。
• 見た目の心地良さを維持する。
• コードとして複数人で運用できるようにルールを定める・サポートする。

余白の設計（スペーシング）はデザインの基本だと思っていますが、これら全てをきっちりと整えて運用していくのは相応の難易度があると思っています。余白の基礎については次の資料にまとめました。

エンジニア向けの余白の基礎 / Spacing

余白設計の学び方について

試行と検証の繰り返しが必要です。例えば次のようなことを繰り返すと精度が上がっていくと思います。

• デザインの基礎知識の書籍を読む・試してみる（実践する）。
• タイポグラフィとカーニングについて学ぶ・実践する。
• 余白を広げたもの、狭くしたものなどを比較して検証する。理由を考えてみる。

Webサイトの文章を読みやすくするには？

以下の記事にまとめました。

読みやすいWebタイポグラフィとデザインルール設計について

秩序ある文字サイズ強弱を表現するには？

以下の記事にまとめました。

Webサイトで明快なデザインと運用しやすいコーディングを両立する文字サイズ強弱の仮説・検証

欧文Webフォント選びで満たしたい基本条件

以下の記事にまとめました。

コーポレートフォント選びの基本条件（欧文フォント）

日付フォーマット選びの検証

以下の記事にまとめました。

最適な日付表記（日付フォーマット）を選ぶための、UIデザイン観点による比較検証

少ない色数でユーザーへの視覚的ノイズを減らす

使用頻度の高いアプリケーションの場合

• 画面内の色数を抑えたほうが、ユーザーの集中力を奪いにくいメリットがある。
• 有彩色のボタンやテキストが複数あると、コンテンツに集中しにくくなるデメリットが考えられる。

使用頻度の低いアプリケーションや訪問頻度の低いWebページの場合

• どこが押せるのかをユーザーに気付いてもらいやすくするために、有彩色を用いたボタンにするメリットがある。

結論

ユーザーのアプリケーションに対する習熟度が高くなればなるほど、ボタンが目立つ優先度が下がっていくのではと考えます。

アクセントカラーを用いるかの判断材料

コンバージョン増加を目的としたWebサイトの場合

問い合わせ獲得、商品購入のようなコンバージョンの増加が目的になるサイトの場合は、コンバージョン用のボタンを協調する目的でアクセントカラーを活用する場面が多いです。例えば青がメインカラーの場合、アクセントカラーとしてコンバージョン用に黄色やオレンジ系の色を指定する方法があります。

利用頻度の高いWebアプリケーションの場合

ステータスカラーやラベルカラーなど色を使う場面が増えるので、あえてアクセントカラーを用いない選択もあり得ると思います。状況によってはブランドカラーをコンポーネントのメインカラー（プライマリーカラー）にしないほうが良い場合もあると考えます。特に何らかの状態を示すステータスカラーと衝突しそうな状況においてです。

例えばAdobeではブランドカラーはロゴの色である赤色ですが、ボタンのユーザーインターフェイスで使用する色は青色を採用しています。Appleもロゴの色はグレーですが、購入ボタンの色は青系統です。状況によって配色や色数を決めていくことで、ユーザーにとって使いやすい製品やサービスに近づくと考えます。

グレースケールは本当に10段階も必要か？

これまでグレースケールは10段階を基本としてきましたが、7か8段階くらいが運用しやすいのではと考え直しています。表現の幅では段階が多いほうが良さそうに見えますが、運用のしやすさを考えたときに10段階全てを使い分ける必要性は再考しても良いかもしれません。段階を減らしても問題ないのであれば、なるべく減らしたほうが運用しやすくなるメリットがあります。

後から一括編集しやすい構造に

Webサイトを例にすると、ページ個別で指定するページタイトルやデスクリプション、OGPなどはページごとに指定できるようにします。コーディング時に共通箇所と個別箇所が理解しやすいようにまとめておくと使いやすくなりそうです。共通化する箇所は特に、後から一括で編集しやすい設計を意識したいです。

どこまでやるかはWebサイトの方針によりますが、例えばページのデスクリプションを指定する際にdescription用の変数を用意しておき、その変数をdescription、og:description、twitter:descriptionに反映する設計にしておけば、1箇所反映するだけで3箇所分の編集が完了するので効率的です。

ボタンのhover状態をデザインする観点

以下の記事まとめました。

hover状態のデザイン、Primaryボタンを明るくなるように設計した理由

アイコンとテキストの使い分け

アイコンはシンプルな画面設計に有効です。一方でアイコン単体では複数の解釈ができてしまうことで、意味が伝わりにくくなる問題もあります。表現する要素や状況によって使い分けたほうがわかりやすくなります。

要素を表現するときに状況によって以下のように使い分けて検証することで、よりわかりやすい表現に近づくはずです。

• テキストのみ。
• アイコンのみ。
• アイコンとテキスト。もしくはテキスト併記で補足。
• アイコンとツールチップ。マウスオーバー時に説明を表示。文字数上限の影響が少ないメリットあり。

Webアプリケーションのコンテンツレイアウト

ページ上部と左側に固定ナビゲーションがあるWebアプリケーションの場合、ユーザー設定やお問い合わせなど、コンテンツ幅の狭い（800pxくらい）のブロックの配置は中央寄せが主流のようです。横幅1920px以上のディスプレイで見るユーザーが増えていることもあり、中央寄せが適する場合が多いかもしれません。

Webアプリケーションの場合は特に1画面の情報量が多くなりがちで、画面いっぱいに情報を表示したい場合もあります。画面全体で表示するコンテンツと幅の狭いコンテンツの両方がある中で、それらを行き来したときに違和感の少ないレイアウトにできると一体感が出ます。

ツールチップのメリット・デメリット

ツールチップは、小さな領域に一時的に表示できる文字数を増やせるメリットがあります。その反面スマートフォンやタブレットなど、タッチ操作のデバイスで表現できないデメリットがあるので状況に応じた使い分けが必要です。

ボタン強弱の命名規則と優先したこと

デザインシステムを設計するにあたり、破壊的なボタンを除く通常ボタンとして3段階のボタン強弱を持たせる場合の命名規則は、以下の4つが良いと判断しました。

• Primary（第1の）
• Secondary（第2の）
• Tertiary（第3の）
• Destructive（破壊的な）

Tertiaryの呼称は馴染みが薄い印象ですが、運用にあたって意味の明確さと整合性を優先したほうがチームで運用する際に迷いが少なくなると考えました。次に挙げるいくつかのデザインシステムも参考にしています。

Apple

• Normal
• Primary
• Cancel
• Destructive

通常ボタンの強弱は2段階しかないためか、PrimaryとNormalという命名になっています。キャンセル用途に限定されたcancelが存在します。

Human Interface Guidelines

Adobe Spectrum

• Accent variant
• Primary variant
• Secondary variant
• Negative variant

Accent variantは最優先でありつつも、通常使用と切り離された特別なボタンという位置付けのようです。その後にPrimary variant、Secondary variantと続いています。破壊的アクション用のボタンはNegative variantと表現されています。

Button – Spectrum

Carbon Design System（IBM）

• Primary button
• Secondary button
• Tertiary button
• Danger button

破壊的アクション用のボタンがDanger buttonと表現されています。

Buttons – Carbon Design System

ケイ線で表現するボタンデザインの観点

ケイ線で表現するボタンは次の点を意識したいです。

• 標準のケイ線を2pxにするか1pxにするか。もしくは重要度によってそれらを使い分けるか。ケイ線を2pxとすると、ユーザーにより明快なボタンとして認識してもらいやすくなるメリットがある。
• 1pxの場合は視覚的な主張が少なくなるため、よりコンテンツに集中しやすい画面設計に近づく。
• グレー背景の際にボタンの背景色に白を用いるか透過とするか。透過したほうが汎用性が高そう。
• テキスト入力欄（input）との違いを明確化するために、線の太さで差別化する方法もあり。
• フォーカス時の表現も要検討。
• Material Design、Carbon Design Systemでは基準を1pxとしている。
• Adobe Spectrum、Luna Design System、Mozilla Protocolでは基準を2pxとしている。

現時点では重要度によって2pxと1pxのボタンを使い分ける設計や運用が良いと考えています。その他の参考事例はthe component galleryがコンポーネントごとに探しやすいです。

なるべく境界線を使わずに区分け（ゾーニング）する

Webサイトやアプリケーションに限りませんが、境界線を使わずに情報を区分け（ゾーニング）するとすっきりした印象に近づきます。画面内の情報量が多い場合は違いを感じやすいです。境界線の使用は重要性の高い箇所に限定して、余白や背景色とのコントラストで整理すると見やすくなる場合が多いです。

それでも情報整理に境界線を使ったほうが良いと判断した場合は、なるべく薄い色で反映すると情報取得のノイズになりにくくて見やすい画面設計に近づいていきます。例えば背景色が白（#FFFFFF）であれば、#E0E0E0ぐらいのグレーは境界線に使いやすい色です。もう少し薄い色を使う場合もあります。

境界線は情報を整理するためのもので主役ではないので、主役（ユーザーが必要とする情報）が伝わりやすいように控えめに使うとバランスが良くなりやすいです。例外的に、境界線をデザインのアクセントとして意図的に目立たせる場合もあります。

ドロップシャドウは要素の重なりを表現するためと限定する

次の理由からドロップシャドウの使用は限定的にしています。

サービス全体の世界観を合わせるため

• ドロップシャドウを使う用途として、Z軸上の重なりを表現するためと限定することでデザインの秩序や振る舞いを統一しやすいと考えるため。
• ドロップシャドウを使うとユーザーインターフェイス上の世界観に物体の距離感や立体的なZ軸の概念などが生まれ、全体のデザインコントロールで考慮すべき点が増えて管理が複雑になる。この状況を避けてシンプルさを維持するため。

例えばサービスで使うパーツごとにドロップシャドウの濃さや範囲がバラバラだと、物理構造としての違和感を感じやすくなるのではないでしょうか。全体的な世界観を合わせるため、ドロップシャドウは使わないか使う用途を限定したほうがデザインの秩序を維持しやすいはずです。

コンテンツに集中しやすくするため

ドロップシャドウは装飾表現としては情報量が多く、印象が強くなりがちです。ユーザーにコンテンツにより集中してもらいやすくするため、インターフェイスの装飾はなるべく少ない状態を維持したいと考えています。

重なりを表現する場合に使う

限定的ですが、要素の重なりを表現する場合にドロップシャドウを使うこともあります。例えばプルダウンメニューの表示やウィンドウの重なりを表現する場合です。物体として要素と要素を重ねる際に、Z軸の重なりを明確にする目的では使う場合があります。

hover時の表現としては？

hover時の表現としてドロップシャドウを用いるデザインも存在しますが、「ドロップシャドウは重なりを表現する場合に限定する」というシンプルなルールで運用することを優先して、他の表現方法を選ぶことが多いです。

有効・無効の状態をアイコンで表現するには？

アイコンを現在のステータスを表現する形状にするか、押した後に起こるアクションを表現する形状にするかについて。一律のルール付けが難しく明確な解決方法が見えていませんが、「初期表示やデフォルトが何か」が判断基準になりそうだと感じました。

例えば初期状態が機能オフという理由で否定形のアイコン（マイクミュートのような打ち消し線の入ったアイコン）を置くことによって、そもそもユーザーが機能の存在を正しく理解しにくくなってしまう可能性があります。ユーザーにわかりやすく伝わるように、以下観点を意識したいです。

• 初期状態は何か。
• 非活性（disable）と否定（not）の違いをどう表現するか。表現ルールを決める。例えば、形状や色、不透明度などで使い分ける。
• 主となるステータス表現と追加可能な（オプショナルな）ステータスをどのように区別して表現するか。
• アイコンで補足表示しなくても別の要素でユーザーに情報が十分に伝わりそうと判断できるのであれば、アイコンを省略したほうがシンプルになりユーザーにとってわかりやすくなる場合もある。
• アイコンで表現する属性が増えた場合に整合性が維持できるかどうか。属性が増えた場合にアイコンで表現しにくいものだった場合を想定する。その場合はそもそもアイコンの種類を増やさずにテキストで情報を伝えたほうがわかりやすいのかもしれない。
• 使うアイコンの概念が一般的に普及しているものか、特殊なものか。
• アイコンが使われる文脈が一般的か特殊か。
• ユーザーがそのアプリケーションを使い慣れているか、否か。
• ユーザーが視覚的に判別できる情報か否か。例えば音量は視覚的に判別できないので、視覚的にステータスを表示したほうがわかりやすくなる場合が多いはず。

項目のソートには「並べ替え」を使う

• ユーザーインターフェイスのラベリングとして何らかの項目をソートする場合は、「並び替え」ではなく「並べ替え」が正しいと教えていただきました。

サムネイル画像の縦横比は16:9で統一する

特にメディアサイトの場合は16:9の縦横比で統一すると運用しやすくなると考えています。詳細は「アイキャッチ画像の縦横比（アスペクト比）を統一するメリットと理由」として記事にまとめました。

ダークモードのデザインに必要な観点

以下の記事にまとめました。

ダークモードを1週間試した感想とデザインに必要な観点

スイッチ切り替え式のユーザーインターフェイス参考

「Why Toggle Buttons Are Confusing」という記事が、2項目かつオンオフ（ON / OFF）ではない、スイッチ切り替え式のユーザーインターフェイス設計の参考になります。

3項目以上の場合は単色の表現でもどれが選択中かわかりやすいですが、2項目の場合は単色だと選択中の項目がわかりにくい場面があります。解決方法としてグレーのケイ線とグレーの文字表現を用いるのは有効かもしれません。活性と非活性をより明確化できる利点があると思います。

スケジュール機能の設計観点

まだ仮説段階ですが、スケジューリング機能では時刻を主体にするか、曜日を主体にするかによって使い心地が変わってくるようです。1週間の予定を俯瞰してわかりやすく伝えるのであれば、曜日を主体とし、詳細情報として時刻を設定するという情報構造のほうが、人間にとってよりわかりやすいのではないかと考えています。例えば学校の時間割やGoogleカレンダーのイメージに近いです。1週間の曜日ごとに情報が書かれています。

一方で時間が決まっているルーチンワークを登録したい場合、1度の時間指定でまとめて曜日登録できるユーザーインターフェイスのほうが手間が減らせる場面がありそうです。登録の手間、一覧性、再編集性、時間感覚のわかりやすさ、これまでの慣れなど、総合判断では曜日主体のほうがわかりやすそうな印象です。

テキスト選択時のシェアボタン表示は本当に必要か？

Webサイトによっては、選択中の文章をTwitterなどのSNSで引用シェアできる場合があります。確かに引用シェアを多用するユーザーには便利なのかもしれません。一方で選択したテキストをハイライト的に使い集中して読みたい場合には、逆効果になってしまうデメリットもあります。状況によって導入するか判断したほうが良いでしょう。

テキスト選択時に勝手にSNSシェアボタン郡が表示されるのは、ユーザーにとって煩わしさを感じさせてしまう原因になると考えるため、基本的には使用しないことを推奨しています。

画像の数え方への疑問と汎用性

画像の個数を表示したり数えたりするときの単位について。「1枚、10枚、100枚…」か「1点、10点、100点…」あたりが日本語として自然な印象だと感じました。「1件、10件、100件…」でも意味は通じますが、枚のほうがより自然かもしれません。

一方で、それは写真を現像した物理的なものとして捉えているからそう思うだけかもしれません。今はデジタルな写真のほうが一般的で、物理的な写真に触れたことがない人からすると、「枚」という単位には違和感を感じるかもしれません。よって「点」のほうが単位として汎用性が高い可能性があります。

少し調べたところ、「枚」か「個」の使い分けは物体の厚みの観点で使い分けるようです。スクリーン上の画像には厚みの概念は無い（もしくは限りなく薄い物体として認識される）と考えられるので、単位の解釈はユーザーの感覚に左右されやすいのかもしれません。結論としては「点」が汎用性が高いように感じます。

課題解決ストーリーによるサービスページの基本構成

• 問題提起（課題・悩み）。
• 解決方法・結果を伝える。
• 解決の根拠を示す。
• サービス提供元の信頼根拠の提示。
• 不安や疑問解決の導線。
• 具体的なアクション方法。

文字だけで構成するページは基礎力を上げる機会

主観ですが、プライバシーポリシーや利用規約のページまで文字組みが整っているWebサイトを見ると、細かいところまでしっかりとしていそうと感じます。文字だけで構成するページを読みやすくデザインしたりコーディングしたりするのは、タイポグラフィや余白の基礎力を高められる良い機会だと思います。

つくったものを3日置いてから見直す

デザイン、コーディング、コピーなどの制作物は、ある程度できあがったら3日ほど置いてから見直すと改善点に気付くやすくなる印象です。3日も時間が無ければ1日置くだけでも効果を感じます。文字校正やデバッグなどの確認工程も、制作工程とは日程を少しずらしたほうが精度上がりやすいかもしれません。

リファクタリング（コード構造の整理）のメリット

• デザインを統一化しやすくなる。
• コードの見通しが良くする。
• 一括編集しやすくなる。
• 要素の追加や削除など、後からの編集がしやすい。
• 影響箇所が特定しやすく、デバッグの時間を減らせる。
• 長期的な品質と開発スピードが上がる。

最後に

ユーザーインターフェイス設計について思ったことや繰り返し発信していることをまとめてみました。自分はこれらをいつも意識できているわけではありませんが、考えていたことを思い出すきっかけや思考の振り返りとして活用できたらと思います。これからも気付いた点があれば追記していきます。