アプリUI勉強会 in ネットイヤーグループ

アプリUI デザイン勉強会in ネットイヤーグループ株式会社

メンバー紹介
鈴木健一鈴木智大
イマジカデジタルスケープ、IADI、FICC inc. にてデザイン／ディレクション業務に
従事した後、2014 年にアプリやサービスのUI デザインを専門に行うSTANDARD
inc. を設立。マーケティングエージェンシーで培ったノウハウを基に、ユーザーの
課題解決とビジネスゴール達成を両立するUI デザインを提供する。
元ケーキ職人。
CEO,Designer Designer
DTP 制作会社、某新聞社を経て株式会社ナナメウエにてデザイナーとして数々の
アプリUI デザインを手がける。2014 年2 月からSTANDARD へ参画。ユーザー
の目的を最短で達成し、満足度を高めるためのユーザー体験やUI 設計、情報を
正確に伝えるためのビジュアルデザインを提供する。
元ブレイクダンサー。

メンバー紹介
吉竹遼Designer
2011 年からフェンリル株式会社にてiOS / Android / Windows ストアアプリの企
画・UI デザインに従事。2014 年10 月よりSTANDARD へ参画。多くのプロジェク
トを手掛けた経験を活かし、ユーザーと情報が正しく繋がるインターフェイス、
心地よさを感じられるデザインを提供する。
高校は演劇専攻。

本日の流れ
1. 利用中の体験とUI の間を繋ぐブリッジビルダー
　　鈴木智大
2. アプリのUI 設計をする上で理解しておきたいコンポーネントの種類と用法
　　鈴木健一
3. 質疑応答、ディスカッション

STANDARD での制作プロセス
ビジネスプランのヒアリングリサーチ・サービス設計UI 設計・プロトタイピングビジュアルデザイン
・プロトペルソナ作成
・リーンキャンバス作成
・シナリオ作成
・UI フロー作成
・画面遷移図作成
・ワイヤーフレーム作成
・プロトタイピング
・ユーザテスト
・ビジュアルデザイン
・レイアウト指示書作成
・関連アセット作成

本日の話は
・UI フロー作成

利用中の体験とUI の間を繋ぐ
ブリッジビルダー
Tomohiro Suzuki

デザインプロセス
STANDARD でのデザインプロセス

問題提起
シナリオ画面遷移ワイヤー

問題提起
成果物：画面遷移図
制作の全体像と構造を把握してUI デザイン
開発側との認識
既にクライアント側で作成しており、提示されることも

問題提起
Twitter の場合
タイムライン
ユーザーページツイート詳細リプライRetweet
ツイートフォローフォロワー設定ツイート詳細

問題提起
画面遷移での課題
フィードバック、エラーの情報が不十分
情報の関係性がわかりにくい
シナリオで定義された流れが見えにくい

UI Flows概要
UI Flows とは？
37signals が使用しているツール
UI フロー図？
シナリオを元にタスクを分解
画面遷移の代替ツールとして期待できる

UI Flowsの表記1
ユーザーが見るもの

UI Flowsの表記1
ユーザーがすること

UI Flowsの表記1

UI Flowsの表記1
ユーザーが見るものユーザーが見るもの

UI Flowsの表記1
メール一覧
メールの場合

UI Flowsの表記1
メール一覧
メールをタップ
メールの場合

メール一覧
返信ボタン
UI Flowsの表記1
メールの場合

メール一覧
返信ボタン
タップ
UI Flowsの表記1
メールの場合

メール一覧
返信ボタンテキストフィールド
タップ
UI Flowsの表記1
メールの場合

UI Flowsの表記2
ユーザーがすること①

UI Flowsの表記2
ユーザーがすること②

UI Flowsの表記2
ユーザーが見るものユーザーが見るもの
ユーザーがすること②

UI Flowsの表記2
メール一覧
メールの場合
返信ボタン
返信

UI Flowsの表記2
メール一覧
メールの場合
返信ボタン
返信
転送

UI Flowsの表記2
メール一覧
返信ボタン
返信
転送
テキストフィールド
転送先選択
メールの場合

UI Flowsの実践
UI Flowsを実際に作成

UI Flowsの実践
最近の悩み
最近サバゲーにハマっているんですが、フィールドで孤立するとヤバい

UI Flowsの実践
仮想のサービス
制作アプリ
味方レーダー
ターゲット
サバゲー（サバイバルゲーム）をやっていて、味方の位置を把握したい人

UI Flowsの実践
提供価値
仲間の位置を表示することで、戦場で一人ではないという不安を無くし、仲間同士で
の高度な連携などを可能にし、戦局を有利に進める。
味方同士の誤射を防止する。
シナリオ
ゲームがはじまる前に、味方同士の端末を登録。ゲームが開始すると、それぞれが別々
に動いても今どこにいるかという位置をマップに一覧表示をしてくれる。もし敵に撃
たれたりした場合には、自分のステータスを”死亡” などにすることで、残りの味方の
数を把握することができる。

UI Flowsの実践
ID を入力
ゲームがはじまる前に、味方同士の端末を登録

UI Flowsの実践
ID を入力
ゲームがはじまる前に、味方同士の端末を登録
名前を入力

UI Flowsの実践
ID を入力
名前を入力
ゲームが開始すると
開始ボタン
ボタンをタップ

UI Flowsの実践
それぞれが別々に動いても今どこにいるかという位置をマップに一覧表示
ID を入力
名前を入力
開始ボタン
マップ/ 友達の位置/
自分、友達のステータス

UI Flowsの実践
もし敵に撃たれたりした場合には、自分のステータスを”死亡” などにする
ID を入力
名前を入力
開始ボタン
ステータス一覧
ステータスを選択
ステータスを変更

UI Flowsの実践
ID を入力
名前を入力
ゲームを終了
ソルジャーを追加
開始ボタン
そのほか

UI Flowsの実践
ネクストステップ
他の場合のシナリオを元にUI Flows を複数作成
→ 例：離れている味方と簡易的なコミュニケーションをする
→ 例：ゲーム回数を元に死亡数の合計などをカウントする
各画面間の関係を元に画面構造を検討しプロトタイピング

UI Flowsの実践
ユーザー登録画面マップステータス変更
ID を入力
名前を入力
ゲームを終了
開始ボタン

画面遷移よりも情報の関係性、詳細が確認しやすい
簡単な仕様ができあがるので開発会社への発注がしやすくなる
ユーザーが利用する情報があるため、ワイヤーフレームを作成しやすい
簡単に作れるため、デザイナー以外のチームメンバーも参加できる
まとめ
UI Flowsのメリット

ありがとうございました

アプリのUI 設計をする上で理解しておきたい
コンポーネントの種類と用法
鈴木健一

はじめに
はじめに質問
PC とスマホ、前提の違いってなんでしょう？

PCとスマホの前提の違いとは？
・利用シーン
・利用方法（タッチスクリーンであること）
・ジェスチャ
・回線、オフライン時の使用
・画面サイズ
・ピクセル密度
・利用するユーザー層の幅広さ（リテラシーとか）

特に
画面サイズ

・比率：PC のディスプレイは横長、スマホは縦長
・グローバルナビゲーションのようなモジュールが使えない
・使える面積が少ない
・画面＝資源になる

・比率：PC のディスプレイは横長、スマホは縦長
・グローバルナビゲーションのようなモジュールが使えない
・使える面積が少ない
・画面＝資源になる
少ない資源で効率良く機能するUI を設計する必要がある

どうやって設計する？
Q. どう設計するの？

アプリ設計の指針となる
ガイドラインがあります
・iOS : iOS Human Interface Guidelines
・Android : Android Design

大切なところだけまとめました
・アプリUI の主要な画面パターン
・操作の起点となるナビゲーションのメリット・デメリット
・その他によく使われるコンポーネントの紹介

アプリUIの主要な画面パターン
アプリUI の主要な画面パターン

1. 導入画面
2. トップ画面
3. 一覧画面
4. 詳細画面
5. 入力・操作画面

1. 導入画面
アプリを起動した直後に表示される画面。
アプリの機能の説明などの目的に用いられ、目的によっていくつかの種類が存在する。
導入画面の例
スプラッシュウォークスルーコーチマークエンプティステート

1. 導入画面
スプラッシュ
・アプリの起動中に表示する画面
・アプリが起動動作をしている最中に表示し、待
ち時間のストレスを軽減するもの
・ロゴマークなどを表示し、特定のイメージを伝
えるもの
・起動中に表示される画面となるため、過度な演
出や大量のメッセージを表示させることは避ける

1. 導入画面
ウォークスルー
・ユーザーが初めてアプリを起動した場合に、そのアプリがどんなも
のかを説明するための画面
・アプリで出来ることが多岐に渡る場合に、その機能をビジュアルと
テキストで端的に伝える役割を果たす。
複数画面にまたがって構成されることも多く、その場合はページイン
ジケーターが下部に表示されている
・使い方が想像出来ているユーザーやまずは使ってみたいと思うユー
ザーには障害に感じられることもあり、複数画面に渡るウォークスルー
を設置する場合にはスキップできる選択肢も検討する必要がある

1. 導入画面
コーチマーク
・画面上のUI がどんな意味や機能を持っているかをオーバーレイ表示
で説明するもの
・主要となる機能や初めにするアクション等を提示し、インストール
したばかりのユーザーに行動を促す

1. 導入画面
エンプティステート
・表示するコンテンツが何もない場合に表示される画面
・なにも表示するものがないということを伝えると同時に、何をすれ
ばこの画面上にコンテンツが表示されるようになるかを提示し、アク
ションを促す役割も兼ねるもの
・類似した画面として、読み込みに失敗した場合の画面等も存在する

2. トップ画面
アプリ起動画面直後に表示される、最もユーザーが接触することが多い画面。
ナビゲーションや主要機能などが設置され、他の画面と繋がるハブとなる役割を担います。
トップ画面の例
ポータル型タイムライン型ストア型

2. トップ画面
ポータル型
・コミュニティサイトのような多くの情報を1 画面で表示することが
求められる場合に用いられる画面
・様々なUI コンポーネントを使い、主要な情報の提供と下階層の画面
への誘導の役割を担う

2. トップ画面
タイムライン型
・ユーザーによる投稿やニュースのような時間軸を持った情報を順序
立てて表示する画面
・垂直方向に情報が積み重なって表示されることが多いため、何の軸
で表示されているのかが伝わりやすく、スクロールしながら情報が得
やすい構成が求められる
・表示された時点での最新の情報を取得するため、一覧をリフレッシュ
するためのボタンや過去の一覧を取得するための機能が付与されるこ
とが多い

2. トップ画面
ストア型
・ユーザーが商品を購入できるアプリに使われる画面です。
・ポータル型とは違い、商品が購入できることにフォーカスされたア
プリのため、ユーザーが探している商品を簡単に探せる機能や、販売
促進のためのキャンペーン情報、また、購入したユーザーの評価や感
想などの情報が存在するため、何をトップ画面で表示するのかを意識
した設計が重要になります

3. 一覧画面
コンテンツの一部を１つのコンポーネントとしてまとめて、一覧で表示する画面。
ユーザーのアクションに対する結果を表示する際に用いられることが多く、主にリスト型コンポーネントで構成される。
一覧画面の例
検索結果ギャラリーお知らせ

3. 一覧画面
検索結果
・ユーザーの検索により表示される画面
・垂直型のリストを用いて検索結果を表示する
・検索結果の制御（ソート、絞り込み等）をする為に、セグメンテッ
ドコントロールというUI がよく利用される
・検索結果が複数画面にわたる場合はページャーやインフィニットリ
ストページャーが使われる

3. 一覧画面
ギャラリー
・写真や動画などのサムネイルを一覧表示する画面
・一覧性を高めるために、画面の全面にわたってグリッドリストにし
て表現される
・コンテンツによっては補足説明をするためのキャプションと一緒に
配置される

3. 一覧画面
お知らせ
・SNS などで、いいねやコメント等のフレンドからの反応を表示する
画面
・誰がどんな事をしたのか、何があったのか、を端的に表現したテキ
ストで一覧表示される
・アクションが多い場合がほとんどのため、垂直型のリストで表現さ
れる

4. 詳細画面
アプリ内の深い階層にある画面で、コンテンツ単体を表示する画面。多くのアプリにとって、
この画面が利用する目的となることが多いため、使い心地について最も注意を払って設計する画面となる。
詳細画面の例
ビューア記事マッププロダクト

4. 詳細画面
ビューア
・写真や動画を表示するための画面
・画面の移動のためにスワイプを用いたり、動画の進行状態の表示の
為にスライダーを用いる
・この画面の主役はコンテンツそのものであるため、UI 要素がコンテ
ンツ自体の閲覧を妨げないようにすることが重要
・コントローラー等もユーザーが利用しない際は非表示にするなど、
コンテンツに没頭できるような配慮もすべき

4. 詳細画面
記事
・ニュース、ブログ記事等の文章を表示する画面
・テキストと画像のシンプルな構成ですが、スマートフォンでの閲覧
を考慮した文字サイズや行間、文字色等の配慮が必要
・記事の長さが長くスクロール量が多くなる傾向にあるため、ページ
トップへの移動を補助するような機能も検討する

4. 詳細画面
マップ
・現在地や目的地の地図を表示する画面
・ビューアと同様、コンテンツである地図を画面内に大きく表示させ
る必要があるため、ナビゲーションやボタンの大きさや配置に配慮す
ることが重要
・複数の地点を表示するようなケースでは、詳細画面に加え一覧画面
に求められる機能も考慮した設計が必要

4. 詳細画面
プロダクト
・商品情報を表示する画面
・この場合のユーザーの目的は商品の購入のため、購入検討に必要な
商品写真や価格、概要、購入者からの評判等の必要な情報を掲載する
・商品の説明や仕様などの掲載する情報が多くなるケースでは、垂直
型リストを多く用いる画面になる

ユーザーが何らかの動作をするための画面。小さい画面上で文字の入力などの複雑な動きをすることが
多くなるため、動作がしやすいか、誤動作を防げるかを考慮したUI を設計することが重要。
入力・
操作画面の例
サインアップ投稿カメラ撮影設定

サインアップ
・アプリの利用にユーザー登録が必要な場合に用いられる画面
・テキストフィールドを使って文字の入力を促す
・登録時の成功・失敗などのエラー表示や、確実な情報を促すための
補足情報などを考慮し、掲載する情報を検討する

投稿
・ユーザーが何らかの情報を投稿する際に用いられる画面
・投稿する対象となるテキストや写真、動画、位置情報などにより表
示方法は様々
・投稿するという行動はユーザーがアプリの利用に関わる際のキーと
なる行動のため、誤動作を防ぐような配慮が必要

カメラ撮影
・写真や動画を撮影するためにアプリを起動した際の画面
・ツールバーにシャッターを切るボタンを配置するものが主流
・撮影対象となる被写体が主なコンテンツとなるため、撮影対象を妨
げず、操作しやすい大きさや配置を心がける必要がある

設定
・アプリの設定を変更するための画面
・垂直型リストとスイッチを組み合わせて構成されることが多い
・設定項目が多岐にわたる場合には、ドリルダウンを使って階層式に
する場合も

身近なアプリを分類してみた例
Twitter
導入画面トップ画面一覧画面
入力・
操作画面
詳細画面
スプラッシュタイムラインツイート一覧
ユーザ一覧
検索結果
設定画面
ツイート詳細
ユーザ詳細

身近なアプリを分類してみた例
Mail
一覧画面
入力・
操作画面
トップ画面を兼ねる
一覧画面
アカウント一覧
新規メール
作成
受信メール
一覧
詳細画面
メール詳細

UI フローと一緒に考えると上手くまとまる
ユーザー登録画面マップステータス変更
UI フローは画面内の要素がどんなものかを明らかにするもの
複数のアクションをさせる場合はひとつのフロー図に納まらない場合も
複数のフローをまとめて1 つの画面とすることで画面遷移にできる
ID を入力
名前を入力
ゲームを終了
開始ボタン

まとめ
5 種類の画面パターンを意識してアプリを利用・分析しておくことで、
UI フローの作成時の画面の集約がしやすくなり、アプリ全体の遷移や
主要なシナリオに必要なUI 要素と出来るアクション出しがスムーズになる。
続いて、各画面内の詳細なUI 設計へ

ナビゲーションのメリット・デメリット
操作の起点となる

アプリでも、ナビゲーション重要。
複数の画面間を遷移しながらユーザーがやりたいことを実現するアプリでは、画面を遷移させる機能を担うナビゲーションが重要な
存在となります。ここではPC サイトとは違う特徴的なナビゲーションを取り上げながら、それぞれを採用するメリットやデメリットを
紹介していきます。
ドリルダウン型タブ型スプリングボード型ドロワー型

ドリルダウン型
階層構造になっているものから1 つを選択してもらうために用いられるコンポーネント
メリット
ドリルダウン型が向いているケース
デメリット
・ツリー構造を作れるため階層化しやすい
・垂直方向に増やせるため拡張しやすい
・階層構造をまっすぐ掘り進めるため迷いにくい
・1 階層ずつしか上に戻れない
・見る対象が大きく変わる際に階層の深さが問題となる
・カテゴリの絞り込み等、階層構造が明確なナビゲーションの場合
・並列となるナビゲーション項目が存在せずシンプルな構造の場合

タブ型
主要機能が並列する際に、どの画面からでもいつでも別画面に遷移するための
ナビゲーションとして用いられるコンポーネント
メリット
・複数の機能間を平行に移動できる
・iPhone のタブ型の場合指が届きやすい位置に置くこ
とができる
・領域を広く取れるため素早くタップしやすい
タブ型が向いているケース
デメリット
・追加できる項目数に限界がある（2 項目～ 5 項目程度）
・機能を端的に表現するラベリングが必要
・ユーザーが複数の機能間を遷移しながら利用することが想定される場合
・主要機能と補完となる機能が明確に分類できる場合

スプリングボード型
利用頻度が平均化されている項目や、ユーザーの目的が異なる項目を並列に表示し、
グリッド上にアイコンとラベルを並べるUI コンポーネント
メリット
・アプリで出来ることを最初に掴んでもらいやすい
・タブ型より多くの項目を設置できる
・画面が広く使えるため、タップしやすいサイズで設置
できる
・グラフィック要素を大きく配置できるため印象付けに
活用できる
デメリット
・画面全体がナビゲーションとなるため、それ以外の情
報を得ることが出来ない
・目的意識が明確で1 つの機能のみを使っているユー
ザーにとっては不要な画面となってしまう
スプリングボード型が向いているケース
・どんな事ができるアプリか全体像をユーザーに提示したい場合
・提供する機能や情報がタブ型より多岐に渡る場合

ドロワー型
サイドからスライドして項目を表示するUI コンポーネント。
項目リストは本体の画面から独立して縦方向のスクロールが可能で、ユーザーの目的が1 つではなく
複数あるようなアプリでの利用に多く用いられる。
メリット
ドロワー型が向いているケース
デメリット
・メイン画面でのナビゲーション項目を減らすことがで
きユーザーがコンテンツに集中できる
・縦方向のスクロールが可能なため項目数に制限がなく
いくつでも拡張可能
・ドロワーを開く際に必ず1 アクションが必要
・ナビゲーションが展開するまで何が出来るのかがわかりにくい
・画面の上部に配置される事が多く、ユーザーによっては指が届
きにくい状態になってしまう
・格納できる項目数に上限が無いため機能が複雑になりがち
・コンテンツに集中してもらうことが最優先の場合
・タブやスプリングボードでは収まりきらない場合
・同粒度のカテゴリで分類できる構造の場合
・主な主要機能が限られており、優先度が低い機能をまとめられる場合

よく使われるコンポーネントの紹介
その他によく使われるコンポーネントの紹介

セグメンテッドコントロール
・複数の項目を1 つのグループのようにまとめたコンポーネント
・検索結果のソートや表示されている内容を別の軸から再表示するような時に、画面の状態をコントロールするために用いられる
・タブ型のナビゲーションと機能は似ているが、想定している用途が違うため、グローバルなナビゲーションがある際の位置関係に注意

リフレッシュコントロール
・タイムラインなどの、垂直に表示されているリストの情報を最新の状態にする際に用
いられるコンポーネント
・リストを画面下部に引っ張ることで実行される
・下に引っ張った分、上に新しい情報が読み込まれる直感的な部分があるが、画面を表
示した時点では気付かれないため、引っ張れることを気付かせるようなデザインが必要

カルーセルパネル
・コンテンツを上下ではなく左右にスワイプして切り替えられるコンポーネント
・高さを一定にできるため、縦方向に複数並べて利用したり他のコンポーネントと併用
することができる
・画面外の左右に情報を隠すことができるため画面を有効利用できるが、画面内で見え
る要素が1 つだけとなるため、カルーセルパネルであることがわかりやすいデザインに
する必要がある
・カルーセル後半の情報はユーザーがスワイプまたは時間経過等で表示されるため、確
実に閲覧をさせたいのであれば別の方法も検討してみることが重要

モーダルメッセージ
・画面中央にオーバーレイする形でメッセージを表示するコンポーネント
・ユーザーに注意を促す場面や必ず読んで欲しいものがある場合などに利用される
・一番確実にメッセージを伝えられるコンポーネントだが、ユーザーの行動を強制的に
止めるものであるため、多用するとユーザーに負担がかかってしまったり、見慣れてし
まうことでユーザーが内容を見なくなってしまう恐れがあるため、利用箇所は慎重に検
討する

まとめ
各ナビゲーションの種類や特徴を理解することで、
画面間を繋ぐナビゲーションに何を採用するかを素早く判断することができる。
各コンポーネントの種類や特徴を理解することで、
UI フローが作成しやすくなり、画面毎に必須となる要素と機能が分かる。

この後はどうする？

パーツを活用しながら
画面毎に詳細なUI 設計をする
・ステンシルやUI コンポーネントを予め持っておくと作りやすい
・ビジュアルデザインのような作り込みは省略し、試作と改善のスピードを上げることのほうが重要
考慮しておくべきこと
・UI 設計がビジュアルデザインの原型になるため、アニメーションで差別化するようなUI を作るのであれば設計の時点から考慮しておく必要がある
・WF からビジュアルデザインへの飛躍は必要だけど飛躍し過ぎると設計時の意図通りにならないこともあるので注意

プロトタイピングへ
・Flinto や、inVision、Prott などを使って実践する
・シナリオごとに遷移を繋ぎナビゲーションの整合性や抜け漏れを無くす
・実際の端末での操作感を確認し、配置や遷移のアニメーション等を検討する
プロトタイピングツールの使い分けについての記事を近日公開予定
http://www.standardinc.jp/reflection/

ビジュアルデザインへ
・設計意図を踏まえつつ、競合と差別化でき、触ってみたいと感じさせるビジュアルデザインを作る
・サービスやアプリにおけるUI は本来透明化すべきもののため、突飛なビジュアルデザインが主役になるようなアプリは
　長く利用されることは稀（ゲームとかは別）
利用者の興味を喚起でき、最初の利用を促し、
継続的な利用の妨げにならないようなビジュアルデザインが理想

ありがとうございました
コンポーネントの種類と用法を理解して
素早く正しく設計しましょう！

もっと学びたい方へ
参考資料
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/

アプリUI勉強会 in ネットイヤーグループ

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie アプリUI勉強会 in ネットイヤーグループ

Ähnlich wie アプリUI勉強会 in ネットイヤーグループ (20)

アプリUI勉強会 in ネットイヤーグループ