「はじめてのUIデザイン」をまとめる②
フロントエンドエンジニアである私が、個人アプリ「シェア家計簿(仮)」を制作していくなかで、インプットした本や記事の内容をまとめていきます。
前回の記事 で「はじめてのUIデザイン」の２章までまとめました。今回は３章の「UIの見えない部分を学ぶ」を成果物を作りつつまとめていきます。
UIデザインの前に
この章では、アプリのペルソナを作ったあとの情報設計や全体構成について紹介されています。
様々なデザインパターンを参考にして、いきなりUIのラフスケッチを描いてもある程度「らしい」ものはできますが、ユーザーに「分かりやすい」・「使いやすい」・「思いのままに目的を達成できる」と感じさせるためには、用件の定義や構造の設計が必要です。ユーザーがどのような情報を目にして、目的達成のためにどのような行動を取るのかといった「本質」に向き合う必要があります。
情報設計とは
情報設計はプロダクトの骨格を作ります。アプリに明確な価値があったとしても情報設計がきちんとされていないと、画面の繋がりが不明瞭になりユーザーがすぐに迷子になってしまいます。
逆に、適切に情報設計がされていると、ユーザーは「アプリを自分の思いのままに操作している」と感じることができます。また、データ構造が整理されるので、ユーザーにとってだけではなく開発者にとっても利点があります。さらに、アプリ全体がシンプルになることで拡張性にも影響します。
プロダクト全体を「物語」とすると、第２章までが「単語」でしたが、第３章では物語の「骨格」の作り方を学びます。骨格がしっかりしていれば、重要な体験をぶれさせることなく様々な表現を試すことができます。
この章では以下の流れで必要な成果物を作っていきます。
0. ペルソナの設定
1. 行動、操作シナリオの作成
2. コンテンツの分類軸の作成
3. UIモデルの設計
4. レイアウトとインタラクションの設計
0. ペルソナの設定
顔写真、氏名、性別、年齢、人物像、1日の行動イメージ、達成したい目標、現状の課題など。ターゲット層が複数ある場合は複数用意してもOK。
今回私が作るアプリ（シェア家計簿）は、私自身が使いたいものなので、ペルソナは私に似たような人を設定しました。
ちなみにですが、UX Persona TemplateというFigmaのテンプレートを拝借しました🙏
1. 行動、操作シナリオの作成
ユーザーが目的を達成するまでの理想的な状態の仮説(シナリオ)を立てます。つまり、ペルソナが「何ができると目的を達成するのか」といった道のりを具体的にするためにシナリオを作成します。
作成するシナリオは以下の３つに分かれます。
・価値シナリオ：ペルソナがやりたいことと関連するシーン
・行動シナリオ：目的達成までのストーリーとアプリ上のタスク
・操作シナリオ：タスクを実行するための操作
１つ目の「価値シナリオ」は「ユーザーがアプリをどのような文脈で使うのか」の仮説設定につながり、ユーザーの行動をイメージしやすくなります。
上記のペルソナに基づいて自分なりに価値シナリオを作成してみました。
ユーザーがの要求や何を価値と思うかに関して、面倒な記入作業というネガティブ（マイナス）な要素を0に近づけるのか、それともポジティブ(プラス)に転じさせるようになるのが価値なのか、迷いましたが一旦は前者を目指すこととしました。
２つ目の「行動シナリオ」は、上記の「価値と関連のあるシーン」に対してペルソナがどんな行動をすると目的を達成するのかをストーリーとして書きます。また、それに対して発生する必要なタスクを洗い出します。
価値を明確にしていたのでストーリーはすんなりかけたように思えます。
せっかく２人で使うものだから相手とのコミュニケーションのツールとしても使いたいと思い、「相手の記入に対してのコメントやリアクションをつける」といったタスクを追加しました。しかし、価値シナリオから判断すれば、将来あってもいいかもしれませんが必須の対象からは外したほうがいいかもと思っています。
最後の「操作シナリオ」は、実際にアプリ上でどのような操作を行うのかを書き出す一番具象度の高いシナリオです。
アプリ自体わりとシンプルなので、操作シナリオもシンプルに収まった印象です。ただ今見返すと、行動シナリオを若干かぶっている部分もあるので、行動シナリオを具体的に書きすぎたかも🤔
2. コンテンツの分類軸の作成
シナリオの準備ができたので、ユーザーが必要な情報を見つけて理解しやすくするために必要となる要素を抽出していきます。
コンテンツの分類方針では「シナリオを元にする視点」と「コンテンツが持っている属性を元にする視点」がありますが、まずは後者で考えてみました。今回のアプリで扱うコンテンツは「出費」ですので、出費がもつ属性を抽出します。
また、これらの情報をまとめるために、LATCHと呼ばれる基準があります。
・Location: 場所
・Alphabet: A to Z, あいうえお順
・Time: 時間軸、カレンダー
・Category: 種類・性質
・Hierarchy: 連続量・順位（番号）
これに基づいて整理してみました。
ただ、シナリオを元にすると、「場所」という要素はそこまで重要ではないかもしれません。むしろ「内容」みたいにして汎用的な補助要素としたほうがいいかもと思ってきました。
3. UIモデルの設計
ここまででコンテンツと機能を整理しました。ここからは、これらをどのように手順で操作していけば目的を達成するのかを考えていきます。
オブジェクトの抽出
オブジェクトは聴き慣れないとイメージしづらいかもしれませんが、ユーザーが目的を達成するために「何を」「どうするか」の「何を」にあたる部分です。今回の対象となるアプリはシンプルに「出費」だけとしました。
フロー図の作成
ここまで整理してきた「何を」「どうするか」といった項目を先で繋ぎフロー図を作成します。画面遷移とは異なり、各画面にどの要素があるかなどはこの時点では考えません。先ほど、「何を」に当たる部分としてオブジェクトを抽出しましたが、実際にはオブジェクトの属性（プロパティ）も考える必要があります。コンテンツを見つけやすいように分類したカテゴリーなどもです。また、「どうするか」といった「おこなうこと」に当たるものはユーザーが見えているものに対して行うアクションです。
これらの整理に最適とされているのが、UI Flowsです。これはビュー単位でユーザーが見るものと行うことに分解してプロダクトの構造を抽象化し、全体を把握しやすくするための方法です。ここではそれを拡張して、ビューの種類やビュー単位での遷移を考慮したフロー図を作成します。
ビューとはコンテンツの見え方のことで、大きく分けてコレクションビュー(一覧)とシングルビュー(個別詳細)に分けられます。メールアプリを例にすると、受信ボックスはメールのコレクションビューとなり、いずれかを選択するとメールのシングルビュー（詳細画面）にあたります。
題材のアプリの「今月の出費に対して特定の出費を入力するフロー」を図にしてみました。
出費を月毎と日毎でそれぞれコレクションビューとシングルビューをわけてみようとしたのですが、「月のシングルビュー」＝「日のコレクションビュー」では？となり、一緒にしてみました（この考え方が良いかは謎🤔教えて欲しいです🤔）
モーダルとモードレス
ここまで、「オブジェクト」とその「属性（プロパティ）」、またそれらに対する「アクション」をフロー図として整理してきました。次にUIのデザインに入っていく前に「モーダル」と「モードレス」という概念に触れます。
「モーダル」は「モードがある状態」、「モードレス」は逆に「モードがない状態」を意味します。モードとは特定の操作を完了あるいはキャンセルを行うまで他の操作ができない状態を指します。詳細はソシオメディアさんの記事に委ねますが、一般的にモードが多いとそれだけ画面数も多くなり、操作が煩雑になりがちです。また、モードレスデザインの特徴として、「操作する対象（名詞）の選択」→「どのような処理（動詞）」という手順が挙げられます。私たちが使用しているOSでも、多くがこの流れでの操作できるようになっているかと思います。（例：対象のファイルを右クリック→アクションを選択）
デザインをモードレスにすることで、ユーザーに自由を与えるだけでなく、画面数は必要以上に多くならず、アプリ内での作業効率も高められます。
逆に、タスクベースのUIはアプリの都合で決まった方法でしか操作できず、ユーザー自身の創造性を高めることができません。どうしても完了して欲しい操作ではない限りはモードレスなデザインを心がけると良いそうです。
ペーパープロトタイピング
ここまで準備してきたシナリオ、コンテンツの分類軸、フロー図の内容を画面構成に合わせて画面のレイアウトとインタラクションの設計を行なっていきます。
今回、私がプロトタイプで作成した画面は以下の３つです。
・月毎の出費一覧
・日毎の出費一覧（＝特定の月の出費詳細）
・出費の詳細
ペーパープロトタイピングの１番の利点はスピードです。細かいところを気にしないで描くことができます。（自分の場合、Figmaなどを使うとどうしても綺麗に描こうとしてしまいます。。）
実装するわけではないので、考えられるたくさんのパターンを書き出します。今回は一人で作っていますが、実際にはステークホルダーやデザイナー以外のメンバーにも書き込みやすく、ペーパープロトタイプの段階で認識を合わせるのにも適しています。
本文でも紹介されていたPOPというペーパープロトタイピング用のアプリを使用してインタラクションまで作成してみました。（簡単にインタラクションまで再現できてびっくりです😳）
一番迷ったのは、出費追加部分です。
共通を表示している時に追加する場合は、共通の出費として登録。
その中に自分(もしくは相手)への支払いを含む場合は、トグルをオンにして金額や内容を打ち込めるようにしてみました。
これによって、行動ストーリーにある「共通の出費から自分（もしくは相手）の出費だけ差し引く」ということが、計算式を書かずとも可能になります。
これにて、ペーパープロトタイピングまでが一通り終わりましたが、ペーパープロトタイピングの利点はその手軽さにあるので、後日見返してシナリオやユーザーが求める価値と照らし合わせてより良いものがありそうであればそのプロトタイピングも行ってみようと思います。