Contenu connexe
Similaire à アプリUI勉強会 in ネットイヤーグループ (20)
アプリUI勉強会 in ネットイヤーグループ
- 2. メンバー紹介
鈴木 健一鈴木 智大
イマジカデジタルスケープ、IADI、FICC inc. にてデザイン/ディレクション業務に
従事した後、2014 年にアプリやサービスのUI デザインを専門に行うSTANDARD
inc. を設立。マーケティングエージェンシーで培ったノウハウを基に、ユーザーの
課題解決とビジネスゴール達成を両立するUI デザインを提供する。
元ケーキ職人。
CEO,Designer Designer
DTP 制作会社、某新聞社を経て株式会社ナナメウエにてデザイナーとして数々の
アプリUI デザインを手がける。2014 年2 月からSTANDARD へ参画。ユーザー
の目的を最短で達成し、満足度を高めるためのユーザー体験やUI 設計、情報を
正確に伝えるためのビジュアルデザインを提供する。
元ブレイクダンサー。
- 3. メンバー紹介
吉竹 遼Designer
2011 年からフェンリル株式会社にてiOS / Android / Windows ストアアプリの企
画・UI デザインに従事。2014 年10 月よりSTANDARD へ参画。多くのプロジェク
トを手掛けた経験を活かし、ユーザーと情報が正しく繋がるインターフェイス、
心地よさを感じられるデザインを提供する。
高校は演劇専攻。
- 5. 本日の流れ
1. 利用中の体験とUI の間を繋ぐブリッジビルダー
鈴木 智大
2. アプリのUI 設計をする上で理解しておきたいコンポーネントの種類と用法
鈴木 健一
3. 質疑応答、ディスカッション
- 18. UI Flows概要
UI Flows とは?
37signals が使用しているツール
UI フロー図?
シナリオを元にタスクを分解
画面遷移の代替ツールとして期待できる
- 38. UI Flowsの実践
提供価値
仲間の位置を表示することで、戦場で一人ではないという不安を無くし、仲間同士で
の高度な連携などを可能にし、戦局を有利に進める。
味方同士の誤射を防止する。
シナリオ
ゲームがはじまる前に、味方同士の端末を登録。ゲームが開始すると、それぞれが別々
に動いても今どこにいるかという位置をマップに一覧表示をしてくれる。もし敵に撃
たれたりした場合には、自分のステータスを”死亡” などにすることで、残りの味方の
数を把握することができる。
- 44. UI Flowsの実践
テキストフィールド
ID を入力
テキストフィールド
名前を入力
ゲームを終了
ソルジャーを追加
開始ボタン
ボタンをタップ
ステータス一覧
ステータスを選択
マップ/ 友達の位置/
自分、友達のステータス
ステータスを変更
そのほか
- 45. UI Flowsの実践
ネクストステップ
他の場合のシナリオを元にUI Flows を複数作成
→ 例:離れている味方と簡易的なコミュニケーションをする
→ 例:ゲーム回数を元に死亡数の合計などをカウントする
各画面間の関係を元に画面構造を検討しプロトタイピング
- 61. アプリUIの主要な画面パターン
1. 導入画面
アプリを起動した直後に表示される画面。
アプリの機能の説明などの目的に用いられ、目的によっていくつかの種類が存在する。
導入画面の例
スプラッシュウォークスルーコーチマークエンプティステート
- 62. アプリUIの主要な画面パターン
1. 導入画面
スプラッシュ
・アプリの起動中に表示する画面
・アプリが起動動作をしている最中に表示し、待
ち時間のストレスを軽減するもの
・ロゴマークなどを表示し、特定のイメージを伝
えるもの
・起動中に表示される画面となるため、過度な演
出や大量のメッセージを表示させることは避ける
- 63. アプリUIの主要な画面パターン
1. 導入画面
ウォークスルー
・ユーザーが初めてアプリを起動した場合に、そのアプリがどんなも
のかを説明するための画面
・アプリで出来ることが多岐に渡る場合に、その機能をビジュアルと
テキストで端的に伝える役割を果たす。
複数画面にまたがって構成されることも多く、その場合はページイン
ジケーターが下部に表示されている
・使い方が想像出来ているユーザーやまずは使ってみたいと思うユー
ザーには障害に感じられることもあり、複数画面に渡るウォークスルー
を設置する場合にはスキップできる選択肢も検討する必要がある
- 64. アプリUIの主要な画面パターン
1. 導入画面
ウォークスルー
・ユーザーが初めてアプリを起動した場合に、そのアプリがどんなも
のかを説明するための画面
・アプリで出来ることが多岐に渡る場合に、その機能をビジュアルと
テキストで端的に伝える役割を果たす。
複数画面にまたがって構成されることも多く、その場合はページイン
ジケーターが下部に表示されている
・使い方が想像出来ているユーザーやまずは使ってみたいと思うユー
ザーには障害に感じられることもあり、複数画面に渡るウォークスルー
を設置する場合にはスキップできる選択肢も検討する必要がある
- 65. アプリUIの主要な画面パターン
1. 導入画面
コーチマーク
・画面上のUI がどんな意味や機能を持っているかをオーバーレイ表示
で説明するもの
・主要となる機能や初めにするアクション等を提示し、インストール
したばかりのユーザーに行動を促す
- 66. アプリUIの主要な画面パターン
1. 導入画面
エンプティステート
・表示するコンテンツが何もない場合に表示される画面
・なにも表示するものがないということを伝えると同時に、何をすれ
ばこの画面上にコンテンツが表示されるようになるかを提示し、アク
ションを促す役割も兼ねるもの
・類似した画面として、読み込みに失敗した場合の画面等も存在する
- 67. アプリUIの主要な画面パターン
2. トップ画面
アプリ起動画面直後に表示される、最もユーザーが接触することが多い画面。
ナビゲーションや主要機能などが設置され、他の画面と繋がるハブとなる役割を担います。
トップ画面の例
ポータル型タイムライン型ストア型
- 68. アプリUIの主要な画面パターン
2. トップ画面
ポータル型
・コミュニティサイトのような多くの情報を1 画面で表示することが
求められる場合に用いられる画面
・様々なUI コンポーネントを使い、主要な情報の提供と下階層の画面
への誘導の役割を担う
- 69. アプリUIの主要な画面パターン
2. トップ画面
タイムライン型
・ユーザーによる投稿やニュースのような時間軸を持った情報を順序
立てて表示する画面
・垂直方向に情報が積み重なって表示されることが多いため、何の軸
で表示されているのかが伝わりやすく、スクロールしながら情報が得
やすい構成が求められる
・表示された時点での最新の情報を取得するため、一覧をリフレッシュ
するためのボタンや過去の一覧を取得するための機能が付与されるこ
とが多い
- 70. アプリUIの主要な画面パターン
2. トップ画面
ストア型
・ユーザーが商品を購入できるアプリに使われる画面です。
・ポータル型とは違い、商品が購入できることにフォーカスされたア
プリのため、ユーザーが探している商品を簡単に探せる機能や、販売
促進のためのキャンペーン情報、また、購入したユーザーの評価や感
想などの情報が存在するため、何をトップ画面で表示するのかを意識
した設計が重要になります
- 71. アプリUIの主要な画面パターン
3. 一覧画面
コンテンツの一部を1つのコンポーネントとしてまとめて、一覧で表示する画面。
ユーザーのアクションに対する結果を表示する際に用いられることが多く、主にリスト型コンポーネントで構成される。
一覧画面の例
検索結果ギャラリーお知らせ
- 72. アプリUIの主要な画面パターン
3. 一覧画面
検索結果
・ユーザーの検索により表示される画面
・垂直型のリストを用いて検索結果を表示する
・検索結果の制御(ソート、絞り込み等)をする為に、セグメンテッ
ドコントロールというUI がよく利用される
・検索結果が複数画面にわたる場合はページャーやインフィニットリ
ストページャーが使われる
- 73. アプリUIの主要な画面パターン
3. 一覧画面
ギャラリー
・写真や動画などのサムネイルを一覧表示する画面
・一覧性を高めるために、画面の全面にわたってグリッドリストにし
て表現される
・コンテンツによっては補足説明をするためのキャプションと一緒に
配置される
- 74. アプリUIの主要な画面パターン
3. 一覧画面
お知らせ
・SNS などで、いいねやコメント等のフレンドからの反応を表示する
画面
・誰がどんな事をしたのか、何があったのか、を端的に表現したテキ
ストで一覧表示される
・アクションが多い場合がほとんどのため、垂直型のリストで表現さ
れる
- 75. アプリUIの主要な画面パターン
4. 詳細画面
アプリ内の深い階層にある画面で、コンテンツ単体を表示する画面。多くのアプリにとって、
この画面が利用する目的となることが多いため、使い心地について最も注意を払って設計する画面となる。
詳細画面の例
ビューア記事マッププロダクト
- 76. アプリUIの主要な画面パターン
4. 詳細画面
ビューア
・写真や動画を表示するための画面
・画面の移動のためにスワイプを用いたり、動画の進行状態の表示の
為にスライダーを用いる
・この画面の主役はコンテンツそのものであるため、UI 要素がコンテ
ンツ自体の閲覧を妨げないようにすることが重要
・コントローラー等もユーザーが利用しない際は非表示にするなど、
コンテンツに没頭できるような配慮もすべき
- 77. アプリUIの主要な画面パターン
4. 詳細画面
記事
・ニュース、ブログ記事等の文章を表示する画面
・テキストと画像のシンプルな構成ですが、スマートフォンでの閲覧
を考慮した文字サイズや行間、文字色等の配慮が必要
・記事の長さが長くスクロール量が多くなる傾向にあるため、ページ
トップへの移動を補助するような機能も検討する
- 78. アプリUIの主要な画面パターン
4. 詳細画面
マップ
・現在地や目的地の地図を表示する画面
・ビューアと同様、コンテンツである地図を画面内に大きく表示させ
る必要があるため、ナビゲーションやボタンの大きさや配置に配慮す
ることが重要
・複数の地点を表示するようなケースでは、詳細画面に加え一覧画面
に求められる機能も考慮した設計が必要
- 79. アプリUIの主要な画面パターン
4. 詳細画面
プロダクト
・商品情報を表示する画面
・この場合のユーザーの目的は商品の購入のため、購入検討に必要な
商品写真や価格、概要、購入者からの評判等の必要な情報を掲載する
・商品の説明や仕様などの掲載する情報が多くなるケースでは、垂直
型リストを多く用いる画面になる
- 80. アプリUIの主要な画面パターン
5. 入力・操作画面
ユーザーが何らかの動作をするための画面。小さい画面上で文字の入力などの複雑な動きをすることが
多くなるため、動作がしやすいか、誤動作を防げるかを考慮したUI を設計することが重要。
入力・
操作画面の例
サインアップ投稿カメラ撮影設定
- 81. アプリUIの主要な画面パターン
5. 入力・操作画面
サインアップ
・アプリの利用にユーザー登録が必要な場合に用いられる画面
・テキストフィールドを使って文字の入力を促す
・登録時の成功・失敗などのエラー表示や、確実な情報を促すための
補足情報などを考慮し、掲載する情報を検討する
- 82. アプリUIの主要な画面パターン
5. 入力・操作画面
投稿
・ユーザーが何らかの情報を投稿する際に用いられる画面
・投稿する対象となるテキストや写真、動画、位置情報などにより表
示方法は様々
・投稿するという行動はユーザーがアプリの利用に関わる際のキーと
なる行動のため、誤動作を防ぐような配慮が必要
- 83. アプリUIの主要な画面パターン
5. 入力・操作画面
カメラ撮影
・写真や動画を撮影するためにアプリを起動した際の画面
・ツールバーにシャッターを切るボタンを配置するものが主流
・撮影対象となる被写体が主なコンテンツとなるため、撮影対象を妨
げず、操作しやすい大きさや配置を心がける必要がある
- 87. アプリUIの主要な画面パターン
UI フローと一緒に考えると上手くまとまる
ユーザー登録画面マップステータス変更
UI フローは画面内の要素がどんなものかを明らかにするもの
複数のアクションをさせる場合はひとつのフロー図に納まらない場合も
複数のフローをまとめて1 つの画面とすることで画面遷移にできる
テキストフィールド
ID を入力
テキストフィールド
名前を入力
ゲームを終了
ソルジャーを追加
開始ボタン
ボタンをタップ
ステータス一覧
ステータスを選択
マップ/ 友達の位置/
自分、友達のステータス
ステータスを変更
- 88. アプリUIの主要な画面パターン
まとめ
5 種類の画面パターンを意識してアプリを利用・分析しておくことで、
UI フローの作成時の画面の集約がしやすくなり、アプリ全体の遷移や
主要なシナリオに必要なUI 要素と出来るアクション出しがスムーズになる。
続いて、各画面内の詳細なUI 設計へ
- 91. ナビゲーションのメリット・デメリット
ドリルダウン型
階層構造になっているものから1 つを選択してもらうために用いられるコンポーネント
メリット
ドリルダウン型が向いているケース
デメリット
・ツリー構造を作れるため階層化しやすい
・垂直方向に増やせるため拡張しやすい
・階層構造をまっすぐ掘り進めるため迷いにくい
・1 階層ずつしか上に戻れない
・見る対象が大きく変わる際に階層の深さが問題となる
・カテゴリの絞り込み等、階層構造が明確なナビゲーションの場合
・並列となるナビゲーション項目が存在せずシンプルな構造の場合
- 92. ナビゲーションのメリット・デメリット
タブ型
主要機能が並列する際に、どの画面からでもいつでも別画面に遷移するための
ナビゲーションとして用いられるコンポーネント
メリット
・複数の機能間を平行に移動できる
・iPhone のタブ型の場合指が届きやすい位置に置くこ
とができる
・領域を広く取れるため素早くタップしやすい
タブ型が向いているケース
デメリット
・追加できる項目数に限界がある(2 項目~ 5 項目程度)
・機能を端的に表現するラベリングが必要
・ユーザーが複数の機能間を遷移しながら利用することが想定される場合
・主要機能と補完となる機能が明確に分類できる場合
- 93. ナビゲーションのメリット・デメリット
スプリングボード型
利用頻度が平均化されている項目や、ユーザーの目的が異なる項目を並列に表示し、
グリッド上にアイコンとラベルを並べるUI コンポーネント
メリット
・アプリで出来ることを最初に掴んでもらいやすい
・タブ型より多くの項目を設置できる
・画面が広く使えるため、タップしやすいサイズで設置
できる
・グラフィック要素を大きく配置できるため印象付けに
活用できる
デメリット
・画面全体がナビゲーションとなるため、それ以外の情
報を得ることが出来ない
・目的意識が明確で1 つの機能のみを使っているユー
ザーにとっては不要な画面となってしまう
スプリングボード型が向いているケース
・どんな事ができるアプリか全体像をユーザーに提示したい場合
・提供する機能や情報がタブ型より多岐に渡る場合
- 94. ナビゲーションのメリット・デメリット
ドロワー型
サイドからスライドして項目を表示するUI コンポーネント。
項目リストは本体の画面から独立して縦方向のスクロールが可能で、ユーザーの目的が1 つではなく
複数あるようなアプリでの利用に多く用いられる。
メリット
ドロワー型が向いているケース
デメリット
・メイン画面でのナビゲーション項目を減らすことがで
きユーザーがコンテンツに集中できる
・縦方向のスクロールが可能なため項目数に制限がなく
いくつでも拡張可能
・ドロワーを開く際に必ず1 アクションが必要
・ナビゲーションが展開するまで何が出来るのかがわかりにくい
・画面の上部に配置される事が多く、ユーザーによっては指が届
きにくい状態になってしまう
・格納できる項目数に上限が無いため機能が複雑になりがち
・コンテンツに集中してもらうことが最優先の場合
・タブやスプリングボードでは収まりきらない場合
・同粒度のカテゴリで分類できる構造の場合
・主な主要機能が限られており、優先度が低い機能をまとめられる場合
- 102. ネクストステップ
パーツを活用しながら
画面毎に詳細なUI 設計をする
・ステンシルやUI コンポーネントを予め持っておくと作りやすい
・ビジュアルデザインのような作り込みは省略し、試作と改善のスピードを上げることのほうが重要
考慮しておくべきこと
・UI 設計がビジュアルデザインの原型になるため、アニメーションで差別化するようなUI を作るのであれば設計の時点から考慮しておく必要がある
・WF からビジュアルデザインへの飛躍は必要だけど飛躍し過ぎると設計時の意図通りにならないこともあるので注意
- 103. ネクストステップ
プロトタイピングへ
・Flinto や、inVision、Prott などを使って実践する
・シナリオごとに遷移を繋ぎナビゲーションの整合性や抜け漏れを無くす
・実際の端末での操作感を確認し、配置や遷移のアニメーション等を検討する
プロトタイピングツールの使い分けについての記事を近日公開予定
http://www.standardinc.jp/reflection/
- 106. もっと学びたい方へ
参考資料
A shorthand for designing UI flows by Ryan of Basecamp
https://signalvnoise.com/posts/1926-a-shorthand-for-designing-ui-flows
UI のフローをデザインするための簡易記法
http://d.hatena.ne.jp/sirocco634/20090921
iOS Human Interface Guideline
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/
Android Design
https://developer.android.com/design/index.html
使ってもらえるアプリの考え方
http://www.slideshare.net/takayukifukatsu/2012-15750990
スマートフォンのためのUI デザイン
http://www.amazon.co.jp/dp/4797372303
inVision
http://www.invisionapp.com/
Flinto
https://www.flinto.com/
Prott
https://prottapp.com/