zerosant

まずは Foundations から

Accessibility

アクセシビリティとは、障害のある人が情報を利用できるようにすることだけではなく、能力や状況に関係なく、すべての人が情報を利用できるようにすること。シンプルさと知覚しやすさを優先して設計する。

シンプルさ: 使い慣れた一貫性のあるインタラクションをサポート
知覚しやすさ: 視覚、聴覚、触覚のいずれを使っても、すべてのコンテンツが知覚できるようにする

標準コンポーネントを使用すると、テキストやコントロールは太字、拡大、色の斑点、コントラストの増減など、自動で適応してくれる。

Interactions - Buttons and controls

タッチスクリーンのヒットターゲットは44pt x 44pt の大きさが必要。
一貫したスタイル階層を使って、ボタンの相対的な重要性を伝える。
システムが提供するSwitchコンポーネントを優先して使う。
リンクに色だけでなく、下線などの視覚的なものも加える。

Text display

Dynamic Type を使用すると、ユーザーが自分にあったフォントサイズを選ぶことができる。
テキストとアイコンがセットになってる場合は、フォントサイズとセットでアイコンも大きくする。
フォントの太さは regular か heavy を選ぶ。Regular, Medium, Semibold, Bold はみやすい。Ultralight, Thin, Light はみづらいので避ける。

Color and effects

オブジェクトの区別や情報伝達を色だけに頼らず、テキストや形状も使う。
テキストカラーにシステムカラーを使うと、色の斑点やコントラストなどに自動で適応してくれる。

Motion

体験に不可欠でない限り、アニメーションは使わないようにする。
ボタンなどによるコントロールなしで、ビデオやエフェクトが自動再生されないようにする。
動きや点滅は、人を注意散漫にする。

zerosant

App icons

とにかくシンプルにする。
細かくしすぎると判別が難しくなる。特に小さいサイズでは濁って見える。
背景はシンプルに、メイン画像に重点を置く。
複数のプラットフォームでうまく機能するデザインを作る。
- iOS, tvOS, watchOSのミュージックアプリの例
テキストを含めても小さすぎて読めない。不可欠の場合のみ含める。
写真やUIコンポーネントの流用や、スクショを使ったりしないこと。細部が多いとみづらい。
アイコンの角は自動で調整されるので、正方形画像でデザインする。

macOS用のアイコンだと、ツールを配置してるパターンがある。

https://developer.apple.com/design/human-interface-guidelines/app-icons#macOS

このツールの角度とか配置まで、推奨の比率があるらしい。

https://developer.apple.com/design/human-interface-guidelines/app-icons#macOS

zerosant

Branding

一貫したトーンやパターンとシンプルな文章構成で伝える
ブランディングは控えめに。コンテンツを優先
不可欠でない限り、アプリ全体にロゴを表示しない
- どのアプリを使っているのか思い出させる必要はない
起動画面をブランディングに使うのは避ける
- 情報を伝えるほどの時間はない。別途ウェルカム画面やオンボーディング画面を作るほうがいい。

zerosant

Color

（ゲーム以外では）色は控えめに。注意を逸らしてしまうので。
同じ色は同じ意味を持つように設計する
ライトモードでもダークモードでもうまく機能する色を選ぶ
色を選択できる場合は、ビルトインのカラーピッカーを使用する

Inclusive color

色だけで重要な情報を伝えない。色覚異常やその他の視覚障害を持つ人が理解できるように、形状などの別の手段も提供する
使用する色が、他の国や文化ではどのように受け止められるかを考える
- 赤はある文化では危険、他の文化ではポジティブな意味を持つ
- その色が、意図するメッセージを伝えられているかを確認する

System colors

システムカラーをハードコーディングしない
- 実際のカラー値は、さまざまな環境変数に基づいて、リリースごとに変動する可能性があるので
iOS, iPadOS, macOS, visionOS は、標準的なUIコンポーネントの配色にマッチする動的システムカラー（明暗両方のコンテキストに自動的に適応するカラーセット）を定義している
- 各色は、目的によって色が定義されている。ex) ある色は異なる階層のビューの背景を表し、他の色はラベル、リンク、セパレータなどの前景コンテンツを表す
動的システムカラーの意味を再定義しない
- プラットフォームの外観が変更されることもある

zerosant

Dark Mode

アプリ固有の外観設定を避ける
アプリがライトモードでもダークモードでも美しく見えるようにする

Dark mode colors

現在の外観に適応する色を取り入れる
- セマンティックカラーは自動で適応してくれる
- カスタムカラーが必要なら、Xcodeのアセットカタログに明暗のバリエーションを指定する（ハードコードしない）
すべての外観において、十分なコントラストをめざす
- 色間のコントラスト比が 4.5 : 1 を下回らないようにする
- 小さなテキストでは 7 : 1 になるように努める
- コントラスト比については https://ja.wikipedia.org/wiki/Help:配色のコントラスト比
ダークモードだと白い背景を含むコンテンツが眩しいので、和らげる

Icons and images

可能な限りSFシンボルを使う。外観に自動適応してくれる
必要に応じて、明暗それぞれ別のインターフェイスやアイコンを用意する

iOS, iPadOS

ダークモードでは、Base color と Elevated color を区別する。

https://developer.apple.com/design/human-interface-guidelines/dark-mode#iOS-iPadOS

Base color は暗く、背景が後退して見えるようにする
Elevated color は明るく、前景のインターフェイスが前進して見えるようにする

zerosant

Icons

アプリ内のすべてのアイコンで視覚的な一貫性を維持する
- ストロークの太さを統一する
同じ数値で同じ大きさにしたつもりでも、視覚的にはズレて見えることがある
- パディングを含むアセットを作り、それをセンタリングすることで視覚的に中央に見えるように調整する

https://developer.apple.com/design/human-interface-guidelines/icons

zerosant

Images

略（pointの説明や解像度の話）

Immersive experiences

没入型体験

略（visionOSだけを対象とした内容なので）

zerosant

Inclusion

包括的なデザイン

経緯あるコミュニケーションを優先し、誰もがアクセスし理解できる方法でコンテンツや機能を掲示しよう。

異なる視点

年齢
ジェンダーと性自認
人種と民族
セクシュアリティ
身体的属性
認知属性
永久的、一時的、状況的障害
言語と文化
宗教
教育
政治的または哲学的意見
社会的・経済的背景
様々な視点からアプリを検討する
- 不快になる可能性のあるコンテンツを避ける
- 誰もが楽しめるウェルカムな体験

Welcome

文章は、明確に、直接的に、敬意を払って。意図しないメッセージを送らないようにする
人の呼び方に気をつけよう。自分のことをユーザーって呼ばれたらよそよそしく感じる
専門用語を定義なしに使うのはやめよう
口語表現は翻訳が難しい。平易な言葉に置き換えよう
ユーモアは慎重に。理解できないとき、人は混乱するしうんざりする

その他

そのほかにも下記の内容が書かれている。

ジェンダー
ステレオタイプを避ける
アクセシビリティ
言語

本文を熟読した。

zerosant

Layout

コンテキストの変更に対応し、一貫したレイアウトを設計する
各プラットフォームの主要なディスプレイとシステム機能を尊重する
- セーフエリアを使えば、端末のインタラクティブなシステム要素（バーとかDynamic Islandとか）に干渉しなくてよくなる
重要な要素は画面の上、先頭に配置する
必要以上に詳細を表示しない
- 十分なスペースを設け、見つけやすくする
図形や色や区切り線でうまくグルーピングして、情報を見つけやすくする
整列によって視覚的なスキャンを容易にする（一覧性を高める）インデントも活用し、情報階層を理解しやすくする
隠れているコンテンツを見つけるための視覚的なヒントを提供する
インタラクティブなコンポーネントの周りには十分なスペースを。見つけやすくなる。
いろんなデバイスでプレビューする。シミュレータでもいい

iOS

全幅ボタンはシステム定義のマージンを尊重する
- 角丸でセーフエリアの一番下に置くのが最も良い
iPadなら、画面の側面に横向きにコントロールを配置すると良い
- 両手でアクセスしやすい
画面の下の端にインタラクティブなコントロールを配置するのは避ける
- システムジェスチャーとコンフリクトするし、手が届かない人もいる
滅多なことがない限り、ステータスバーを非表示にしない

zerosant

Materials

重なっているコンテンツの前後関係を視覚的に伝え、レイヤーの分離をユーザーに視覚的に伝える。
システムが提供するマテリアルやエフェクトは、その意味に基づいて選ぶ
- システム設定によって外観や動作が変わる可能性があるため、ユースケースと意味のマッチするものを使う
- 見かけの色に基づいてマテリアルやエフェクトを選択しないこと
Material の上に鮮やかな色を使用することで可読性を確保する
システム定義の鮮やかな色を使用すると、異なるコンテキストで色が暗すぎたり、明るすぎたり、飽和していたり、低コントラストだったりする心配がない

zerosant

Motion

ユーザーのアクションに対する明確なフィードバックを提供するための意図的なアニメーションを選ぶ
- このアクションをおこなうと何が起こるのか、次に何ができるのかをフィードバックとして示す
過剰なアニメーションはユーザーから集中力を奪い、不快に感じさせる可能性がある
Motion をオフにできるようにしておく
- 重要な情報を伝える唯一の方法として Motion を使用することは避ける
リアルさと信頼性を追求する
- 物理法則に反しているような動きはユーザーを混乱させる
- 混乱する例) 上から下にビューを表示させるのに、消すときは横にスライドする
簡潔で正確なアニメーションを使えば、より軽快かつ効果的に情報が伝わる
頻繁に起こるインタラクションに Motion をつけることは避ける
- すでにシステム提供の Motion に慣れているユーザーにとって、不必要な追加の Motion は負荷になる

zerosant

Privacy

プライバシーを守ろう

必要なデータのみにアクセスを要求する
- ユーザーがその機能に興味を示す前にデータを求めたりすると、アプリを信頼してもらえなくなる可能性がある
- ユーザーが自分のデータを正確にコントロールできるようにするため、可能な限り細かく具体的にアクセス許可を求める
アプリがどのようにユーザーのデータを収集し、何に使うかについて明らかにする
可能な限りデバイス上でデータを扱う

アクセス許可の申請が必要なもの

個人を特定する情報を含む個人情報
- 位置情報、健康情報、財務情報、連絡先など
ユーザーが作成したコンテンツ
- 電子メール、メッセージ、カレンダーデータ、連絡先、ゲームプレイ情報、Apple Musicアクティビティ、HomeKitデータ、オーディオ、ビデオ、写真コンテンツなど
保護されたリソース
- Bluetooth周辺機器、ホームオートメーション機能、Wi-Fi接続、ローカルネットワークなど
カメラやマイクなどのデバイス機能
アプリのトラッキングをサポートするデバイスの広告識別子

注意点

明らかに必要となるまでは許可を求めないこと
- その機能をユーザーが使うまで、許可を求めるのを待つ
必要ない限り起動時には許可を求めない
- 理由が明らかであればいいけど
そのデータをどう使用するかを明確に説明する

https://developer.apple.com/design/human-interface-guidelines/privacy

Pre-alert screens, windows, or views

許可を要求する理由を詳細に提供することが不可欠である場合、システムアラートを表示する前にカスタム画面を表示する
ボタンを一つだけ置いて、そのボタンを押すとシステムアラートが開くということを明確にする

https://developer.apple.com/design/human-interface-guidelines/privacy

カスタム画面にシステムアラートを表示する以外のアクションを表示しないこと
- システムアラート以外の方法でキャンセルできるようにしない

https://developer.apple.com/design/human-interface-guidelines/privacy

Tracking requests

アプリを起動してすぐにトラッキングしたいときは、トラッキングデータを収集する前に、システムアラートを表示する
システムアラートの前にカスタム画面を置いてもいいが、そこでユーザーを誤解させる表現を用いないこと
- たとえば、許可すればインセンティブを受け取ることができるとか、良い体験を得られるとかのような表現で許可を推奨することは禁止

データの保護

認証をパスワードだけに頼らない
- 可能であればパスキーを使う
機密情報はキーチェーンに保存する
パスワードやその他のセキュアなコンテンツを、プレーンテキストのファイルに保存しない
カスタム認証方式を考案して使わない
- パスキーや Sign in with Apple、パスワード自動入力などの、システムが提供する機能を使う

zerosant

Right to left

アラビア語やヘブライ語などの右から左に記述される言語に対応するとき、必要に応じてインターフェイスの左右を逆にする。

テキスト配置

RTLコンテキストではインターフェイスの左右を逆にする
- LTRコンテキストで左揃えの場合、RTLコンテキストでは右揃えにする
現在のコンテキストではなく、段落の言語に合わせて段落を配置する
- 英語とアラビア語が混在するケースがあったなら、英語の段落は左揃え、アラビア語の段落は右揃え
リスト内ではアイテムごとに左右を変更したりせず、一貫した配置にする
- 一覧性を保つため

数字と文字

クレカ番号や電話番号は、現在の言語や周囲のコンテキストによらず常に同じ順序で表示されるため、反転させない
進行状況やカウントの方向を示す数字は逆順にする

コントロール

スライダやプログレスインジケータなどのコントロールは反転させる
- 前方への進行を、自分が読む言語と同じ方向の動きとみなす傾向がある
移動のためのコントロールの反転
- 例えば、戻るボタンや次へボタンもコンテキストに合わせて反転させる
実際の方向や特定の領域を指すコントロールの向きは維持する
- 「右へ」というコントロールは当然右。どのコンテキストでも右は右

画像

画像そのものを反転させない
画像の順序に意味がある場合は、順序を反転する

https://developer.apple.com/jp/design/human-interface-guidelines/right-to-left

アイコン

上記と同様に、テキストの整列や進行方向に意味がある場合は反転したものを使う
現実世界のオブジェクトを表すものや、ロゴまたはユニバーサルなサインやマークは反転させない

https://developer.apple.com/jp/design/human-interface-guidelines/right-to-left

zerosant

SF Symbols

SF Symbols は Apple が提供する数千種類以上のアイコンライブラリ。システムフォントである San Francisco とシームレスに統合するようにデザインされている。

略

Spatial layout

空間レイアウトのこと。

略

Apple Vision Pro だけを対象とする項目なので、今は読み飛ばす

zerosant

Typography

インターフェイスで使用する書体の数を最小限にする
- 多くの書体が混在すると、情報の階層がわかりにくくなり、読みづらくなる
様々なコンテキストで読みやすいかのチェックをする
- 屋外の明るい日差しの下や、動いてる時にちらっと見たとき、遠くから見たときなど
ライトウェイト（Ultralight, Thin, and Light）は読みづらいので避ける
- ミディアム、セミボールド、またはボールドを優先して使う
テキストサイズの変更に反応させるときは重要な内容を優先する
- ユーザが大きいテキストサイズを選択するときは、関心のあるコンテンツを読みやすくしたい
- 重要性の低いテキストは小さいままでいい

zerosant

Writing

アプリで使用する言葉の選択について。

アクションに基づいた表現を用いる
- 「ここをクリック」ではなく、クリックした先で得られる情報などの内容がわかるような語句を使う
文体や文言のパターンをつくり、一貫性を持たせる
- 一人称または二人称の統一：「自分のお気に入り」「あなたの保存済み項目」を混在させない
- 次の手順に進むためのボタンラベルの統一：「続ける」「次へ」のどちらかを選んで、一貫して使う
デバイスに応じた使用方法を記載する
- iPhoneやiPadで「クリック」という表現は使わない
空白の画面では、明確な次の手順を示す
- 完了済みのTodoリストや、何も入っていないフォルダなどの空白状態では、アプリについてもっと知ってもらう機会をユーザーに提供できる
- 次に何をするかが明確でないとユーザーが躊躇する可能性がある
- 実行できる操作を掲示したり、可能なら実行のためのボタンやリンクを配置する
明確なエラーメッセージを表示する
- 問題の近くに表示し、非難するような表現は避ける
適切な表示方法を選択する
- ユーザーの注意を惹きつける方法は複数あるので、メッセージの緊急度と重要度に応じて決める
- 通知、アラート、アクションシートなどがある
テキストフィールドにヒントを表示する
- 全てのフィールドに分かりやすいラベルをつける
- ヒントやプレースホルダを使用して入力形式がわかるようにする
- エラーはフィールドのすぐ横に表示し、正しく情報を入力する方法を伝える

zerosant

Foundations は以上

次は Patterns

zerosant

Charting data

データセットについての重要な情報を強調したい場合にグラフを使用する
グラフはシンプルにし、詳細な情報は必要に応じてユーザーが確認できるようにする
- 提示すべきデータがたくさんある場合は、ユーザが自らそれを選んで有効にできる方法を考える
すべてのグラフをアクセシブルにする
- 見てわかるだけではなく、アクセシビリティ要素（値を示すラベルなど）も提供する

効果的なグラフのデザイン

基本的に、棒グラフや折れ線グラフなどの一般的なグラフを使用する
斬新な方法でグラフを作成するときは、ユーザーが理解できるようなサポートをする
タイトル、サブタイトル、注釈などのテキストを追加して分かりやすくする
- ユーザーにとって不可欠な情報を一目で把握できるようにする
複数のグラフ間で一貫性を保持し、例外は差異を強調する必要がある場合のみにする
- 同じ目的のグラフなら、同じスタイルを使用する
- アプリ内のグラフに一貫した視覚的アプローチを適用し、ユーザーがあるグラフで得た使い方の知識を別のグラフでも応用しやすいようにする
同じデータを使用する複数のグラフ間で一貫性を維持する
- 同じデータセットをさまざまな視点で探索できるようにしたとき、グラフの種類、色、注釈、レイアウト、説明テキストは同じものを使う

zerosant

共同作業と共有について

共有や共同作業を始めやすいように、共有ボタンをツールバーなどの使いやすい場所に配置する
必要に応じて共有シートまたは共有ポップオーバーをカスタマイズし、アプリが対応してるファイル共有方法を選べるようにする
対応している共有権限を要約した簡潔な文言を書く

シェアボタンの他にコラボレーション機能向けの内容もあった。メッセージ機能なんかを作ろうとしたときは読むべき

今回は省略

zerosant

Drag and drop

可能な限り、アプリの全域でドラッグ＆ドロップに対応する
- ユーザーはドラッグ＆ドロップ操作に慣れているので、どこでもやろうとする
ドラッグ＆ドロップと同じ処理を実行できる代替手段も提供する
状況に応じて、複数項目のドラッグ＆ドロップに対応する

フィードバックの提供

ユーザーが選択部分のドラッグを開始した直後からドラッグイメージを表示する
- 半透明の画像を作成すると効果的。元のコンテンツと容易に区別できるし、ドラッグ先がそれに隠れて見えなくなることもない
コンテンツがドラッグ先で受け入れ可能かどうかをユーザーに明示する
- 受け入れ可能なときは、挿入ポイントを表示したり、親ビューを強調表示したりする
- 受け入れ不可のときは、視覚的なフィードバックを何も表示しないか、円に斜め線のような不許可アイコンを表示する
無効なドラッグ先にドロップしたり、ドロップ操作がエラーになったりしたときは、視覚的フィードバックを掲示する

ドロップ操作の受け入れ

必要に応じてドラッグ先のコンテンツをスクロールする
- 多数のコンテンツが含まれ、スクロールが必要なコンテナ内でドラッグする場合
ドロップされたコンテンツの転送に時間がかかる場合はフィードバックを表示する
ドロップ後はドラッグ先のコンテンツの選択状態を維持する
- ユーザーは、ドロップしたコンテンツがすぐに操作できるように、選択状態のままになっていることを期待する

zerosant

Entering data

ユーザーが正確かつ簡単に情報を入力できる方法について

可能な限りシステムから情報を入手する
- 設定などから自動で収集できる情報がある
- ユーザーの許可により、位置情報やカレンダー情報も収集できる
必要なデータを明確にする
- プレースホルダやラベルではっきりと伝える
- 妥当なデフォルト値がある場合は、あらかじめ入れておく
パスワードなどのセキュアなフィールドは、セキュリティ保護されたテキストフィールドを使う
パスワードフィールドの内容は自動入力しないようにする
できるだけテキスト入力ではなく選択方式にする
できるだけドラッグ＆ドロップやコピペで入力できるようにする
フィールド値の動的バリデーションをいれる
- 入力した直後にフィードバックを掲示すれば、その場で間違いを訂正できる
必須入力のものがある場合は、入力するまで次に進めないことがユーザーにわかるようにする
- 「次へ」ボタンを選択できないようにするなど

zerosant

Feedback

ユーザーが下記のことをするのに役立つ

現在の状況を把握する
次に何ができるかを知る
操作の結果を理解する
間違いを避ける

フィードバックで伝達する情報

システムやアプリ内の様々な箇所の状態
タスクやアクションの成功/失敗
望ましくない結果を招く可能性のある捜査に対する警告
間違いや問題ある状況を修正する機会

ベストプラクティス

すべてのフィードバックを確実にアクセス可能にする
- 画面を見ていなくても、デバイスを無音にしていても、VoiceOverを使っていてもフィードバックを受け取れるようにする
状況のフィードバックをインターフェイスに組み込む
- 対象項目の近くで状況のフィードバックを掲示すれば、ユーザーは追加の負担なく重要な情報を得られる
重大な情報はアラートを使って伝える
- 現在の作業を中断させることになるので、重大な情報に限る
取り返しのつかないデータ損失の原因になる可能性があるタスクを開始しようとするユーザーに警告する
- 予期できるものであれば警告不要。たとえばFinderでファイルを削除するくらいなら予期できる
重要なアクションやタスクの完了のフィードバックは必要に応じて掲示する
- 重要なアクションに限る。通常はタスクが正常に完了するとユーザーは考えるので、失敗した時だけ確認が必要
コマンドを実行できない場合は、その旨を理由とセットでユーザーに伝える

zerosant

File management

macOSやiPadOS向けの内容が大半なので省略

自分がiOS使うときはたまにファイルを意識することもあるけど、頻度としてはかなり低そう

Going full screen

フルスクリーンモードの話

作業内容に適している場合のみ、フルスクリーンモードに対応する
- 適しているのは、ゲーム、メディア再生、詳細なタスク実行など
フルスクリーンモードを維持したままユーザーがタスクを完了できるように、必須のアプリ機能は常に利用可能にしておく
ユーザーがフルスクリーンモードを終了するタイミングを選べるようにする
- 勝手に終了するのは、ユーザーの期待する動作ではない

Launching

アプリ起動時の話

初期設定情報は必要な場合にのみ要求し、できる限り既存のデバイス設定やデフォルト値から取得する
- ユーザができるだけ早く何らかの達成感を味わえるようにする
プライベートなデータへのアクセス許可は、必要とする機能にユーザーが興味を示したタイミングでリクエストする
補足情報の表示や評価依頼は、ユーザーがある程度アプリを体験したあとに行う
- 起動後にすぐ大量のコンテンツを読ませたりしないこと
アプリを再起動した場合は、再起動前の状態から再開できるように状態を回復する

起動画面

起動画面は最初のコンテンツへの流れを作るステップにすぎない。実質的にユーザーに見えないようにするのが理想
起動画面の唯一の役割は、アプリが素早く起動して即座に使えるようになるという印象をユーザーに与えること
- オンボーディングのためのスクリーンでも、スプラッシュスクリーンでも、ましてや芸術的表現の場でもない
起動画面にはテキストを含めないようにする
あまり凝った起動画面にしない
- ユーザーがアプリやゲームの体験にスムーズに移行できる起動画面にする
広告には利用しない。宣伝の場ではない

zerosant

Live-viewing apps

tvOSだけを対象としているので省略

Loading

コンテンツをできるだけ早く表示する
- 読み込み完了までの間に何も表示しないのではなく、プレースホルダのテキストなり、グラフィックスなり、アニメーションなりを表示して、コンテンツ読み込みの進捗に合わせて要素を置き換えていく
コンテンツの読み込み中であることと、完了するまでの予想時間を明確に通知する
- インジケータを使えば、読み込み状況を通知できる
- 読み込み時間が予測できる場合は、確定的なプログレスインジケーターを使う
- 予測できないときは、不確定的なプログレスインジケーターを使う
読み込み時間が長くなるようなら、ユーザーが待っている間になにか有意義なコンテンツを提供する
- ゲームのコツを伝授したり、参考になるグラフィックスを表示したり
アプリの雰囲気に合わせて読み込みビューをカスタマイズする

zerosant

Managing accounts

アプリの主要機能に必要な場合のみ、アカウントの作成をユーザーに要求する。それ以外の場合はアカウントなしでアプリやゲームを楽しめるようにする。

アカウント作成のメリットとサインアップ方法について説明する
サインインを要求するタイミングをできるだけ遅らせる
- アプリを使う意義を何も見出せていないうちにサインインを要求すると、ユーザーはそこで使うのをやめてしまう
アカウント認証で「パスコード」という言葉を使わないようにする
- 「パスコード」はデバイスをロック解除したり、Appleのサービスの認証をおこなうためにユーザーが作成するもの

アカウントの削除

アプリやゲーム内でアカウントを削除するわかりやすい方法を用意する
- アプリ内で削除できない場合は、削除できるWebページに直接アクセスできるリンクを提供する
ユーザーがアカウントの削除をスケジュールできるようにする
- サービス期間を最大限利用したり、サブスクリプションの自動更新が来るまでアカウントを保持したりでき、ユーザーの利便性が高まる
- 同時に、直ちに削除するオプションも提供する

zerosant

Managing notifications

集中モードへの対応

集中モードがオンの時には、ユーザーは通知を表示するアプリを指定できる
コミュニケーション通知：通話やメッセージなどコミュニケーションに対応する通知
- → 通知が表示されるタイミングは送信者に応じて決まる
ノンコミュニケーション通知：コミュニケーション通知以外の通知
- → 通知ごとに中断レベルを指定する必要があり、この中断レベルに応じて通知が表示されるタイミングが決まる
  - passive: ユーザーが好きなタイミングで通知を表示する
  - active (default) : 着信したタイミングで知ることができるとありがたい情報
  - timeSensitive: 即時通知。ユーザーに直接的に影響し、すぐに対応する必要がある情報
  - critical: ユーザーに直接的に影響し、すぐに対応する必要がある情報のうち、健康や安全に関する緊急情報。政府や公的機関、健康や自宅を管理するアプリから発信されるレベルのもの

中断レベルに応じた通知の動作

https://developer.apple.com/jp/design/human-interface-guidelines/managing-notifications#Integrating-with-Focus

ベストプラクティス

それぞれの通知内容を適切に反映した緊急度を設定することで、信頼を得るようにする
- 実情に即した中断レベルを割り当てる
- 優先度の低い情報を、高い緊急度を使って通知することによって、ユーザーの作業を邪魔していると思われないようにする
timeSensitive 中断レベルは、すぐに通知しなければならないことだけに使用する
- 集中モードやスケジュール配信を無視してでも通知する必要性があるか？
- 今起きていることや1時間以内に起きることについての通知のみに限定する

マーケティング通知の送信

マーケティングや宣伝のコンテンツは、ユーザーが明示的に受け取りに同意した場合を除き、通知を使って送信しないようにする
- マーケティング通知：アプリやゲームの新機能、コンテンツ、イベントなどの情報
マーケティングの通知はtimeSensitive中断レベルでは送らないようにする
宣伝やマーケティングの通知を送る場合は、ユーザーの許可を得るようにする
- 警告やモーダルビューを使用してどんな情報を送りたいかを説明し、ユーザーが分かりやすい方法で有効/無効を選択できるようにする
ユーザーがアプリで通知設定を管理できるようにする

zerosant

Modality

モーダルはユーザーの注意を喚起することが有効な場合にのみ使用する
- モーダル表示を使用すると、ユーザーは直前の作業から切り離され、それを閉じるためのアクションをする必要がある
モーダルなタスクは、シンプルで短く、効率的なものにする
- 複雑だと、モーダルビューに入ったときに中断した親ビューのタスクの状況がわからなくなってしまう
詳細なコンテンツや複雑なタスクには、フルスクリーンのモーダルを使う
- フルスクリーンにすると、気が散る要素を最小限に抑えられる
モーダルビューを閉じる方法をわかりやすくしておく
必要な場合はモーダルビューを閉じる前に確認を表示してデータが失われないようにする
モーダルビューで何をすべきか簡単にわかるようにする
別のモーダルビューを表示する前に、ユーザーがモーダルビューを閉じるようにする
- 複数のモーダルビューが同時に表示されると、雑然として散らかってまとまりのないアプリになる。ユーザーの認知負荷も高い。

zerosant

Multitasking

特に iPadOS 向けの話が多いので省略。Slide Over とか Split View とかピクチャインピクチャとか。

zerosant

Offering help

ヘルプの提供についての話。

ユーザーに提供するヘルプの種類は、アプリのタスクに応じて決める
- 複雑なタスクにはチュートリアルを提供したり、単純なタスクにはインラインテキストを出したり
ヘルプに使用する用語や画像には関連性と一貫性を持たせる
- iPhone で「ボタンをクリックする」と表記したりしない。プラットフォーム間で使い回しているときは注意

ヒントの作成

https://developer.apple.com/jp/design/human-interface-guidelines/offering-help#Creating-tips

ヒントとは、一時的に表示する小さなビューで、アプリの機能の使い方を簡潔に説明するもの
新機能や目立たない機能について説明したり、タスクを早く完了する方法を知らせたい場合に効果的
アプリのUIに最も適した種類のヒントを使用する
- インライン表示して重要な情報が隠れないように注意
- コンテンツを中断したくない場合は、ヒントをポップオーバーで表示
ヒントに向いているのは、単純なタスク
- 説明しやすく、手順の少ないタスクに向いている
- 3つ以上のアクションが必要な機能には、ヒントを出すにはちょっと複雑すぎる
短くて、操作したくなるような、惹きつけられるヒントにする
- 1~2文にとどめ、直接的で操作中心の言葉をつかって機能を説明する
意図したユーザーにのみ届くようにルールを定める
- 慣れてるユーザーにとってはヒントは有益ではない
- ヒントが役立つと思われるユーザーを決めるルールを作り、ヒントを出すタイミングを調整する
さらに詳しい情報やカスタマイズ設定への動線ボタンを、ヒント内に含めるのもよい

zerosant

Onboarding

オンボーディングが必要な場合は、短時間で楽しく終えることができ、スキップ可能なフローを提供する

アプリの主な目的を短時間で楽しく伝えると、記憶に定着しやすくなる
- ユーザーの記憶力を要求したり、大量の情報を提供したりしないこと
インタラクティブな方法で説明する
- 説明をただ読むだけではなく、実際にタスクを行い、コンテンツを操作する方が学習効果は高い
独立したオンボーディングのフローよりも、メインなコンテンツに簡潔なオンボーディング要素を組み込む方がいい可能性もある
- 例えばある機能を最初に有効化するときに、その機能の簡潔な説明と次のステップを示す視覚的なヒントを表示するとか
チュートリアルを提供する場合でもスキップできるようにする
- 次回以降起動したときに再表示しないようにする
- あとから見たくなったら、ヘルプや設定画面から見られるようにする

zerosant

Playing audio

ユーザーはデバイスの消音設定や音量設定が、すべてのサウンドに影響することを期待しているので、ユーザーの予想通りの動作になるようにする。

必要に応じて、自動的に音量を調整する（ただし全体の音量は調整しない）
可能な場合はオーディオの再生先を変更できるようにする
システムが提供する音量ビューでオーディオを調整できるようにする
- 音量ビューには、音量スライダやオーディオの再生先を変更するコントロールが含まれている
アプリに適したオーディオカテゴリを選択する
- オーディオカテゴリに応じて、例えばほかのオーディオとミックスされるかどうかや、バックグラウンドの時に再生されるかどうかなどが決まる

https://developer.apple.com/jp/design/human-interface-guidelines/playing-audio#Best-practices

オーディオコントロールを別の目的に使用しない
- ユーザーはオーディオコントロールがアプリで一貫した動作になることを期待している
カスタムのオーディオプレーヤーコントロールを作るのは、システムが対応しないコマンドを提供する場合のみ
- 早送りや巻き戻しなど

zerosant

Playing haptics

触覚フィードバックの話。

触覚フィードバックの使い方には一貫性を持たせる
- 触覚パターンと特定のパターンを結びつけるため、明確な因果関係を持たせる
多用しすぎない
- たまに提供されると効果的だが、頻繁だとしつこく感じられる
オプションでオフにできるようにする

zerosant

Playing video

システムが提供するビデオプレーヤーを使う
- 慣れ親しんだ使いやすい操作感を提供できる
ビデオのコンテンツは常にオリジナルのアスペクト比で表示する
キーボードが接続されてるときは、スペースバーで再生と一時停止ができるようにする
- これ以外にも、どの入力デバイスを使っても期待する操作ができるようにしておく

zerosant

Printing

プリント機能

プリント機能を見つけやすくする
- iOSやiPadOSのアプリなら、ツールバーやナビゲーションバーにアクションシートを開くボタンを追加する
プリントオプションは可能な場合のみ表示する
関連するプリントオプションを表示する
- ページ範囲の選択、複数部数のプリント、両面プリントなど

zerosant

Ratings and reviews

ユーザーにアプリのレビューを依頼するタイミングは、アプリの利用頻度や利用する機能の数、完了したタスクの数を考慮して、適切なタイミングを選択する。

評価を求めるのは、ユーザーがアプリやゲームをある程度使用したあとにする
- アプリの価値が理解できた頃を見計らって評価を求める
- 使用してないうちに評価を求められたという印象を与えると、否定的なフィードバックが残される可能性が高い
タスクを実行したりゲームをプレイしているユーザーの邪魔をしないようにする
- アプリの中で、自然な小休止や停止のタイミングを探す
しつこく要求しない
- 少なくとも1~2週間は空ける
システムで提供されるプロンプトを優先する
- アプリの中でフィードバックを求めるのに適した場所を指定すると、システムが未入力かどうかを判定してレビュー依頼してくれる
- プロンプトの表示は、アプリごとに365日間で3回までに自動的に制限されている

zerosant

Searching

アプリのコンテンツを検索できるようにする
コンテンツのインデックスを作成してメタデータを指定すると、Spotlightに共有することもできる
システムで提供される開く/保存ビューを優先して使用する

zerosant

Settings

できる限り、ユーザーが設定領域に移動しなくてもタスク固有のオプションを変更できるようにする
- アプリ内のインターフェイスの一部表示/非表示や、コレクションの並べ替え、リストのフィルタリングなどの調整。これは個別の画面でオプションを提供した方が見つけやすい
- 別の設定領域に配置すると、オプションが現在のタスクから切り離され、ユーザーがタスクを中断して設定を調整しなければならないし、その設定が反映されたかどうかはタスクを再開しなければわからない。不便
アプリ内の設定領域には、滅多に変更しないアプリレベルのオプションのみを含める
- ユーザーはあまり設定領域にアクセスしない傾向がある
- インターフェイス全体のスタイルや、アプリアイコンの変更など
提供する設定の数はできるだけ少なくする
ユーザーのシステム全体の設定を尊重し、アプリ固有の設定領域に重複した設定がないようにする
- ユーザーはグローバルオプションがすべてのアプリに適用されることを期待している
他の方法で取得できる設定情報を求めない
- 位置情報などは端末から取得できる
OSの設定アプリに、アプリ固有の設定を含めることができるが、そこに含めるのは滅多に変更しない設定のみにする
- 設定を変更するにはアプリの切り替えを要するため、現在のコンテキストを離れる必要がある
- OSの設定アプリでオプションを提供する必要がある場合は、アプリから直接設定を開くボタンを配置する
アプリ内設定は、見つけやすくすると同時に、目立ちすぎないようにする
- たとえば、プロフィールビューやアカウントビューで設定を提供する

zerosant

Undo and redo

ユーザーが取り消し/やり直し操作の結果を予測できるようにする
取り消し/やり直しの結果を示す
- 表示されていないコンテンツに対する取り消しの場合は、結果を強調して表示することが重要
ユーザーが何度も取り消しできるようにする
- ユーザーはすべての操作を取り消せることを期待するので、回数に不要な制限を設けない
取り消し/やり直しの標準ジェスチャを定義し直さない（iOS, iPadOS）
- 取り消し/やり直しの標準ジェスチャは、3本指スワイプやiPhoneのシェイク
取り消し/やり直しの対象となる操作を簡潔かつ正確に示す（iOS, iPadOS）
- 「取り消す - 名前」や「やり直す - アドレスを変更」などのように、対象となる操作を示すテキストを追加する

zerosant

Workouts

どちらかというと WatchOS がメインなので省略

zerosant

Patterns は以上

次は Components

下記のサブ分類みたいなのがあって、その下にそれぞれの項目が入っている構成

Content
Layout and organization
Menus and actions
Navigation and search
Presentation
Selection and input
Status
System experiences

zerosant

Charts

グラフによる表現について。各部位の名前はこんな感じ

https://developer.apple.com/jp/design/human-interface-guidelines/charts#Anatomy

グラフの持つ意味に合わせて、軸の範囲を固定または動的にする
ユーザーがグラフを見る前にグラフの目的を理解できるような説明を記述する
- タイトルやラベルでグラフの目的や機能を説明しておくと、ユーザーは必要なコンテキストを理解できる
グラフの主要なメッセージを要約し、誰にとっても利用しやすく役にたつグラフにする
アプリ内のすべてのグラフでアクセシビリティに対応する
- VoiceOverへの対応により、画面を見なくても情報の取得やナビゲーションを行えるようにする
必要に応じてユーザーがデータを操作できるようにするが、重要な情報は操作しなくてもわかるようにする
誰でも簡単にグラフを操作できるようにする
- グラフのマークが小さすぎると操作しにくい。ヒットターゲットを拡大する
ユーザがグラフの重要な変化に気づけるようにする
- マークや軸の変化に気づかないと、グラフを読み誤る可能性がある
- アニメーションをつけると気づけそうだけど、VoiceOverユーザーやアニメーションをオフにしているユーザーにも気づかせたい

色

グラフ内の色だけでデータの区別や重要な情報の伝達をしない
- 図形やパターンなどの代替手段を用意する
連続する領域の色を明確に分離して理解を助ける
- 積み上げ棒グラフなどは、色を分けて区切りを表示すれば、区別しやすくなる

zerosant

Image views

イメージビューは、ビューの主な目的が単にイメージを表示することである場合に使用する
- イメージをインタラクティブにしたいときは、イメージビューにボタンの挙動を追加するのではなく、ボタンにイメージを表示する
アイコンを表示するときは、イメージビューではなくシンボルまたはインターフェイスアイコンを使用する
- SF Symbolsというベクトルベースのイメージライブラリが提供されている
イメージ上にテキストをオーバーレイするときは、テキストとイメージのコントラストを十分に確保する

zerosant

Text views

長いテキストや編集可能なテキスト、特殊なフォーマットのテキストを表示する場合に使う
- 短いテキストの場合は、ラベルやテキストフィールド（編集可能な場合）を使う
テキストを読みやすくする
- Dynamic Type を使ってデバイス側でテキストのサイズを変えても読みにくくならないようにする
有用な情報は、選択してコピペできるようにする
- エラーメッセージ、シリアル番号、IPアドレスなど
入力内容に合わせた適切なキーボードを表示する（iOS, iPadOS）

zerosant

Web views

埋め込まれたHTMLやWebサイトなどのリッチなWebコンテンツをアプリ内に直接読み込んで表示する機能

進む/戻るナビゲーションに適宜対応する
- デフォルトでは使用不可になっているので、ユーザーがもし複数のWebページの閲覧をする可能性がある場合は、進む/戻るナビゲーションを有効にし、それらに対応するコントロールを用意する
Webビューを使ってWebブラウザを構築しない
- Webビューの目的は、アプリを離れずにWebサイトにアクセスすること。Webブラウジングの主な手段はあくまでSafariなので、アプリ内でブラウザを複製しない

zerosant

Boxes

論理的に関連のある情報やコンポーネントを視覚的にまとめるためのコンポーネント。

ボックスは、それを含むビューに対してなるべく小さくする
- 大きくなると、コンテンツのまとまりを区別する効果が減少し、他のコンテンツを圧迫する
ボックス内でさらにグループ化を行う場合は余白や配置を工夫する
タイトルによってボックスのコンテンツを識別しやすくなる場合には、タイトルを含める
- タイトルが必要な場合は、簡潔な表現にする

zerosant

Collections

順序のついたコンテンツのセットを管理できる。画像ベースのコンテンツの表示に最適。

可能な場合は、標準の行レイアウトやグリッドレイアウトを使用する
- デフォルトでは、コンテンツは水平方向の行やグリッドで表示される
テキストを表示する場合は、コレクションではなくテーブルを使う
項目を選択しやすくする
ユーザーが項目を挿入、削除、並べ替えた場合は、なるべくアニメーションを使用してフィードバックを返す

zerosant

Column views

カラム表示によるデータ階層の表現。左に親階層があり、右に向かって階層が深くなる。Finderで採用されているやつ。

macOSのみが対象なので省略。

zerosant

Disclosure controls

表示したり非表示にしたりする開閉コントロールの話。

詳細な情報をユーザーが必要とするまでは、開閉コントロールを使って非表示にしておく
- 詳細な内容は非表示にしておくことで、ユーザーが大量の詳細情報に煩わされず、最も重要な情報を素早く見つけることができる
開閉用三角ボタン：行の先頭に配置され、コンテンツが非表示のときは内向き、表示中は下向き
開閉用矢印ボタン：特定のコントロールに関連する機能を表示/非表示できる。コンテンツが非表示のときは下向き、表示中は上向き
- できるだけ表示/非表示にするコンテンツの近くに配置する
- 1つのビューで複数の開閉用矢印ボタンを使わない

zerosant

Labels

ボタン、メニュー項目、ビューに表示される少量のテキスト。コピーはできるが、編集はできない。

システムフォントを優先する
- Dynamic Type に対応している
有用なラベルテキストは選択可能にして、コピペできるようにする
- エラーメッセージ、場所、IPアドレスなど
システムで提供されるラベルカラーを使って相対的な重要度を伝える

https://developer.apple.com/jp/design/human-interface-guidelines/labels#Best-practices

zerosant

List and tables

リストまたはテーブルでは、テキストの表示を優先する
- サイズのばらつきの大きい項目がある場合や、多数のイメージを表示する必要がある場合は、代わりにコレクションを使う
リストの項目が選択されたとき、適切なフィードバックを提供する
- 新しいビューが開くのか、項目の状態が切り替わるのかに応じてフィードバックは異なる
- 階層内を移動するためのテーブルなら、ユーザーがたどっているパスを明確にするために選択済みの行が強調表示されることが多い
常に項目のテキストを簡潔にして読みやすくする
横幅に収まらないテキストの読みやすさを保つ方法を検討する
- テキストの中央に、省略を意味する...を表示すると、先頭と末尾の両方が保持されるため、項目を区別しやすい
複数列のテーブルでは、列見出しで列の内容を説明する

zerosant

Lockups

tvOS向けの内容なので省略

Outline views

階層型のデータを表示するために用いる、スクロール可能なリスト。macOS向けの内容なので省略

zerosant

Split views

Split View は、複数の隣接するコンテンツパネルの表示を管理する。サイドバーを設ける場合は、Split View を使うのが一般的。

Split View は表示領域がコンパクトな環境ではなく、レギュラーの環境で使用することを心がける
- 横方向に複数のパネルが表示されるので、ある程度の幅が必要
- 縦向きの iPhone には向いていない
ナビゲーションの操作感を高めるため、詳細ビューに到達するまでの各パネルでの選択箇所を常に強調表示する
パネル間でのコンテンツのドラッグ&ドロップに対応する

zerosant

Tab views

複数のコンテンツパネルを同じ領域に切り替えながら表示できる。主にmacOS向けの内容なので省略。
なお、iOS, iPadOS向けに似たようなコンポーネントとして、セグメントコントロールがある

zerosant

Activity views

共有やコピー、プリントなどのアクションを素早く実行できるビュー。共有シートとも呼ばれる。

アクティビティビューですでに利用できる一般的なアクションと重複するアクションを作らない
- プリントなどの基本的なアクションはすでにシステムで提供されている
カスタムのアクションを作る場合は、わかりやすいタイトルをつける
- 短く簡潔な単一の動詞句で表現する
現在のコンテキストに適したアクティビティであることを確認する
- 例えば、プリントする必要がない場合は「プリント」アクティビティを除外できる
アクティビティビューは「共有」ボタンからのみ表示する

https://developer.apple.com/jp/design/human-interface-guidelines/activity-views

zerosant

Buttons

使いやすいボタンする
- ボタンの周りに十分なスペースをとり、周囲のコンポーネントやコンテンツから容易に区別できるようにする
- どの入力方法でもボタンを簡単に選択できるようにするには、ヒット領域を44x44pt以上にする必要がある
目的が明確に伝わるボタンにする
- ボタンが実行する処理をユーザーが予測できるように、ボタンには必ずテキストラベルかシンボルを含める
ビューの中で一番使われるであろうボタンには、背景の塗りつぶされたボタンなどの視認性の高いものを使う
1つのビューにつき、目立たせるボタンは2つまで
複数の選択の中で推奨するものを視覚的に差別化する場合は、サイズではなくスタイルを使用する
- サイズが異なれば、ひとまとまりの選択肢であることを認識しづらい

iOS/iPadOSのボタン

4つのスタイル、3つのサイズ

https://developer.apple.com/jp/design/human-interface-guidelines/buttons#iOS-iPadOS

zerosant

Context menus

iOS, iPadOS だと、タッチまたはピンチして長押しするジェスチャにより表示するパターンが多い。macOSだと、Controlを押しながらクリック、または右クリックで出てくるメニュー。

コンテキストメニューに含める項目は、コンテキストとの関連性が高く、ユーザーが必要とする可能性が高いものにする
メニューの項目の数を抑える
アプリ全体で一貫してコンテキストメニューに対応する
コンテキストメニューでできることは、メインのインターフェイス経由でも常にできるようにする
複雑なメニューを扱うためにサブメニューを使用する場合は、1階層までにする
- 2階層以上は複雑で操作しづらい
- サブメニューを使うときは、サブメニューを開かなくてもメニュー項目が推測できるようなタイトルを親階層に表示する
利用できない項目は薄く表示するのではなく、非表示にする
最もよく使うメニュー項目をユーザーの目に留まりやすい場所に配置する
iOS, iPadOS, visionOSでは、データを破壊する可能性のあるコンテキストメニュー項目についてユーザーに警告する
- 削除や除去などの項目を含める場合はメニューの末尾に配置したり、赤文字で表示するなど、注意を促すための工夫をする
iOS, iPadOS, visionOSでは、コンテキストメニューのコマンドにアイコンを含める
- ユーザーが機能を即座に理解できるようになる

zerosant

Dock menus

mac の Dock メニューに関しての話。省略。

zerosant

Edit menus

テキストを選択したときに表示される、カット/コピー/ペースト/翻訳/調べるなどの関連コマンドのメニュー。テキストだけでなく、画像やファイルなどの選択可能な多くのタイプのコンテンツに適用できる。

できるだけシステムが提供する編集メニューを使う
編集メニューを開く操作は、システムで定義された操作を用いる
- iOSなら長押し、macなら副ボタンクリックなど、ユーザーが慣れている操作を使う
現在の状況と関連性の高いコマンドを提示し、適用できないコマンドは取り除くか目立たなくする
必要な場合はユーザーが編集不可テキストも選択してコピーできるようにする
取り消し/やり直しに対応する
編集メニューの項目と同じ機能を実行するコントロールを別に実装することは避ける
カスタムコマンドには簡潔なラベルをつける

zerosant

Menus

iOS/iPadOSだとこういうやつ

https://developer.apple.com/jp/design/human-interface-guidelines/menus

ラベル

各項目には、そのアクションを説明するための明瞭かつ簡潔なテキストを記述する
- 意味を明確にするためのシンボルやアイコンを含む場合もある
アクションを実行する前にユーザーに追加情報を提供してもらう必要があるときは、メニュー項目のラベルの末尾に省略記号（...）をつける
- 省略記号（...）は、ユーザーが情報を入力/選択する別のビューが開くことを意味する
メニュー項目が使用不可のときはそのことをユーザーに示す
- 淡色表示して押せないようにするなど

切り替え項目

1対のメニュー項目を表示できるだけのスペースがない場合は、変化するラベルを使用する
- グリッドが表示されてないときは「グリッドをオンにする」、表示されている時は「グリッドをオフにする」のように
切り替え項目が現在有効な属性（太字への切り替えなど）を表す場合は、チェックマークの使用を検討する
複数の切り替え属性を容易に削除できるメニュー項目を提供することを検討する
- 例えば、テキストに適用済みのすべてのフォーマット属性を一度にプレーンに戻す項目など

整理

使用頻度、オブジェクトの重要度、昨日のカテゴリに応じた優先順位づけスキームに従って整理する
優先度の高いものを上にもってくる
論理的に関連しているコマンドのグループは、優先度がすべて同じでなくても分割しない

サブメニュー

サブメニュー：メニュー項目の下位のリストに表示する、項目と密接に関連する一連のアクションなど
- メニュー項目の後ろに>などのシンブルを表示することで、サブメニューの存在を示す
サブメニューは控えめにする
- 1つ増えるごとにUIが複雑になる
- 3つ以上のメニュー項目に同じ用語が表示される場合には、サブメニューの作成を検討する
  - 日付で並べ替え、件名で並べ替え、未開封で並べ替え のようなメニュー項目が並ぶ場合は、表示順序メニュー項目に 日付、件名、未開封のサブメニューを設けるなど
サブメニューの深度は1階層までがおすすめ
サブメニューの項目が使用不可の場合でも、サブメニュー自体は使用可能にしておく
- ユーザーがサブメニューを開いて、どんなコマンドが含まれているかを調べられるようにしておくべき
メニュー項目のインデントよりも、サブメニューの使用を優先する
- インデントはシステムとの整合性がないので、メニュー項目間の関係を明確に表すことができない

zerosant

Pop-up buttons

ポップアップボタンのメニューから項目を選択すると、メニューが閉じてボタンのコンテンツがアップデートされ、現在の選択値が表示される。

https://developer.apple.com/jp/design/human-interface-guidelines/pop-up-buttons

択一的なオプションや状態を含むフラットなリストを掲示する場合に使用する
- アクションのリストを掲示したり、複数の項目を選択したりする場合はプルダウンボタンを使う
デフォルトで選択する項目は、大多数のユーザーが選択する可能性の高い項目にする
ポップアップボタンを開く前にオプションの内容を推測できるようにする
ポップアップボタンが有効なのは、スペースが限られていて、すべてのオプションを常に表示する必要がないとき

zerosant

Pull-down buttons

https://developer.apple.com/jp/design/human-interface-guidelines/pull-down-buttons

ボタンのアクションに直接関連するコマンドや項目を掲示するために使う
- ex) 追加したい項目を指定するためのメニューが呼び出される「追加」ボタン
- ex) 並べ替えの基準となる属性を選択するためのメニューが呼び出される「並べ替え」ボタン
- ex) 直前の場所を開く代わりに戻り先を選択できるメニューが呼び出される「戻る」ボタン
コマンド以外の択一的な項目をリスト表示する場合は、ポップアップボタンを使う
主要なアクションには不向き
- ビュー内の主要なアクションはユーザーがすぐに見つけられる必要がある
メニュー項目の数のバランスを取る
- 1, 2個だけならプルダウンボタンは大げさすぎる。逆に多すぎると目的の項目を見つけるのに時間がかかる
破壊的なアクションを実行するメニュー項目は、それが伝わるように赤字などで強調表示する
必要ならメニュー項目にアイコンをつける
スペースに制約がある場合、重要度の低い項目は「さらに表示」プルダウンボタンを使って掲示する

zerosant

Toolbars

iOSだと画面の下に、iPadOSとmacOSでは画面またはウインドウの上に表示される。

https://developer.apple.com/jp/design/human-interface-guidelines/toolbars

ユーザーが必要とする可能性が高いコマンドを優先して配置する
表示する項目を多くしすぎると、目的の見つけづらい
各項目の意味を必ず明確にする
- 勘に頼ったり試しに使ってみたりしないと機能がわからないような項目は避ける
- アイコンや短い説明ラベルを割り当てて説明する
全ての項目の見た目（ビジュアルスタイル）をなるべく揃える
2つの状態が切り替わるような項目の場合は、現在の状態が明確に伝わるようにする

iOS

タブバーも画面の下に表示されるが、ツールバーとは目的が異なる
- ツールバーは、画面に関係するアクションを実行するために使う（項目の作成、フィルタリング、コンテンツのマークアップなど）
- タブバーは、アプリのさまざまな領域間を移動するために使う
ツールバーとタブバーが同じビューに同時に表示されることはない
ツールバーのボタンが3つ以下の場合は、シンボルではなく簡潔なテキストラベルを使って意味を明確にする
ボタンが4つ以上の場合はシンボルを使ってスペースを節約する

zerosant

画面の上に表示される、コンテンツの階層のナビゲーションを補助するコンポーネント。画面のタイトルや親階層に戻るためのボタンが配置されていたりする。

タイトルは簡潔に
- 1語または短いフレーズで、その画面の目的をまとめる
- タイトルが冗長になる場合は、空のままでもいい
操作に集中できるように、ナビゲーションバーを一時的に非表示にすることを検討する
- 写真を全画面表示しているときなど
- 非表示にしたときは、タップや下へのスワイプなどのジェスチャで再表示できるようにする
標準の戻るボタンを使用する
- ユーザーが、情報の階層を辿って前の手順に戻れることを認識できる
ナビゲーションバーでセグメントコントロールを使って、情報階層をフラットにすることを検討する（iOS）
ユーザーが移動したりスクロールしたりしても常に自分の位置がわかるように、ラージタイトルを使用する（iOS）
- デフォルトでは大きなタイトルが、スクロールすると標準タイトルになるやつ

https://developer.apple.com/jp/design/human-interface-guidelines/navigation-bars#Best-practices

Accessibility

Interactions - Buttons and controls

Text display

Color and effects

Motion

App icons

Branding

Color

Inclusive color

System colors

Dark Mode

Dark mode colors

Icons and images

iOS, iPadOS

Icons

Images

Immersive experiences

Inclusion

包括的なデザイン

異なる視点

Welcome

その他

Layout

iOS

Materials

Motion

Privacy

アクセス許可の申請が必要なもの

注意点

Pre-alert screens, windows, or views

Tracking requests

データの保護

Right to left

テキスト配置

数字と文字

コントロール

画像

アイコン

SF Symbols

Spatial layout

Typography

Writing

Charting data

効果的なグラフのデザイン

Collaboration and sharing

Drag and drop

フィードバックの提供

ドロップ操作の受け入れ

Entering data

Feedback

ベストプラクティス

File management

Going full screen

Launching

起動画面

Live-viewing apps

Loading

Managing accounts

アカウントの削除

Managing notifications

集中モードへの対応

ベストプラクティス

マーケティング通知の送信

Modality

Multitasking

Offering help

ヒントの作成

Onboarding

Playing audio

Playing haptics

Playing video

Printing

Ratings and reviews

Searching

Settings

Undo and redo

Workouts

Charts

色

Image views