「はじめてのUIデザイン」をまとめる③
フロントエンドエンジニアである私が、個人アプリ「シェア家計簿(仮)」を制作していくなかで、インプットした本や記事の内容をまとめていきます。
はじめてのUIデザインをまとめるシリーズもようやく最後になりました、、（第一弾、第二弾）
第４章から７章までをまとめていきます。
４章 UIが機能する環境を学ぶ
サービスやメディアを作るとなると、まず考えなくてはいけないのはどの媒体で作るかということです。
大きく分けるとWebかスマホアプリか。
さらに、Webの場合もPCとスマートフォンがありますし、スマホアプリの場合は、OSの違いがあります。
【スマホアプリの操作】
まずは、スマホアプリの操作方法についてみていきます。(それぞれの説明は割愛します。)
・タッチ、タップ、ダブルタップ
基本、縦横44px、最低でも30px以上の大きさを確保しておくと吉。
また、「Touch Start」「Touch Move」 「Touch End」に分解できるのでインタラクションを作るにはそれぞれのフェーズの挙動を考えるとよいそうです。
・タッチ＆ホールド（プレス、ロングタップ）
iOSのHome画面で長押しすると編集モードに移行するあれです。
Androidではリストやタイル表示された要素の複数選択に用いられているそうです。
・フリック、スワイプ、スクロール
iOSでは前の画面に戻る操作にエッジスワイプ（画面の端をスワイプ）が使われますが、Androidではドロワーナビゲーションを表示するのに使われるので注意が必要です。
・ピンチ
直感的な拡大縮小ができます。（いつもどっちがどっちか忘れてしまうのですが、）ピンチインは表示の縮小、ピンチアウトは表示の拡大です。
・ドラッグ＆ドロップ
iPadではスプリットビューで分割したアプリ間で使用できます。
・マルチタッチジェスチャー
iPadなどでOSの標準的な操作に割り当てられているため、アプリ専用のジェスチャーとして使うのは避けたほうが良いそうです。
・３Dタッチ、フォースタッチ
iPhone XRではHaptic Touchに置き換わっていて、同じ箇所をタッチし続けると振動によるフィードバックがあります。
・シェイク
キャンセルやUndoなどに使われることがありますが、誤操作やそもそもわかりづらいという懸念点があるので、あくまでショートカットの一つとして考えておくと良いそうです。（私はたまに使います👀）
【iOSとAndroidでの違いと気をつけるポイント】
・バックボタンと戻るための操作
iOSでは左上にバックボタンを配置して戻れるようにするのが普通です。
一方AndroidにはOSレベルの機能として画面の下部にバックボタンが存在します。このボタンは、「戻る」以外にも「キャンセル」や「アプリ間の移動」など、様々な画面で適切な振る舞いを求められるのでそれを考慮して画面設計をする必要があります。
・パーミッションの取り方
位置情報の取得やカメラやマイクの使用、通知の送信などにはユーザーの許可（パーミッション）が必要です。
Androidではアプリをダウンロードした時点で許可を得たことになるNormalパーミッション(通知の送信など)と任意で許可が必要なDangerousパーミッション（位置情報取得やカメラやマイクの使用など）があります。
一方iOSでは、通知の送信も含めて、全てのパーミッションに個別の許可が必要です。
ここで重要なのが、パーミッションを取る際にユーザーにとってなぜその許可が必要なのか、許可をするとユーザーにとってどのように有益なのかを示すことです。(なのでアプリ起動後即パーミッション取得はコンテキストがわかりづらいので基本的にはNG)
パーミッションの取得もアプリ全体の利用体験の一部なので気持ちよく利用してもらえるようなフローを考える必要があります。
Androidではアプリをダウンロードした時点で許可を得たことになるNormalパーミッション(通知の送信など)と任意で許可が必要なDangerousパーミッション（位置情報取得やカメラやマイクの使用など）があります。
一方iOSでは、通知の送信も含めて、全てのパーミッションに個別の許可が必要です。
ここで重要なのが、パーミッションを取る際にユーザーにとってなぜその許可が必要なのか、許可をするとユーザーにとってどのように有益なのかを示すことです。(なのでアプリ起動後即パーミッション取得はコンテキストがわかりづらいので基本的にはNG)
パーミッションの取得もアプリ全体の利用体験の一部なので気持ちよく利用してもらえるようなフローを考える必要があります。
【Webサービスの操作】
Webサービスの場合は、スマホだけでなくPCでの操作を考える必要があります。
特徴的な差異としては、Hover(マウスカーソルを要素に重ねたとき)や、Active(クリック後)の挙動があります。例えば、クリック可能な要素にHoverしたときは要素の見た目を変えてあげることが重要です。
【Webサービスとスマホアプリの導線設計の違い】
スマホアプリでは「トップページから検索して、詳細コンテンツページにたどり着く」というケースが多いですが、Webサービスの場合はGoogleやSNSから直接コンテンツの詳細ページにアクセスするケースが頻繁にあります。
つまり、ユーザーが「求めているコンテンツに素早くたどり着ける」ということが重要です。なので、検索結果に表示されるサムネイルなども何が適切かを検討する必要があります。
5章 UIデザインを作ってみよう
【情報をUIに落とし込む】
いよいよUIデザインを組み立てるプロセスです。
つい、「UIデザイン＝ツールを使ってビジュアルを作ること」と捉えがちですが、「それまで決めてきた情報たちを上手に落とし込む答え合わせのフェーズ」が正しいといえます。
UIデザイナーはコンポーネントを組み合わせてプロダクトの画面を作りますが、その目的を言語化する必要があります。
デジタルのプロダクトは「目的や意図の入れ子」と言えます。
ボタンひとつとっても、色やサイズ、位置、そのボタンで行えるアクションにも目的や意図があり、そのボタンが置かれている画面自体にも目的や意図があり、一連の画面の流れにも目的や意図があります。
実際に情報をUIに落とし込むには
・ドキュメントを理解する
・画面構成を考えながら具現化する
といった手順を踏みます。
第２章で作成した、シナリオやUI Flowsがそのドキュメントにあたります。
自分がドキュメントの作成に携わっていない場合、作成した方と認識を合わせる必要があります。
ドキュメントの理解が進んだら、画面構成を考え、言語化された情報を具現化していきます。
主な具現化の種類としては、
・メモ書き
・ペーパープロトタイプ
・ワイヤーフレーム
があり、上から順に手軽に行えます。
例えば、メモ書きは一人で反復して思考を深めたい場合には向いていますが、人に共有するのには向いていません。
一方、ワイヤーフレームでは実物に近いので実際の構成や遷移について確認できますが、色やアイコンなどの具体的で狭い範囲でのフィードバックが来がちなので、方向性が決まっていない段階で用いると、プロトタイプとしての目的を果たさない場合があるので注意が必要です。（また、時間をかけて作ったデータを作り直すのはつらい😢）
ただ、最近のツールでは簡単に実物に近いプロトタイプを作ることができるので、フィードバックの抽象度に注意さえすれば、メモ書きで試行錯誤してから一気にワイヤーフレームを描くのもありだそうです。
【一貫性を意識してプロダクトの質と作業効率につなげる】
UIを作る上で一貫性が大事と言われますが、それは
・プロダクトのふるまいに統一感をもたらす
・ユーザーの学習コストを減らす
・UIの作成プロセスを効率化する
・開発の複雑度を減らす
といったメリットがあるからです。
「デザイン」と聞くと「オリジナリティあふれる独創的な世界観を作りたい！」となりがち（？）ですが、
・ユーザーの学習コストが増えやすい
・実装コストが増えやすい
・メンテナンスコストが増えやすい
といったデメリットが存在します。
独自性の有無ではなく、そのUIが「ユーザーのためになっているのか」「サービスの目的を達成できるのか」を考えてデザインすることが重要です。
プロダクトの一貫性として、
・コンポーネントの一貫性
・スタイルの一貫性
・スペースの一貫性
が挙げられます。
コンポーネントの一貫性は、例えば、複数の画面で共通のコンポーネント（プライマリボタンなど）を使うことで使いやすさの向上や開発の効率化につながります。
スタイルは主にフォントや色彩のことを指します。
２章を参考にして、指定したフォントや色を使ってみることにします。
スペースは要素間の余白を指します。スペースをどう扱うかでプロダクトの雰囲気はガラッと変わります。
また、「スペースには４の倍数ピクセルだけ用いる」などのルールだけでもある程度の統一感を保つことができます。(例：shopifyのデザインシステム)
ここまでの内容を踏まえて、「シェア家計簿（仮）」の一番コアな体験のみプロトタイプを作成してみました。
↓ペーパープロトタイプ
↓Figmaで作成した画面
大枠はペーパープロトタイプで作ったものと変わりありませんが、年ごと、月ごとの出費合計を表す円グラフを省きました。これは一番コアな機能が、
・出費を記入する
・今月相手に支払う(or相手からもらう）額を確認する
の２つだからです。
そのため、出費を記入するというアクションがすぐに行えるように「＋新規」ボタンは全ての画面にツールバー(iOS: ToolBars Android: BottomAppBar)として配置しています。
また、月の詳細画面ではその月に相手に支払う(or相手からもらう）額を確認するできるように強調しています。
コアな機能とは外れますが、今回アプリ作成するにあたって、既存の家計簿共有アプリの課題として「個人の出費は相手に見られたくない（けど同一アプリ上で管理したい）」というものがありました。
そのため、Segmented Controlesで「共通」と「自分」の出費切り替えを可能にしています。
6章 UIデザインができたら
【体験をデザインする】
このフェーズで今まで「点」だったデザインが「線」で繋がることになります。ここでは大きく分けて２つの作業があります。
・画面遷移にトランジションをつけ、ページの要素やレイアウトの検証を行う。
・ユーザーのアクションに応えるインタラクションを追加する
１つ目の画面遷移をつける作業では、１ページの出来栄えだけを重要視するのではなくて、一連の体験を最適化します。（それぞれのページやモジュール、パーツはこれを達成するための手段です。）
「UIの細部」と「全体の流れ」という粒度の違う面を交互に見ることで全体の完成度を上げていくことが大事です。
また、ページを切り替えるのか、はたまたハーフモーダルで見せるのか、トーストで見せるのかなど、といった部分はこのフェーズで定めるつもりで取り組みます。
２つ目のインタラクションをつける作業は、必ずしも必要なフェーズではありませんが、標準のUIのみで作られたアプリだと退屈な印象を与えかねません。コアな体験にはそのサービスを印象付けるマイクロインタラクションをつけるだけでも印象が大きく変わります。例としてはTwitterのいいね機能があります。最近はツイートによってもいいねをしたときのインタラクションを変えられるようになっていますね。
また、このフェーズでは「実際に他の人に使ってもらう」ことが重要です。
デザインツールのプロトタイプ機能を使えばコアな機能を試してもらうことができます。その一つとして「ウォークスルーテスト」というものがあります。これは、想定している手順を書き出して、その手順のなかできちんと目的を達成できるかをユーザーになりきって試すというものです。実施する際は、さまざまな職種や役職の方にやっていただくと考えていたものとは全く違った課題や、既知の課題でも別の視点でとらえられることがあります。
さらに、このフェーズでは「ユーザビリティ」を考えていく必要があります。具体的には「どのような環境で、どのようなユーザーに、どんなふうに使ってもらいたいか」を考えます。女性誌ひとつ取ってみても、ターゲットによって大きくデザインが異なります。
また、ターゲットユーザーは「今のユーザー」だけとは限りません。つまり、「将来のユーザー」にとってもユーザーファーストでなければいけません。「この機能は使ってくれている人がいるから削れない」という話はよくありますが、それをしていくと細かな機能だらけになり、初めてのユーザーにとっては使いづらいものになってしまいます。
この決断を支えるのがプロトタイピングやそれを使ったテストです。
【開発者と連携する】
「なぜこのUIなのか」というのは意思決定者に向けて説明する際にも必要ですが、実装担当にも共有することが大事です。
例えば、ローディングの「体感速度をあげる」という目的で滑らかなアニメーションを挟んだとします。一方で、そのアニメーションの実装コストが、ある機種だけ異様に高いとします。この場合は、無理に頑張って実装するよりかは、「サービスのtipsを出す」など、目的を達成するための別の手段を検討するという手もあります。
【運用を考える】
継続的にプロダクトを磨き込んでいくためには、デザインデータを「わかりやすく」することは重要ですが、「そのデザインの意図」を伝えることも大切な目的です。
・自分が１年後にみてもデザインの意図が理解できる
・他のデザイナーが新しいデザインを追加できるか
・デザイナーでなくてもパーツの役割や構成が理解できるか
（１つ目、２つ目はエンジニアがコーディングする際にも気を付けたい点ですね。。）
６章の内容を踏まえて、先ほどのプロトタイプに画面遷移をつけてみました。
月ごとの出費までは１ページとして表示し、「新規出費」に関しては「モーダル」で表示させています。これは出費を記入するアクションに集中してもらうためです。（iOSのHIGに以下のような記述があります。）
Presenting content modally can help people focus on a self-contained task or set of closely related options
また、この状態で同居人に協力してもらい「ウォークスルーテスト」を実施しました。手順としてはコア機能の一つである、「今月相手に支払う（相手からもらう）額を確認する」を試してもらいました。
すると、目的の画面までたどり着いたものの、年ごと、月ごとの画面でやや迷いが生じていました。これはリストがただ並んでいるだけだったことが原因だと思われたので、今年あるいは今月の行は強調してみることにしてみました。
さらにいうと、ユーザーの関心はほとんど今月の出費にあるはずなので、アプリを開いた時の画面は、今月の出費であればわざわざ画面遷移させる必要もありませんのでそのように実装しようと思います。
このようにテストを一つ行うだけでもUIだけでなく、どの画面から始めたら良いかまで検討できました😊
「運用を考える」という点では、今回デザインした画面は少ないのですが、リストは共通化できそうだったので共通のコンポーネントとして登録してみました。
左が項目名（年、月、購入内容）で右が金額と画面遷移を表すchevronを配置しました。金額に一番関心がありそうなのでboldで強調しています。
7章 UIデザインをする前の心得
そもそも、何のためにサービスを作るのか？
ユーザーに価値を与えた結果、利益を生み出す製品を作るのがデザイン
前半をすっとばして、利益を生み出すことだけを目的にしてはいけないし、使いやすいだけでも企業のサービスとしてはよくないということでしょうか。
【サービスを作る前の心得】
デザインは、グラフィックを爽快に描くイメージが強いですが、実際はチームとのコミュニケーションをとりながらコンセプトを具現化していきます。
チームによってはデザイナーに期待されている役割が異なります。
例えば、「自分でワイヤーフレームを書いて、細部のグラフィックスをお願いしたい」プランナーもいれば、「実現したいゴールだけをテキストでまとめてUI設計を任せたい」という人もいます。大事なのは先入観で役割を判断するのではなく、認識を合わせておくことです。
役割だけでなく、ビジョンや方向性のすり合わせも重要です。（ほんの少しのかけ違いで設計がずれてしまうそうです。）
【情報収集で判断力を身につける】
よく「センスのある人」という言い方をしますが、そのような人たちもその分野の歴史や知識などの情報を蓄積した経験からベストな判断を導いています。
具体的に、著者の方の例として、中国向けの育児サービスを作る際に、現地の育児知識や文化を吸収するために、中国の都市に実際に赴き、エスノグラフィックリサーチやインタビューの実施や、中国の歴史やスタートアップの生態系の調査まで行ったそうです。
【サービスコンセプトの検証】
新規サービスのデザインは不確実性の高い状態から具現化していく仕事です。
デザイン評価は、（スマホのアプリであれば）パソコンで行うのではなく、実際の環境と同じ状態で評価することが望ましいです。（例：乗り換えアプリであれば電車の乗り換え時に触ってみるなど）
デザイナーがセルフチェックする方法としては以下のものがあります。
・Figmaなどのプロトタイプ機能で画面遷移を繋いで実際の状況下で触ってみる
・プロトタイプを関係者で意見を出しながら触ってみる
・競合サービスのユーザーにヒアリングする
・コンセプトデザインをTwitterに投稿して意見を募ってみる
また、評価の際に意識することとしては
・小さくトライし、小さく失敗し、学ぶ
・リスクに対する失敗コストを最小化する
・仮説に対して効果的な検証方法を考え抜く
・デザインの途中経過をチームにシェアして感覚をすり合わせておく
などが挙げられています。
４つ目は本書の最後にも関連したことが書かれていて、
「デザイナーがデザインを抱え込みすぎず、工程のオープン化を心がける」とあります。
エンジニアやプランナーを巻き込んでUIを組み上げていくコミュニケーションも重要なスキルです。壁にぶつかったら周りを巻き込んでデザインをみんなのものにすることで壁を越えやすくなるかもしれません。
作りながらまとめたのでかなり時間がかかってしまいました、、！（&まとめるの下手すぎて長くなってしまいました。）
ただ、インプット→実際に手を動かしてアウトプットというのは効率が良さそうだと感じたのでこれからも続けてみようと思います🙌