見出し画像

【10日目】【11日目】「はじめてのUIデザイン 改訂版」備忘録 3-5〜6

maya_design

具体的な作業工程だから後で実際に作業するときに参考にすると良い部分です。
ただものすごくロジカルな説明を文字で読むと逆に分かりづらいな、と思う部分もある気がしています。。
著者と自分の間で共通言語の認識にズレが生じると結構意味がわからなります。。（チームで仕事をするときの共通言語の大切さがちょっとわかった）

※この記事は個人の勉強の備忘録として「はじめてのUIデザイン 改訂版」を参考にまとめたもので、イラスト等も全て同書を参考に作成しています。

3-5. 必要な要素を整理する

ユーザーシナリオができたら、そこからコンテンツの分類に必要な要素を抽出。
主に「コンテンツの持つ属性」と「シナリオ」からの視点を組み合わせて抽出し、分類方法を決めていく。
→ここでの分類はナビゲーションや検索軸などユーザーがアプリ上で目にするものにつながっていく。

  • コンテンツの持つ属性を元に抽出（ここでは「曲」）
    曲名、アーティスト名、アルバム名、アルバムアーティスト名、作曲者名、曲番、曲の時間、発売年月日、ジャンル、アートワーク、BPM、再生時間、歌詞

  • シナリオを元に抽出
    シナリオからユーザーの普段の行動や人物像から導き出す方法。
    ペルソナが聞きたい曲を探すとき、どのような情報を利用しているのかを想像して書き出す。
    曲名、アーティスト名、アルバム名、歌詞に使われたフレーズ、使われていたシーンなどの特徴。

上記で抽出したものからユーザーがコンテンツを探すきっかけとなるものを検討する。（ユーザーに伝わるよう普段から親しみのある分類を選択するのが良い）
「LATCH 5つの情報整理方法」を参考にすると良い。
Location（場所）：
Alphabet（アルファベティカル）：A to Z 、あいうえお順（辞書、連絡帳など）
Time（時間）：時間軸、カレンダー、年表（ニュースフィード、メールの受信箱など）
Category（カテゴリ）：種類、性質による区分（音楽ジャンルなど）
Hierarcht（階層）：再生回数、順位（番号順、日付順、重さ順など）

分類軸を定める

このアプリでユーザーは聴きたい曲をどうやって探すか、ペルソナとシナリオに沿って予測する。
・曲名、アーティスト名、アルバム名で検索→○しそう
・作曲者名、BPMで検索→×しなさそう
・行動シナリオ、操作シナリオからマイライブラリ、お気に入り、登録したアーティスト名、アルバム名を切り口に探しそう。
（つまりユーザーが曲を探す時初めにしそうなことは下記2つに分類される。1番目の階層。表層。）
↓
●マイライブラリから探す：
登録した曲、登録した曲が含まれるアルバム、登録した曲のアーティスト
●検索して探す：
曲名、アーティスト名、アルバム名、歌詞のフレーズ、曲の特徴（使われていた映画など）、音声入力（鼻歌など）

つまりここでの分類軸は マイライブラリから探す 検索して探す の2つ。

このようにユーザーがどのようにコンテンツを探していくのかを、シナリオ、コンテンツの持つ属性を検討し分類軸を考えていく。
ここで分類軸が定まったので、さらに掘り下げて、アーティスト一覧、アルバム一覧、検索結果の表示順なども分類軸に合わせて反映していく。
（例：「誰のなんというアルバム」と思い出すならアルバム一覧もアーティスト名順（A to Z）に並べるなど普段の思い出し方で探せるようにする。ユーザーが目的に辿り着くために2番目に行う動作）

マイライブラリから探す 検索して探す の2つの分類軸をさらに掘り下げていく。（1階層目の動作の次に操作する2階層目にあたる分類軸を定める）

●マイライブラリ：
-アーティスト：A to Z
-アルバム：アーティスト名のA to Z
-曲名：追加順
●検索結果：
-同じキーワードで選択されている結果：順位
-曲：人気順
-アルバム：人気順
-アーティスト：人気順

※ユーザーが目的の曲に辿り着くまでに行う動作と操作2階層目にあたるの階層目の分類軸

上記のプロセスで情報の構造パターンを抽出し、コンテンツの分類軸を決めていく。一度で決めていくよりメンバーと共有したりペルソナに近いユーザーと検証してみる。

カードソーティングゲーム：情報の構造化をユーザーの思考の理解を深めながら調べるのに適した手法。←調べてみたけどいまいちわからなかった・・・

3-6. UIモデルを設計する

ここまでの過程でコンテンツと機能を整理してきたので、今度はユーザーがその整理されたコンテンツと機能をどのように操作していけば目的を達成できるかを考えていく。

オブジェクトの抽出

オブジェクトは操作シナリオの「何をどうするのか」の「何を」で表されている名詞で表せるもの。
「どうするのか」はオブジェクトに対してユーザーが行う動作。動詞。

・検索フォームに聞きたい曲名を入力して検索する
・検索フォームに聞きたい曲が含まれるアルバム名を入力して検索する
・検索フォームに聞きたい曲のアーティスト名を入力して検索する
・検索フォームに聞きたい曲の歌詞のフレーズを入力して検索する
・検索フォームに聞きたい曲が使われていた映画の名前を入力して検索する
・検索フォームに聞きたい曲の鼻歌を音声入力して検索する

→以上からこのアプリのオブジェクトは「曲」「アルバム」「アーティスト」の3つ。
オブジェクトの特定が難しい場合は、ユーザーが強い関心を持って一覧を作成しやすい要素を探してみる。オブジェクトと捉えて良いのか、オブジェクトが持つ属性の一つなのかも精査していく。

フロー図の作成

まずは「何を」「どうすればいいのか」というレベルでの整理を行い、それらを繋いでみる。

「ユーザーが見たものに対してどうするのか」をフロー図で整理する。

（※ここで想像しがちな画面遷移図はある程度UIデザインが進んだ状態で全体像を可視化して把握するために利用するもの。）
A shorthand for designing UI flows 参照

・シングルビューとコレクションビュー
コンテンツの見え方は大まかにシングルビューとコレクションビューに分類される。
・シングルビュー：1つの画面の中にアプリで扱うオブジェクトを一つ表示する。いわゆる詳細表示。例：ブログ記事、メディアプレーヤー、メールの詳細
・コレクションビュー：1つの画面の中にアプリで扱うオブジェクトを複数並べてリスト状に表示する。例：音楽アルバムのリスト、収録曲のリスト、検索一覧

※地図上に表示されたピン→コレクションビュー（リストに切り替えられるから）コンテンツの見え方は大まかにシングルビューとコレクションビューに分類されるが、ユーザーが操作する状態を表すものもある。
→対話式の操作・入力操作（設定画面など）、編集などのツール提供（写真の編集など）

UIのモデリング

先ほど整理したフロー図をさらに拡張していく。
抽出したオブジェクトとどのビューが関係するかを意識するのがポイント。
画面や見た目と切り離してオブジェクトを具現化し、ユーザーが扱えるよ形にする。

↓こちら、書籍内の図と全く同じものを書いてみた
マイライブラリから曲を探すフローの図。

マイライブラリから曲を探すフロー
Ikeda Takuji,Uno Yu,Kaminogoya Taichi,Tsubota Tomo,Motoyama Kazuyuki,Yoshitake Ryo. Hajimete no UI design kaiteiban (Japanese Edition) (p.221). Kindle 版.
追記：記載のチャート図が個人的にわかりにくかったので作り直した。。

注：粒度（構成単位の粗さ）をコントロールないと必要以上に時間がかかる。
（ユーザーが見るもの：名詞、行うアクション：動詞で表せるものを設定）

粒度の設定

モーダル、モードレス

オブジェクトとアクションはUIを構成する基本となる要素。
・名詞にできるもの＝オブジェクト
・動詞にできるもの＝アクション

UIには大きく分けてモーダル、モードレス、という状態がある。
・モーダル＝「モードがある」状態
・モードレス＝「モードがない」状態
モードとはユーザーが特定のモードに入り、そのモード内での操作を完了、またはキャンセルするまで他の操作ができない状態のこと。
例：入力したデータを削除するときに「本当に削除しますか？」などのアラートメッセージ。ATMの操作など。

【モーダルの特徴】
・モーダルはユーザーの操作を限定して決まった操作に集中して行う支援をするもの
・支援にもなり得るが、ユーザーの行動や操作を限定するものでもある（ATMの操作など）
・何をするかを先に選んでから何を操作する対象を選ぶ
・行う操作ごとの画面を用意する必要があるので画面数が多くなる
・アプリ内のモードを減らすように意識すると「何をするか」ではなく「操作する対象を意識しながら目的を達成できるので使いやすさにつながる
・モードが必要な場合は、どう言ったモードであるかをわかりやすく表示する、いつでもモードから出られるようにしておくと良い。

【モードレスの特徴】
・ユーザーは普段と同じようにそれぞれの手順で目的達成に向けて操作を実行できていると感じる
・操作する対象を先に選んでから何をするか決めるので画面が少なくなる
（何をするかが先か、操作する対象が先かで画面数が大きく異なる）

GUI（Graphical User Interface）の基本的な考え方はモードレス。
PCのOSも操作する対象を選んでから何をするか決める、という流れで操作するようになっている。

例：Mac OS
①書類フォルダ内の
②Adobeフォルダに
③どのような操作を行うか

モードレスなデザインは操作の柔軟性が提供できる。
操作対象を選んで操作方法を決めるので画面数が必要以上に多くならず、アプリ内での作業効率も高められる。

モーダルなタスクベースのUIは、ユーザーが決まった方法でしか操作できず創造性が高めにくい。モーダルであることがいけないというわけではないが、デザイナーは基本的にモードレスなオブジェクトベースのUIデザインを心がけながら、特定の操作に焦点を絞った方がいい場合にはモーダルなタスクベースのUIデザインを検討するのが良い。


画面の構成

UIフロー図で整理したコンテンツの見え方（ビューごとに整理された情報補まとまり）をアプリを提供する環境に合わせて画面を区切っていく。

PC → 大きな画面を利用できるので複数のビューを組み合わせて配置できる
スマホ → 画面が小さいのでビューごとに画面を遷移させる必要がある

例）メールアプリの場合
MacOS：メールボックス、メールリスト、メール詳細が一つの画面
iPad：左側のカラムがメールボックスと受信したメールリストで切り替わる
iPhone：メールボックス、メールリスト、メール詳細それぞれが別画面

題材の音楽アプリのUIフローに画面構成を加えた図↓

題材の音楽アプリの画面構成の例。
マイライブラリから曲を探すフロー。
追記：記載のチャート図が個人的にわかりにくかったので作り直したものその2。。

アーティストのシングルビューとアーティストの曲のコレクションビューはまとめて一つの画面にできそう。
アルバムのシングルビューとアルバム曲のコレクションビューはまとめて一つの画面にできそう。

以上、題材のアプリの上記のフローは
・アーティストリスト画面
・アーティスト個別画面
・アルバムリスト画面
・アルバム個別画面
・プレーヤー個別画面
の5つの画面で構成される。


ちっとイマイチ理解していなくてついていけていないところがあるのだけど、、
とりあえずまとめてみました・・・

#Daily_UI #005 App Icon
牛乳配達サービスのアイコン。

牛さんを描いたよ。
アイコンっぽくしたくてグラデをかけたよ。

あと89日🐊

↓「はじめてのUIデザイン 改訂版」読んだよシリーズはこちら。


この記事が気に入ったらサポートをしてみませんか？