iOS ヒューマンインターフェースの原則
iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴から情報設計の原則、それぞれ何のための部品なのか、という解説がされています。なぜこうなったのか、なぜこれが良くてあれが駄目なのか、Apple の UI デザイナーは何を考えてこのような設計にしたのか、HIG ではそのようなところまでは説明されていないことがあります。いくら内容を丸暗記したとしても「なぜ」がわからなければ本質から理解したとは言えません。
よくある UI デザインにおける誤り、『磨りガラス効果がかっこいい』『アニメーションしておくとかっこいい』『ボタンは右配置の方が押しやすい』『色が綺麗』『流行っているから優れている』…などがありますが、そういうことではないのです。いや実際かっこいいかわいいの感覚は重要ですが、見た目が何となくそれっぽいだけでは優れた UI とは言えません。磨りガラスでも何でも必ずそこには意味があります。だからこそ HIG の理解が必要なのです。
今回は HIG の「なぜ」を理解するために役立つ 最低限守るべき原則 を解説を交えてご紹介しようと思います。
この記事を読むと例えば
『iOS のプッシュ遷移とモーダル遷移の違いがわからない！』
というのが理解できるようになります。
なお、前提知識として iOS Human Interface Guidelines（日本語版は若干古いかもしれない）はある程度読んでおくことをおすすめします。Web の UI 設計に関しては HIG でも触れられていないため特に考えないものとします。
この記事は試しに Medium を使ってみるための投稿です。内容はこの Qiita 記事と同じものです。
情報の配置は左が否定・右が肯定である
通常 iOS では左に否定、右に肯定にあたる情報が配置されます。Mac ユーザーにはとても自然なことだと思いますが、Windows あるいは少し前の Android のユーザーにはあまり馴染まないかもしれません。ですがこれは非常に重要な原則ですので理解しておいてください。
例えば2ボタンのアラートを見てみると、左側に破壊的なアクション、右側に肯定的（もっとも自然）なアクションが置かれます。稀に2ボタンが縦に並ぶ場合もありますが、これはボタンのラベル幅が長い場合に自動的に上下配置に変更されているものです。
アラートのボタン配置は HIG でも指南されています。
https://developer.apple.com/jp/documentation/UserExperience/Conceptual/MobileHIG/Alerts.html
ボタンを適切に配置する。タップするのが最も自然なボタンとは、一番実行したいであろうアクションを実行すること、誤ってタップしても問題が生じにくいこと、という条件を満たすもののことです。これを次のように配置します。
•最も自然なボタンのアクションが非破壊的であれば、2つボタン型アラートの右側に置いてください。アクションを取り消すボタンは左側にします。
•最も自然なボタンのアクションが破壊的であれば、2つボタン型アラートの左側に置いてください。アクションを取り消すボタンは右側にします。
これはアラートに限らず iOS のあらゆる場面で見ることができます。ホーム画面でアイコンを削除しようとした時の×ボタン、Safari のタブを閉じる×ボタンならびにスライド方向なども則っています。
- 基本的に情報は「左が否定・右が肯定」であるが、文脈で判断する必要がある
- アクションの目的が自然であればそれが右、キャンセルは否定的とみなされ左に配置される
- アクションの目的が破壊的であればそれは否定的とみなされ左に配置される。そしてキャンセルが肯定的になるので右に配置される。キャンセルが常に左とは限らない
情報は左から右に流れる
先ほど「左が否定・右が肯定」と述べましたが、一方で情報は左から右に流れるという原則もあります。これはわかりやすく、UINavigationController のプッシュ遷移の方向から slide to unlock の方向まで、あらゆる要素に見られる共通事項です。
- プッシュ遷移の方向・戻る方向
- slide to unlock の方向
- スライダーやプログレスバーの方向
- ホーム画面など横スクロールの方向
- テキストの入力方向・削除方向
これは簡単な話で、横書き文を左から右に読む文化に由来します。よく “Z” に沿って視線が動くと言われますが背景にあるのは横書き文の読み方にあり、そして各種 UI 部品もそれに合わせて設計されています。だから英語や日本語などの文化圏では親＝左・子＝右ということになります。
一方でアラビア語など横書き文を右から左に読む言語環境では UI がまるまる左右反転するという、日本人の我々からすると奇妙な画面構成になります（iOS 9）。一部の数字を見れば、この画像がただの左右反転ではないことは理解できると思います。
つまりこれは情報の流れが左右逆転したことになり、親＝右・子＝左になります。同様に肯定・否定の配置も逆転します。他言語対応する場合にはこのように情報設計から考慮する必要があります。
ナビゲーションバーのボタン配置
ナビゲーションバーのボタンは適当に配置しているわけではありません。基本は前述の情報配置の原則に従いますが、その画面に至るまでの文脈で決まります。ざっくり箇条書きすると以下になります：
- その画面単体では考えず、そこに至るまでの文脈を考慮する
- その画面でできる主目的によって左右が決まる
- 遷移先画面の上下関係によって左右が決まる
- 編集に対する完了あるいはキャンセルは同じ位置
- キャンセルと完了がそれぞれ配置される場合は通常完了が右
- アクション系ボタンは右側から詰める
- アクション系ボタンが2つ以上あるならツールバーに収める（iPhone）
- ナビゲーションバーに収まるならそこに収める（iPad）
- ツールバーが使えるならツールバーを活用する
- モーダルビューのキャンセルボタンは遷移元のボタン配置に従い同じ位置になる場合がある
アプリの目的はひとつである
純正アプリを観察していると気付くと思いますが、アプリでできることは結局たったひとつの目的を達成するための機能だけだということです。ユーザーは何か目的を達成したいと思ってから起動するアプリを選択するので、その目的とは異なる体験がそこにあるのは不自然ですよね。
よくやってしまう誤りは「アプリに本質ではない目的を多数設置してしまう」ことです。アプリの機能が膨れ上がって使いづらくなってしまう原因はここにあります。例えば上の画像で言うと、写真とカメラを同一アプリにするようなことです。なぜ写真とカメラが別アプリになっているのか考えれば当たり前なのですが、もしこれらを0から設計するとなるとここは落とし穴になりかねないところでしょう。
ひとつのアプリに複数の目的を設置することはモバイルでは非常に難しいことですので避けるのが賢明です。Facebook ですら Messenger 機能を別アプリに分離しました。メッセージアプリにそれとは無関係な機能を載せるとかは本来のアプリの目的とはかけ離れているので iOS 的にはあまり良いとは言えないでしょう。
画面遷移の目的地はひとつである
アプリの目的はひとつだと述べました。同様にその目的に至る一連の画面の目的地もひとつであると言えます。ここで再び純正アプリを観察すると、App Store はタブ型ナビゲーションを採用していますが結局どのタブからもアプリの詳細画面にたどり着くことができ、「アプリのインストール」という目的を必ず達成することが可能です。
画面を設計するとき、目指すべき「目的地」を設定することができれば、それぞれの画面で何をすべきなのか、そして次にどこに遷移するのか、は明確になると思います。
画面遷移の種類
iOS の画面遷移の種類は主に3種類あって、これらをコンテクストに合わせて適切に使い分ければ正しい画面遷移を設計することができます。
- プッシュ（階層型）
- モーダル（分岐型）
- タブ（並列型）
プッシュ（階層型）
UINavigationController のプッシュ遷移です。「情報は左から右に流れる」という原則に従って右側に潜っていきます。画面遷移の一連の流れをひとつのタスクとして捉えたとき、プッシュ遷移はタスクを進行します。
アプリの UI を設計するならまずはプッシュ遷移に収められるかを検討すると良いでしょう。これが最もシンプルな iOS アプリの形です。
注意したいのは、通常「戻る」はキャンセルにはならないということです。画面で行ったことは不可逆的に実行され得るものです。Twitter のタイムラインからツイート詳細画面に潜ってお気に入りした事実を「戻る」ことで無かったことにすることはできません。「戻る」とはあくまで前の画面に移行するだけなのです。だから UINavigationController の popViewControllerAnimated() は無効化することができないのです。
設定アプリでよく見られる例ですが、スイッチを切り替えたらもうそれは確定した事実として保存され、後は戻るだけです。もし確定させるアクションあるいはキャンセルを取り扱いたいのであれば、保存を右上に置くか、タスク全体をモーダルで分岐してキャンセルと完了（保存）を配置すると良いでしょう。
モーダル（分岐型）
モーダルビューは一時的な画面の状態です。プッシュ遷移の一次元的な流れをひとつのタスクと捉えたとき、モーダルビューはそこから分岐したサブタスクです。モーダルビューの中で更に別のプッシュ遷移が起こることもあります。
モーダルビューは必ず元のタスク（表示元画面）に戻れなければなりません。なぜならユーザーは今自身が何をやろうとしているのかを理解して画面を操作しています。そしてモーダルは一時的なものだとも理解していますから、元の画面に戻れることを期待します。そこではタスクの完了あるいはキャンセルを行うアクションが必要になります。右上などに完了やキャンセルボタンを設置するとか、セルを選択したら処理を実行して閉じるとか、そのような設計にします。
多重モーダルは推奨されませんが二重三重程度であれば許容範囲でしょう。もしそれ以上にモーダルを重ねるようなら画面設計を見直すべきです。なぜならユーザーは自身がどこからやってきたのかを忘れてしまうからです。前の前の前のモーダルが何をしていたタスクなのかいちいち覚えていられません。ナビゲーションの経路をシンプルにすることはユーザーにとって易しい設計です。
Twitter アプリの例
Twitter アプリを考えたとき、目的は「ツイートを読む」ことです。なので一連の画面はプッシュ遷移でツイートの詳細画面まで繋がっている必要があります。「ツイートを投稿する」という行為は言い換えると「ツイートをタイムラインに追加する」ことなのでツイートを読む目的とは若干違う意味になってしまいますが、ここでモーダルの出番です。ツイートを読むことがメインタスクだとしたら、ツイートを追加することはそこから分岐したサブタスクになるので、一連の画面のいずれかからモーダルビューで投稿画面に遷移させます。投稿を完了あるいはキャンセルしたらモーダルビューを閉じて元のタイムラインに戻ります。
これがモーダルの正しい使い方です。
タブ（並列型）
アプリの目的はひとつである前提で目的までの導線を考えたとき、それが必ずしも1本とは限りません。ファーストビューがタイムライン的な画面である一方で、検索画面が別にあったり、新着の情報のみを取り扱う画面もあるかもしれません。このように導線が複数ある場合にはタブのような並列型遷移を採用します。
UITabBar はグローバルナビゲーションのための UI 部品で、iPhone では最大5個まで表示できます（それ以上は「その他」タブにまとめられる）。iPhone の5個というのは多すぎす少なすぎずといった数字で、もしもこれ以上タブが増えるようならそれは機能が多すぎると考えられ、情報設計から見直すべきです。なので大して重要ではない「設定」などはタブにはもったいなすぎるため置かないほうが良いでしょう。設定なんてそう頻繁に変更しませんよね？ Twitter アプリのように歯車アイコンを画面の奥深くに追いやるか、そもそも「設定アプリ」に任せてしまってアプリから設定画面自体を無くしてしまうことを検討すると良いでしょう。
ハンバーガーメニューがダメな理由
はっきり言ってハンバーガーメニューはゴミ溜めも同然です。中には煌く石もあるでしょうがそれを見つけるのは困難です。世に溢れているコレはどう見ても「その他いろいろをとりあえず詰めた謎の三本線」メニューですし、UI デザイナーとして安易に採用してしまうのは負けたのも同然と私は考えます。
アプリのグローバルナビゲーションとして安易にハンバーガーメニューを採用してしまうというのは、アプリで何をしたいのか、させたいのか、その目的をうまく設定できていない証拠です。普通はハンバーガーメニューをわざわざ採用しなければならないほどモバイルのナビゲーションは膨れ上がるはずがありません。情報の整理と優先度設定ができていないから、「ホーム」「設定」「利用規約」「ヘルプ」「ログアウト」が同じメニューに並んでしまうことになるのです。そしてスクロール型のメニューだから更にそこに項目を追加したくなるのです。iPhone のタブは5個までという制約が設けられている意味がよく理解できます。試しにタブバーに（表示数に制限がないものとして）並べ直してみれば、そこに違和感があるのは明確です。
スプリットビューはおそらく iOS の UIKit では最もハンバーガーメニューに近い存在ですが、メールや設定アプリのような Master-Detail パターンを一つのビューコントローラーに収めたインターフェースです。※一応ドロワーっぽいことも実現できます。用途としてはプッシュして潜っていく階層型ナビゲーションのためのものなので、ドロワーによる並列型ナビゲーションのために使うものではありません。
関連記事：君たちはそんなにハンバーガーメニューが好きなのかね？
むすび
iOS のヒューマンインターフェースを理解する上で重要なのは、どのように情報が配置されるのか ということです。見た目はその後からついてきます。なぜ戻るが左なのか、なぜ追加が右なのか、はこれらの原則に則って決まります。そうやって色々な要素が組み合わさって画面が出来上がり、そしてアプリが出来上がっているので、iOS アプリの UI デザインではまず情報設計をしっかりと考える必要があります。
HIG はもちろん読んでおいたほうが良いですが、そこには詳しく書かれていない事柄も多く、それらを理解するためにもまずは Apple 純正アプリをよく観察してみることから始めるときっと「馴染みすぎていて気付かなかった発見」があります。これはぜひ試してみてください。少なくとも純正アプリは正解なので間違いはありません。