【24日目】「はじめてのUIデザイン 改訂版」備忘録 3-7
完全に見よう見まねでやっとペーパープロトタイプの作成まで辿り着きました〜（本の内容のトレースですが）
※この記事は「はじめてのUIデザイン 改訂版」を参考にまとめたもので、イラスト等も全て同書を参考に作成しています。
あくまで自分用の備忘録なので十分でないところもあるかもしれませんが悪しからず。。
3-7.プロトタイピング
プロトタイプは議論を活性化させ、プロジェクトの成果をより良いものにする役割がある。完成形を作るのではなく素早くアウトプットし、良い議論を生み、フィードバックを得ることが目的。
デザイナーには得られたフィードバックを元に修正を繰り返し精度を高めていくスピードが求められる。
→素早さを目的にするのではなくある程度の方向づけを行なった上でスピードを意識する
ファシリテーションスキル（物事がスムーズに進んでいくよう調整する能力）が伴うとより良い。
プロトタイピングの順序
1. プロトタイプの方向づけ
2. プロトタイプの具現化
3. プロトタイプの検証・議論
これらの繰り返し。
必要に応じてシナリオや、フローを見直しを行う。
目的はアイデアを具現化して議論すること。（成果物の出来にこだわりすぎることではない）
1.プロトタイプの方向づけ
プロトタイピングを行うにあたってどういった議論を行うかを方向づける
・どんなユーザーのどんな課題に向けたものなのか
・ユーザーがどのような目的を達成するためのプロトタイプなのか
（例：ペルソナがその日の気分に合わせて曲を探し再生する曲を選ぶまでの流れがプロトタイプの方向性。
→「聞きたい曲の曲名がわからない」への解決方法は提供できているか
→そもそもそういった課題を解決するべきなのか、など。）
・議論を交わす相手を決めておく（フォーカスしても仕方ないことを気にせず面白がって、目的や意図を把握し、同じ目的で別視点からのフィードバックをくれる人に参加してもらうと良い議論に発展して良い。）
2.プロトタイプの具現化
意思決定の議論に必要な部分のプロトタイプを作成する。
今回はユーザーがマイライブラリから曲を探すフローのUIモデルからペーパープロトタイプを作成。
3-6までのフローで決定した5つの画面に、検索画面、検索結果画面、マイライブラリ画面を追加して、計8画面で構成されたプロトタイプを作成する。
以下↓、画面とそれぞれの画面の構成。
マイライブラリ画面
・アーティスト一覧
・アルバム一覧
・曲一覧
・最近再生した曲一覧
アーティストリスト画面
・アーティスト一覧
アルバムリスト画面
・アルバム一覧
検索画面
・検索ツール
・最近検索した曲リスト
検索結果画面
・検索ツール
・検索候補一覧（入力中）
・検索結果一覧
アーティストの個別画面
・アーティストの個別詳細
・アーティストの曲の一覧
・アーティストのアルバム一覧
アルバム個別画面
・アルバム個別詳細
・アルバムに含まれる曲一覧
プレーヤー個別画面
・曲個別詳細
・曲の再生、停止、戻し、送り、お気に入り登録ツール
ここからより詳細な情報をUIに落とし込んでいきます。
ナビゲーションの設計
プロトタイピングを進めるにあたって、アプリをどのような構造にして、全体をどのようなナビゲーションスタイルにするのかを選択します。
スマホの場合、OSごとにナビゲーション構造に関するガイドラインが設けられており使用するナビゲーションが示されている。
iOs → iOS Human Interface Guidelines / Navigation bars
Android → Material Design / Understanding navigation
1つのプロトタイプで複数のナビゲーションを試してみる。
・ユーザーが目的地に到着するまで、できるだけ意思決定したと感じさせないようにするにはどうすればいいか
・分類軸を見直す必要も出てくる
・コンテンツを探す方法やコンテンツをどういう属性で探したいのか改めて考える
・ナビゲーションはユーザーに現在地をわかりやすく伝えるとともに、どちらにいけばあとどれくらいで目的に地に到着するのかを示す道標でもある
・できるだけ遷移を少なく設計できるとユーザーは目的地までの道筋を把握しやすくなる
題材の音楽アプリではユーザーはまず
・聞きたいと思っている曲を検索する
・ライブラリの各分類から探す
↓
こうした場合メニューに登場するのは
・ホーム
・検索
・マイライブラリ
ナビゲーションの構造はフラット、横方向ナビゲーション
マイライブラリでコンテンツを絞り込んでいく部分は階層型・順方向ナビ
グローバルナビ：iOSはタブバー、Material Designはボトムナビ
ドロワーコンポーネントを採用する前に
ドロワーはコンテンツの特性上、どうしても画面を広く使いたい場合の最後の手段で使用する。（採用するときは少し考える）
ドロワーは現在地の確認や目的の場所に移動できるかの確認したい場合もメニューを展開する必要があるので期待される道標としての機能をしっかり果たしているとは言えない
アプリ上でユーザーが何かしようとするたびにタップ→ドロワーを展開→目的の項目を探して選択する操作が必要になるため、操作が複雑になりユーザーは前に作業していた破面に戻る場合など移動方法を想像しにくくなる。
パーパープロトタイピングを行う時点で、タブバーやボトムナビに収まらない数の項目が候補に上がっている場合は、アプリの目的や情報の分類軸など石器を見直す必要がある。
ペーパープロトタイプ
上記のプロトタイプの具現化、でまとめた項目をもとにペーパープロトタイプを作成します。（全部で8画面）
ペーパープロトタイプを採用する理由
・ツールを利用すると線の太さや色、フォントサイズ、余白などの細かい部分の調整に時間がかかってしまうため、そう言ったことを気にせず考えられるパターンをたくさん書き出すのに向いているから。
UIデザインの答えは一つではないため、何度も修正できるため精度を高めていくことができる。
実際の端末画面サイズで作成すると良い。
スマホの枠が描かれたタイプのものや長方形の付箋等を利用すると良い。
（手元でめくりながら操作できるので画面の遷移をイメージしやすい）
インタラクション（相互作用）の設計
レイアウト設計と合わせてインタラクションの設計を行う。
ユーザーのアクションに対してアプリはどのような反応を返すのか、UI Flowで整理した画面の遷移をどのように行うかを設計する。
コンテンツの見え方や操作方法を意識する。
プロトタイプの検証・議論
ペーパープロトタイプが出来上がったら、画面遷移図のように並べてみるなどして画面の展開を確認する。
開発メンバー、ステークホルダー、ペルソナに近い人物に試してもらいフィードバックからさらに精度を高めていく。
今日はここまで。
この記事が気に入ったらサポートをしてみませんか？