参考元： iOS Human Interface Guidelines

iOS向けの設計

UI とアプリの中心となる機能とその関連
iOSに基づいたUI設計
様々なデバイスに対応

内容を尊重

画面全体を有効活用背景画像とその表側の詳細情報
半透明UIの活用一時的な要素であることを示す

明瞭性を与える

簡素な色使い
境界なしボタンの活用

奥行きを利用

半透明の利用
リストの階層

アクティビティとレイアウト

サイズクラス

全て XCode の StoryBoard にどの画面に対応するかが書いてあるので、それの対応をする

どの環境でも

主たるコンテンツに着目できる。サイズごとに変わってはいけない
レイアウトの不要な変更を避ける
１つの向きでしか動作しない場合はそれがわかるようにする
画面要素の重要度に応じて視覚的な重みやバランスを工夫する。大きな項目、色は目を惹きやすい
主要コンテンツはデフォルトの大きさのままで理解できるようにする。スクロールしたり拡大しないと見れないようではいけない
タップ可能なコントロール部品には 44x44 ポイントの領域を与える
余計なスプラッシュなどをできるだけ避ける
設定情報の入力を要求しない => デフォルト機能、デバイス組み込みの設定などの利用、アプリ起動時に求める
できる限りログイン要求を遅らせる
とりあえず試してみるために必要な情報のみを与える
アニメーションや対話機能を工夫して実際に操作しながら使い方を習得させる
いつでも中断し、飛ばして次に進める
アプリを再起動する際は状態を保存しておいて中断した時の状態から再開できるようにする

いつ停止しても

できるだけ早く、かつ妥当な頻度でユーザーデータを保存
停止時に現在の状態をできるだけ詳細なレベルまで保存

現在アプリのどの位置にいて次に目標とする画面にはどうすれば到達できるのか、いつでもわかる
ナビゲーションバーを使ってデータ回想を容易に辿れる
ページコントロールは各アプリ画面が同じ種類のものを表している場合に用いる
一般に角画面に到達するための経路は一通りにする. 同じ文脈で同じ画面を表示しなければならないときはモーダルなどの一時ビューを利用

モーダル

ユーザーの注意を喚起することが重要な場合
データが曖昧な状態にならないよう自己完結した時作業を最後まで進めさせたい場合
モーダルの作業は短時間で済むようにする。複雑だとそこから抜けて元に戻った時に何をしていたかがわからなくなる
モーダルを終了するための明確で安全な方法を用意
モーダルを閉じると作業結果hあどうなるか予測できるようにする

対話性とフィードバック

ユーザーは標準的なジェスチャの使い方を把握している. -> どのアプリでもジェスチャが同じように働くと想定している

対話型要素にはタッチ要素を誘う働きがある

画面上の要素が対話型であることを示すために余計な装飾が必要なことはほとんどない。

ボタンのボーダーとかも他の文章と被ってわかりにくくなったときだけ利用する。
適切な場合はiOSから情報を取得する. 日付や連絡先など

アニメーション

状態を伝え、フィードバックを返す
直接操作の感覚を高める
ユーザーのアクションの結果を視覚化する支援

ブランド

ロゴなどのブランド資産は、洗練された、** 控えめな方法 ** で組み込む。
ユーザーが着目するコンテンツのスペースを奪わない。ユーザーのコンテンツを主体とする
常にアプリロゴを表示するのは画面サイズ的に厳しい

色とタイポグラフィ

対話型要素とそれ以外に同じ色を使うことは避ける
ユーザーの木の散るような色使いは避ける
キーカラーを決める

iOS との一体化

必要ならば設定が可能であるようにする

成功しているアプリはほとんどのユーザーがすぐに使い始めることができるだけでなく、ユーザー体験を調整する便利な方法も提供している
必要に応じてユーザーが「設定」でアプリの設定に直接移動できるようにする。起動URLを用いる

設計戦略

一貫性の原則のチェック

アプリはiOSの標準との生合成が取れているか. ビューやアイコンを正しく利用しているか。
アプリ内での一貫性が保たれているか。テキスト、アイコン、アクション実行場所など。独自UIはそのアプリケーションを通じて同一になっているか

メタファ

現実世界のオブジェクトのアクションに似せる

レイヤわけしたビューを動かして奥にあるものを見せる
オブジェクトのドラッグ、フリック、スワイプ
書籍のページめくり

アプリケーションを定義する

アプリケーション定義ステートメントとは、アプリケーションの主な目的や対象ユーザーを、簡潔かつ具体的に記述した宣言のこと

初期段階で作成しておけば、構想や一連の機能を、統一感の取れた商品として実装する上で役立つ。アプリケーション定義ステートメントを使用して、
組み込もうとしている機能や動作が意味のあるものかを判断する。

ユーザーに好まれる可能性のあるすべての機能の洗い出し

まずはブレストから。プロダクトの本誌に関連するすべてのタスクを列挙。

対象ユーザーの決定

開発しようとするアプリの潜在ユーザーと、一般のiOSユーザーとの違いを明確にする。主たる構想の中で、潜在ユーザーにとって最も重要なのはなんなのか。
何に価値を置いているか。何を問題としているかを自問する

対象ユーザーの定義による機能の絞り込み

優れたアプリケーションは対象ユーザーが達成したいタスックだけに焦点を合わせるもの。

これでアプリケーション定義ステートメントを作成することができる。具体的には、
アプリケーションが実行する内容と対象ユーザーについて要約を作成する。

そこで立ち止まらない

新機能を追加すべきか検討する際には、アプリの主目的と、対象ユーザーにとって欠かせない機能かどうか検討する。不可欠でなければ除外する。
UI の外観や動作を検討する際には、ユーザーがシンプルでスリムなスタイルを評価するのか、よりはっきりとテーマを表現するスタイルを評価するのかを検討する。ユーザーがアプリで達成したいと期待していること、例えば重要な作業をこなす機能、素早く答えを得る機能、総合的な内容を深く振り下げる機能、楽しむ機能などから判断する。
使用する用語を検討する際には、対象ユーザーの専門知識とアプリのテーマが一致するよう心がける。

タスクに合わせてカスタマイズする

最良のアプリは、UIのカスタマイズと、目的の明確さや使いやすさとのバランスが取れている。このバランスを達成するには、設計プロセスの初期段階でカスタマイズについて
検討するようにする。ブランド戦略、オリジナリティ、市場性に関する問題はカスタマイズの判断に影響を与えることが多いため、カスタマイズがユーザー体験にどう影響するのかに
焦点を合わせ続けることは困難となる恐れがある。

まず、アプリケーション内のタスクについて考える。そのタスクをユーザーが実行する頻度や状況はどうか。

常にカスタマイズの理由を考える。カスタマイズによって、ユーザーが実行したいタスクが促進され、ユーザー体験が強化されることが理想。
できるだけ認識に関してユーザーの負担を増やさない。。ユーザーは標準UIの動作に慣れているため、操作の手を止めて使い方について考える必要がない。が、それ以外のパターンが来ると、それまでの体験の利点を失う。ユーザーは他のアプリケーションでは使えない新しい手順の学習を強制されることを嫌う可能性がある
常にコンテンツに従う。
標準コントロールを設計し直す前によく考える。
カスタム UI要素は徹底的にユーザーテストを行う

バー

ステータスバー

ステータスバーのテーマはグローバルもしくはビューコントローラ毎にセットできる

コンテンツをスクロールしてもステータスバーの領域に重ならないようにする
ナビゲーションコントローラを用いる
邪魔にならない画像をステータスバーの奥に表示する
コンテンツがステータスビューの領域に入らないように位置を管理する
必要であればネットワークアクティビティインジケータを表示する。ステータスバーに表示可能

ナビゲーションバー

半透明
キーボードが表示された時、ユーザーがジェスチャを行うときは非表示にできる
色合いを調整できる
ビューのタイトルをナビゲーションバーに表示するのは、それに意味がある場合に限る
必要ならばプロンプトを使ってこの画面でできることを明確にすることも検討する。検索時のヒントなど
スペースが十分あってもナビゲーションバーにコントロールを追加しすぎない
ナビゲーションバーもアプリケーション全体で一貫した外観にする

タブバー

半透明
画面の下
タブは同時に５つまで。　６つ以上の場合は最後はMoreが現れる
現在の画面やアプリケーションのモードを操作するユーザーコントロールを提供する目的でタブバーを使用しない
機能が使えない場合でもタブを削除しない

コンテンツビュー