デザインガイドラインの軽くまとめ

参考元： iOS Human Interface Guidelines

iOS向けの設計

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

内容を尊重

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

明瞭性を与える

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

奥行きを利用

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

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

サイズクラス

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

どの環境でも

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

いつ停止しても

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

ナビゲーション

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

モーダル

• ユーザーの注意を喚起することが重要な場合

• データが曖昧な状態にならないよう自己完結した時作業を最後まで進めさせたい場合

• モーダルの作業は短時間で済むようにする。 複雑だとそこから抜けて元に戻った時に何をしていたかがわからなくなる

• モーダルを終了するための明確で安全な方法を用意

• モーダルを閉じると作業結果hあどうなるか予測できるようにする

対話性とフィードバック

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

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

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

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

アニメーション

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

ブランド

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

色とタイポグラフィ

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

iOS との一体化

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

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

設計戦略

一貫性の原則のチェック

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

メタファ

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

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

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

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

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

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

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

対象ユーザーの決定

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

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

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

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

そこで立ち止まらない

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

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

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

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

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

バー

ステータスバー

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

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

ナビゲーションバー

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

タブバー

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

コンテンツビュー

アクティビティ

現在のコンテンツと連携して動作可能な、システムが提供するタスクまたはカスタムタスクを表す

アクティビティビューコントローラ

• なんらかの方法で指定するコンテンツに対して実行可能な、一連のタスクを表示するために使う。
• アクティビティビューコントローラを表示するためのボタンは生成しない。

コレクションビュー

• アイテムの一部を視覚的に区別して表示するビュー、あるいは装飾用のアイテムを収容できる
• レイアウトを切り替える際、独自の無イメーション効果を与えることができる
• ジェスチャリコグナイザを追加することにより独自のアクションを実行できる

注意

• テーブルビューが適している場合はそちらを使う。 テキスト情報の表示や編集にはスクロールリストを使う方が容易
• アイテムを選択しやすくする

Popover

コントロールや画面上の領域をタップしたとき、一時的に表示されるビュー

• 自己完結型のモーダル

• 水平方向が標準の環境では、矢印を表示してどこから表示されたのかを示す

• 背景が半透明で、手前のコンテンツにぼかしを施す

• 様々なオブジェクトやビューを含められる

• ポップオーバーを閉じるボタンをつけない

• 境界外のどこかをタップしたら閉じる

• ポップバーを大きくしない

テーブルビュー

• テーブルの内容が膨大または複雑な場合、何かを表示する前に、すべてのデータが利用可能になるのを待機しない
• 最新データの到着を待つ間における、古いデータの表示を検討する

アラート

• メッセージを提供する場合は、短くて完全な文を作成
• ボタンのテキストはできるだけアラートに直接関連する同士を使用する。 Ignore, View All, Reply など
• 単純な受け入れを示す選択肢として、他に候補がなければ OK を使用する。「はい」や「いいえ」の使用は避ける
• できる限り「あなた」、「私」の使用は避ける

アクションシート

• タスクを実行する別の方法を掲示する。
• 危険な可能性のあるタスクを完了する前に、確認を求める。

モーダルビュー

フルスクリーン以外にも、画面外がグレーアウトされたようなモーダルを出すことも可能

• ポップオーバーの前面にモーダルビューを表示しない
• モーダルビューの全体的な外観とアプリの外観を調和させる。キャンセル、完了のナビゲーションバーの統一など
• モーダルビューを表示するのに適したトランジションスタイルを選ぶ。
• 垂直: モーダルビューは画面の下から上に向かってスライドし、閉じると下端に向かって降りる
• フリップ: 左右バージョン　モーダルはまるで現在のビューの背景であるかのように見える

アイコンや画像の設計

アプリアイコン

• ユーザーが認識しやすい普遍的な画像を用いる
• 簡潔であることを重視する
• アプリの核となる着想を、抽象的に解釈してみる。