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

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

メンバー紹介

鈴木健一鈴木智大イマジカデジタルスケープ、IADI、FICC inc. にてデザイン／ディレクション業務に従事した後、2014 年にアプリやサービスの UI デザインを専門に行う STANDARD inc. を設立。マーケティングエージェンシーで培ったノウハウを基に、ユーザーの課題解決とビジネスゴール達成を両立する UI デザインを提供する。元ケーキ職人。

DTP 制作会社、某新聞社を経て株式会社ナナメウエにてデザイナーとして数々のアプリ UI デザインを手がける。2014 年 2 月から STANDARD へ参画。ユーザーの目的を最短で達成し、満足度を高めるためのユーザー体験や UI 設計、情報を正確に伝えるためのビジュアルデザインを提供する。元ブレイクダンサー。

CEO,Designer Designer

メンバー紹介

吉竹遼 Designer

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

http://www.standardinc.jp/

本日の流れ

1. 利用中の体験と UI の間を繋ぐブリッジビルダー　　鈴木智大

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

3. 質疑応答、ディスカッション

ここで質問です

STANDARD での制作プロセス

ビジネスプランのヒアリングリサーチ・サービス設計 UI 設計・プロトタイピングビジュアルデザイン

・プロトペルソナ作成

・リーンキャンバス作成

・シナリオ作成

・UI フロー作成

・画面遷移図作成

・ワイヤーフレーム作成

・プロトタイピング

・ユーザテスト

・ビジュアルデザイン

・レイアウト指示書作成

・関連アセット作成

本日の話は

ビジネスプランのヒアリングリサーチ・サービス設計 UI 設計・プロトタイピングビジュアルデザイン

・プロトペルソナ作成



・UI フロー作成








宜しくお願いします

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

Tomohiro Suzuki

ビジネスプランのヒアリングリサーチ・サービス設計 UI 設計・プロトタイピングビジュアルデザイン・プロトペルソナ作成










デザインプロセス

STANDARD でのデザインプロセス

問題提起

シナリオ画面遷移ワイヤー

問題提起

シナリオ画面遷移ワイヤー

問題提起

制作の全体像と構造を把握してUIデザイン

開発側との認識

既にクライアント側で作成しており、提示されることも

成果物：画面遷移図

問題提起

タイムライン

ツイートフォローフォロワー設定ツイート詳細

ユーザーページツイート詳細リプライ Retweet

Twitter の場合

問題提起

フィードバック、エラーの情報が不十分

情報の関係性がわかりにくい

シナリオで定義された流れが見えにくい

画面遷移での課題

解決方法

UI Flows

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の表記1

メールの場合

UI Flowsの表記2




ユーザーがすること①

UI Flowsの表記2





ユーザーがすること②

UI Flowsの表記2



ユーザーが見るものユーザーが見るもの


ユーザーがすること②ユーザーが見るもの

UI Flowsの表記2

メール一覧


返信ボタン

返信

メールの場合

UI Flowsの表記2

メール一覧


返信ボタン

返信

メールの場合

転送

UI Flowsの表記2

メール一覧


返信ボタン

返信

転送

テキストフィールド

転送先選択

メールの場合

UI Flowsの実践

UI F lowsを実際に作成

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 Flowsのメリット

ありがとうございました

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

鈴木健一

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

はじめに

P C とスマホの前提の違いとは？

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


特に画面サイズ


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


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

少ない資源で効率良く機能する UI を設計する必要がある

どうやって設計する？

Q. どう設計するの？


アプリ設計の指針となるガイドラインがあります

・iOS : iOS Human Interface Guidelines・Android : Android Design


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

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

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


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


1. 導入画面

導入画面の例

アプリを起動した直後に表示される画面。アプリの機能の説明などの目的に用いられ、目的によっていくつかの種類が存在する。

スプラッシュウォークスルーコーチマークエンプティステート


スプラッシュ1. 導入画面

・アプリの起動中に表示する画面・アプリが起動動作をしている最中に表示し、待ち時間のストレスを軽減するもの

・ロゴマークなどを表示し、特定のイメージを伝えるもの

・起動中に表示される画面となるため、過度な演出や大量のメッセージを表示させることは避ける


ウォークスルー1. 導入画面

・ユーザーが初めてアプリを起動した場合に、そのアプリがどんなものかを説明するための画面

・アプリで出来ることが多岐に渡る場合に、その機能をビジュアルとテキストで端的に伝える役割を果たす。複数画面にまたがって構成されることも多く、その場合はページインジケーターが下部に表示されている

・使い方が想像出来ているユーザーやまずは使ってみたいと思うユーザーには障害に感じられることもあり、複数画面に渡るウォークスルーを設置する場合にはスキップできる選択肢も検討する必要がある


ウォークスルー1. 導入画面

・ユーザーが初めてアプリを起動した場合に、そのアプリがどんなものかを説明するための画面

・アプリで出来ることが多岐に渡る場合に、その機能をビジュアルとテキストで端的に伝える役割を果たす。複数画面にまたがって構成されることも多く、その場合はページインジケーターが下部に表示されている

・使い方が想像出来ているユーザーやまずは使ってみたいと思うユーザーには障害に感じられることもあり、複数画面に渡るウォークスルーを設置する場合にはスキップできる選択肢も検討する必要がある


コーチマーク1. 導入画面

・画面上の UI がどんな意味や機能を持っているかをオーバーレイ表示で説明するもの

・主要となる機能や初めにするアクション等を提示し、インストールしたばかりのユーザーに行動を促す


エンプティステート1. 導入画面

・表示するコンテンツが何もない場合に表示される画面・なにも表示するものがないということを伝えると同時に、何をすればこの画面上にコンテンツが表示されるようになるかを提示し、アクションを促す役割も兼ねるもの

・類似した画面として、読み込みに失敗した場合の画面等も存在する


2. トップ画面

トップ画面の例

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

ポータル型タイムライン型ストア型


ポータル型2. トップ画面

・コミュニティサイトのような多くの情報を 1 画面で表示することが求められる場合に用いられる画面

・様々な UI コンポーネントを使い、主要な情報の提供と下階層の画面への誘導の役割を担う


タイムライン型2. トップ画面

・ユーザーによる投稿やニュースのような時間軸を持った情報を順序立てて表示する画面

・垂直方向に情報が積み重なって表示されることが多いため、何の軸で表示されているのかが伝わりやすく、スクロールしながら情報が得やすい構成が求められる

・表示された時点での最新の情報を取得するため、一覧をリフレッシュするためのボタンや過去の一覧を取得するための機能が付与されることが多い


ストア型2. トップ画面

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


3. 一覧画面

一覧画面の例

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

検索結果ギャラリーお知らせ


検索結果3. 一覧画面

・ユーザーの検索により表示される画面・垂直型のリストを用いて検索結果を表示する・検索結果の制御（ソート、絞り込み等）をする為に、セグメンテッドコントロールという UI がよく利用される

・検索結果が複数画面にわたる場合はページャーやインフィニットリストページャーが使われる


ギャラリー3. 一覧画面

・写真や動画などのサムネイルを一覧表示する画面・一覧性を高めるために、画面の全面にわたってグリッドリストにして表現される

・コンテンツによっては補足説明をするためのキャプションと一緒に配置される


お知らせ3. 一覧画面

・SNS などで、いいねやコメント等のフレンドからの反応を表示する画面

・誰がどんな事をしたのか、何があったのか、を端的に表現したテキストで一覧表示される

・アクションが多い場合がほとんどのため、垂直型のリストで表現される


4. 詳細画面

詳細画面の例

アプリ内の深い階層にある画面で、コンテンツ単体を表示する画面。多くのアプリにとって、この画面が利用する目的となることが多いため、使い心地について最も注意を払って設計する画面となる。

ビューア記事マッププロダクト


ビューア4. 詳細画面

・写真や動画を表示するための画面・画面の移動のためにスワイプを用いたり、動画の進行状態の表示の為にスライダーを用いる

・この画面の主役はコンテンツそのものであるため、UI 要素がコンテンツ自体の閲覧を妨げないようにすることが重要

・コントローラー等もユーザーが利用しない際は非表示にするなど、コンテンツに没頭できるような配慮もすべき


記事4. 詳細画面

・ニュース、ブログ記事等の文章を表示する画面・テキストと画像のシンプルな構成ですが、スマートフォンでの閲覧を考慮した文字サイズや行間、文字色等の配慮が必要

・記事の長さが長くスクロール量が多くなる傾向にあるため、ページトップへの移動を補助するような機能も検討する


マップ4. 詳細画面

・現在地や目的地の地図を表示する画面・ビューアと同様、コンテンツである地図を画面内に大きく表示させる必要があるため、ナビゲーションやボタンの大きさや配置に配慮することが重要

・複数の地点を表示するようなケースでは、詳細画面に加え一覧画面に求められる機能も考慮した設計が必要


プロダクト4. 詳細画面

・商品情報を表示する画面・この場合のユーザーの目的は商品の購入のため、購入検討に必要な商品写真や価格、概要、購入者からの評判等の必要な情報を掲載する

・商品の説明や仕様などの掲載する情報が多くなるケースでは、垂直型リストを多く用いる画面になる


5. 入力・操作画面

入力・操作画面の例

ユーザーが何らかの動作をするための画面。小さい画面上で文字の入力などの複雑な動きをすることが多くなるため、動作がしやすいか、誤動作を防げるかを考慮した UI を設計することが重要。

サインアップ投稿カメラ撮影設定


サインアップ5. 入力・操作画面

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


投稿5. 入力・操作画面

・ユーザーが何らかの情報を投稿する際に用いられる画面・投稿する対象となるテキストや写真、動画、位置情報などにより表示方法は様々

・投稿するという行動はユーザーがアプリの利用に関わる際のキーとなる行動のため、誤動作を防ぐような配慮が必要


カメラ撮影5. 入力・操作画面

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


設定5. 入力・操作画面

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


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 Basecamphttps://signalvnoise.com/posts/1926-a-shorthand-for-designing-ui-flows

UI のフローをデザインするための簡易記法http://d.hatena.ne.jp/sirocco634/20090921

iOS Human Interface Guidelinehttps://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/

Android Designhttps://developer.android.com/design/index.html

使ってもらえるアプリの考え方http://www.slideshare.net/takayukifukatsu/2012-15750990

スマートフォンのための UI デザインhttp://www.amazon.co.jp/dp/4797372303

inVisionhttp://www.invisionapp.com/

Flintohttps://www.flinto.com/

Protthttps://prottapp.com/