「iOS開発するにあたり、Appleの提唱するHuman Interface Guidelinesを読んでいない、理解していないのはいかがなものか!」
と天のお告げがあったので一通りガッツリ読んできました。
ガイドラインのうちデザインのテーマと原則だけザックリまとめます。
Human Interface Guidelinesとは?
「優れたiOSアプリを開発するためのUI設計の指針」
ってことかなと。
「優れた」の定義がよく分からないけど、優れたアプリにするためにこのガイドラインがあるのだなと思います。
デザインテーマ
iOSアプリとして高い品質と機能性をもつために3つのデザインテーマに沿っている必要があるようです。
テーマ | 私的要約 |
---|---|
Clarity(明快さ) | 「明快さ」つまり、「分かりやすさ」のこと。文字のサイズ、色、フォントだったり、アイコンが意味することを直感的に理解できたりすること。 |
Deference(服従) | アプリコンテンツの理解を助けるようなUI(滑らかな動きや視認性のあるデザインなど)にすること。 |
Depth(奥行き) | 奥行きのあるアプリデザインにすることで、視覚的にアプリの動きを理解しやすくすること。 |
「服従」という訳があっているか分からないが、コンテンツの理解を助けるためのデザインにしろって意味で服従なのかなと。英語難しい…。
デザインの原則
原則 | 私的要約 |
---|---|
Aesthetic Integrity(美的完全性) | アプリの外観と機能が調和されていること。 |
Consistency(一貫性) | アプリ利用者が思った通りに機能が動作すること。 |
Direct Manipulation(直接操作) | デバイスを回転させたりするなど操作で直感的にコンテンツを操作できること。 |
Feedback(フィードバック) | アプリ利用者の操作に対して、音を鳴らしたり、画面遷移したり、知覚可能な結果を示すこと。 |
Metaphors(隠喩) | iOSアプリ内での事象が現実世界のメタファーになっているってこと。 |
User Control(ユーザーコントロール) | アプリ利用者が自分でアプリをコントロールしていると感じられること。 |
Metaphors(隠喩)の説明が難しい。
アプリはデジタルの世界であり、ユーザ操作は現実のアナログな世界。
別の世界だけど、アプリ内での動きを現実世界のメタファーとして認識できるようにアプリを設計してねって話だと思う。よくある本をめくるアニメーションとかも、この原則が適用されている。
おしまい
テーマとデザインの原則については難しいことは言ってない気がする。
**「ユーザが分かりやすい、使いやすいアプリ作れよ!」**ってことかなと。
で、分かりやすい使いやすいをもう少し具体的に解説したのが、Human Interface Guidelinesなのだなと。(本記事では触れていない部分)
ガイドラインは現役iOSエンジニアにとって当たり前のことなのかもですが非常に学びになりました。天のお告げに感謝です。
https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/
https://developer.apple.com/jp/design/
https://developer.apple.com/jp/design/tips/
メモ(途中までまとめていた具体的な部分のガイドラインの一部)
加筆するかもしれないし、しないかもしれない!
App Architecture(アプリのアーキテクチャ)
Launching(アプリの起動)
アプリの起動は高速でシームレス(途切れない)必要があります。
設計のヒントは以下の通り。
ヒント | 私的要約 |
---|---|
起動画面を作る | アプリが起動されると、初期コンテンツを読み込むまで起動画面を表示させておく。これにより、アプリ利用者に高速で応答性の高いアプリという印象を与えられる。 |
適切な方向で起動する | デバイスの現在の向きに応じて画面を表示させる。 |
アプリの起動設定を最初から要求しない | 初期設定はデバイスの設定やiCloudなどの同期サービスを介して取得すること。設定変更は後ほどアプリ内でできるようにすること。 |
ライセンス契約や免責事項を表示しない | App Storeでアプリをダウンロードする前に読んでもらっておくこと。表示させたい場合はUXを損なわないようにすること。 |
アプリを再起動した場合、以前の状態を保持する | 再起動してもユーザに手順を一から踏ませないこと。中断したところから再開できるようにすること。 |
再起動を推奨させない | 再起動には時間がかかり、アプリの信頼性を損なうと同時に使いにくいように感じさせる。再起動を前提として設計にしないこと |
アプリの評価依頼をすぐにしない、頻繁にもしない | 起動時にアプリの評価依頼は適切なタイミングではない。まんべんなくアプリを利用してもらった後に評価依頼をすること。なお、評価依頼は強制させず、頻繁に依頼しないこと。 |
Onboarding(オンボーディング)
新規ユーザや久しぶりにアプリを使うユーザへ使い方を説明したりします。
任意みたいだけど、ユーザがアプリを最大限に活用するために役立ちUX向上にもつながるからオススメされてます。
設計のヒントは以下の通り。
ヒント | 私的要約 |
---|---|
役立つ内容を提供する | アプリ利用者がアプリの内容、使い方について適切に学べること。 |
すぐにアプリを楽しんでもらう | すぐにアプリを楽しめるように、チュートリアルなどはスキップできるようにすること。すでにアプリを利用している人にはチュートリアルなどは表示させないようにすること。 |
ヘルプの必要性を予測する | アプリ利用者が行き詰まりそうなときの解決策を用意しておくこと。(チュートリアルへのリンクを表示させるなど) |
チュートリアルに固執しない | チュートリアルで説明しすぎるアプリは優れたアプリとは言えない。直感的に利用できるようなデザインであることを最優先でアプリを作ること。 |
楽しく学び、発見があるようにする | 実践による学習は、チュートリアルを読むよりも楽しくて効果的。アニメーションなどを活用し状況に応じてアプリ利用者に使い方などを教育すること。 |
Loading(読み込み)
コンテンツの読み込み中に、空白または静的な画面が表示されると、アプリがフリーズしているように見える。
アプリ利用者がアプリから離脱しないよう以下の点を気にするとよい。
ヒント | 私的要約 |
---|---|
ロードが発生していることを示す | 少なくともローディングを伝えるためにスピナーを表示すること。可能であれば、待機時間を測定できるようにするとなおよし。 |
早くコンテンツを表示する | 期待するコンテンツが全て読み込まれるまで待たないこと。読み込まれていない部分は、徐々に読み込まれるような設計にすること。できるのであれば、バックグラウンドで事前にローディングしておくとよい。 |
ローディングと感じさせない | ゲーム、アニメーションなどを用いてローディングしてると感じさせない設計を検討すること。 |
Modality(一時的な画面)
モーダルを使うことで、現在のコンテンツと密接なコンテンツと理解することができる。
必要に応じて、行動をとることができる。
モーダルを使うときのヒントは次の通り。
ヒント | 私的要約 |
---|---|
意味があるときにモーダルを利用する | 現在のタスクとは異なるタスクを選択したり実行したりすることに注意を向けさせることが必要な場合にモーダルを使うこと。 |
アラートは必要な場面でのみ利用する | アラートはアプリ利用を中断し閉じるためにタップが必要となるため、利用が正当な場面で使うこと。 |
モーダル内のタスクはシンプルにする | アプリ利用者が混乱しないようなモーダルタスクにすること。複雑にするとアプリ利用者は今どこにいるかわからなくなる。 |
閉じるボタンを設置する | 「完了」や「キャンセル」ボタンでもいいので、ボタンでモーダルを閉じる機能が実装されていること。 |
データが損失しないようにする | モーダル内のアクションでデータが損失する可能性がある場合は、ユーザに状況を説明し解決方法をアクションシートで提示すること。 |
ポップオーバーの上に何も表示させない | アラートの可能性を除き、ポップオーバーの上に何も表示させないこと。 |
モーダルと識別できるタイトルを表示させる | モーダルコンテンツと分かるようなタイトルを表示することをオススメする。 |
モーダルの外観はアプリと調和させる | 同じアプリ内でモーダルだけ明らかに異なる外観にならないこと。 |
モーダルトランジションは適切なスタイルを利用する | アプリ利用者に混乱を招かないトランジションスタイルにすること。アプリ内でのトランジションスタイルに一貫性があること。 |