アプリ | UIデザインプロセス

UIデザインとは？

「情報たち」とは？

おもに以下のプロセスから整理される情報たちのこと

1. 現状理解

2. 目的の確認

3. ドキュメントの理解

1. 現状理解

以下のような質問を通して、現状の理解を深めていく

チームメンバーにはだれがいるのか / それぞれ何を担当しているのか

何をするために今のチームは存在するのか

直近のチームの目標はなにか / それはいつまでか

サービスコンセプトややらないことなど、意思決定に必要な情報は揃っているか

決裁フローはどうなっているか

UI Flowsやシナリオなど、設計の指針となるドキュメントは揃っているか

ロゴかカラーガイドなど、スタイルに必要な要素は揃っているか

※ システム要件や開発難易度についても、ビジネスサイドや開発チームに事前に確認しておくとよい

デザイナーの独断でUIをつくってしまうと、実装の直前にNGが出ることさえある

ビジネスサイドとの要件のすり合わせや、開発チームとのコミュニケーションは意識的に行う

2. 目的の確認

UIをつくる目的を言語化する　 ※ 他の人が用意している可能性もあるが、どちらにしても目的の理解は必須

ボタンなどのコンポーネント一つとっても、色やサイズ、位置などに目的や意図がある

そのボタンで行えるアクションにも目的や意図があり

ボタンが置かれている画面にも目的や意図があり

一連の画面の流れにも目的や意図がある

コンポーネントの存在意義を繰り返し問うと、最終的にはそのサービスの目的にまでたどり着く

code: コンポーネントの存在意義からサービスの目的をたどる

スタイル（見た目）の目的

⬇

コンポーネントの目的

⬇

アクション（機能）の目的

⬇

レイアウトの目的

⬇

ナビゲーションの目的

⬇

プロダクトの目的

⬇

サービスの目的

目的を見定めれば、UIデザインにかんして、やるべきことがみえてくる

UIデザインは、あくまでサービスの目的を達成するための一手段であり

サービスの成功のためには、あえてUIをデザイン「しない」という選択肢さえあり得る

アウトプット（成果物 / 制作物）よりもアウトカム（成果 / 目的）に目を向ける

3. ドキュメントの理解

UI Flowsやシナリオなど、プロダクトの骨格となるドキュメントを理解する　※ UIの制作者と構造設計担当が異なる場合

開発初期はこうした「どのようなプロダクトを目指すべきか」を示した青写真をもとにUI設計をすすめていく

ドキュメントの理解を深めていくために、以下のようなプロセスで確認していくとよい

A. つくった人や全体像を理解しているひとがいれば、一緒に内容を確認する

特に、ドキュメント量が膨大で、読み込むのに時間がかかるようなケースで効果的

B. 事前にドキュメントを共有してもらった上で読み込み、疑問点をリストアップして確認する

自分が理解している点とそうでない点を把握できる

理解しているとおもった点の認識のすり合わせをスムーズに行える

デザインガイドライン / デザインシステムなど、プロダクトのデザインに関するドキュメントを理解する

これらはプロダクトの運用年数がある程度経っている場合に存在することが多い　※ 勿論ないケースもある

code: cf.デザインガイドライン / デザインシステムとは？

デザインガイドライン ：カラーやタイポグラフィのルール、各コンポーネントの役割や状態一覧などに関するドキュメント

デザインシステム ：UIデザインで活用できるツールやUIコンポーネント、デザイントークンなどが一体となったもの

こうしたデザインドキュメントで定義されたスタイルやルールを無視して、UIデザイナーが好き勝手にUIをつくってしまうと、プロダクトの一貫性が損なわれていく

結果として、ユーザーに混乱を招いたり / 開発の非効率化につながる

そのため、デザインガイドラインやデザインシステムがあるプロダクトの場合は、必ずはじめに目を通しておく

デザインドキュメントが存在しないプロダクトの場合は、既存の画面からデザインルールやパターンを読み解く

コンポーネントのスタイルやレイアウトのルールなどは、主要な画面を確認することでパターンが見えてくる

※ ただし、運用期間が長かったり、人の入れ替わりが激しいチームでは、パターンが複雑化していたり、一貫したルールがない場合もある

画面構成を考えながら具体化する

「情報たち」に対する理解がすすんだら、UI Flowsやシナリオをもとに、言語化された情報をUIに具体化していく

ただ、UI Flowsやシナリオだけを見てUIをつくろとしても、目的に沿ったレイアウトにたどりつくのは難しい

プロダクトのコンセプトと構造設計をかけ合わせて、UIを具体化するコツ

1. コンセプトとシナリオからコア機能を抽出する

コア機能とは、そのプロダクトが提供するメイン機能、ユーザーがそのプロダクトで一番やりたいこと

プロダクトの課題およびその解決策は、シナリオに記述されていることが多いため、シナリオやプロダクトのコンセプトからコア機能を抽出していく

2. 要素の情報量と重要度を検討する

ユーザーの目的が達成できることを念頭に、シナリオを参照しながら、画面内の構成要素の量と重要度について考える

たとえば、以下のような観点から、情報量と重要度を整理してみる

配置する要素によって、どのようなアクションを誘発できるのか

そのアクションは、画面内においてどのアクションよりも重要で、どのアクションより重要でないか

画面内の情報量が多くなったり、同じ見た目（つまり、同じ重要度）でメリハリがなくなってしまった場合には

ユーザーの目的に立ち返って、重要度の高低と要素の要否について改めて検討してみる

UI Flowsやシナリオで描かれているプロダクト全体の利用文脈について振り返ってみる

UI Flowsやシナリオに沿って情報量や重要度を設定することで

画面に表示する要素を減らすことができ、シンプルでわかりやすいUIになる

テキストやコンポーネントのサイズ、カラーを最適化でき、ユーザーの目的に寄り添ったUIになる

3. オブジェクトとアクションを意識する

オブジェクトとアクションをベースにUIを組み立てることで、タスクベースのUIになりにくくなる

UIをつくってみたら、以下の視点でタスクベースのUIになっていないかを俯瞰して確認してみる

1. 手順を踏まないとすすめない画面遷移になっていないか

2. 選択肢を選ばないとすすめない画面遷移になっていないか

UI Flowsやシナリオに忠実すぎると、画面内が「○○する」ボタンの羅列になりがちなため

アクションの多い画面では、オブジェクトに役割をもたせてみる

重要度を加味して、通常のボタンではなく、アイコンボタンの採用を検討してみる

具体化の手段

具体化の手段としては、主に以下の3つがあり、手段ごとに必要とされる場面と得られる結果が異なる

目的に応じて、最適な手段を選択できるとよい

A. メモ書き

目的 ：自分ひとりで試行錯誤や検討を繰り返すとき

精度 ：自分が理解できればいいので、具現化された情報はかなりラフ

特徴 ：第三者と共有はしづらいが、すばやい反復作業で自分が考えたいことだけに集中できる

B. ペーパープロトタイプ

目的 ：第三者とUIの構成や遷移について確認したいとき

精度 ：手書きでカバーできる範囲で、ユーザビリティテストなどに使うときはテキストやアイコンも描き込む

特徴 ：実際の端末サイズに描き込むため、使いやすさやコンポーネントのサイズ感の検証にも利用可能、アナログ作業のためデザイナー以外のメンバーを巻き込みやすい

C. ワイヤーフレーム

目的 ：第三者とUIの構成や遷移について確認したいとき

精度 ：スタイルは省くが、レイアウトをおこない、コンテンツも流し込む

特徴 ：主目的はペーパープロトタイプと同じ、デザインツールを用いてつくるため、より実物のサイズ感に近い確認が可能

code: cf. UIの忠実度とアウトプット例

低忠実度のUI： メモ書き、ペーパープロトタイプ

中忠実度のUI： ワイヤーフレーム、インタラクティブプロトタイプ

高忠実度のUI： モックアップ（デザインカンプ）、ビジュアルプロトタイプ

低忠実度のUIほど、すばやく具体化でき、全体の構成や画面の流れなど、抽象度の高いフィードバックが得られやすい

高忠実度のUIでは、色やアイコンなど見た目に目が行きやすいため、具体的で、狭い範囲のフィードバックが多くなる

初期フェーズにおいて、本来議論すべきポイントからは外れがち

時間をかけてつくったUIは、つくりなおす精神的負担が大きいため、最初から高忠実のUIをつくるのは避けるほうが無難

一方で、ペーパープロトタイプ / ワイヤーフレームを見慣れていないメンバーは、実物に近いUIのほうが理解しやすい

画面数によっては最初から高忠実度のUIをつくるほうが効率的にすすめられる場合もある

この場合、フィードバックの抽象度に気をつけつつ、一気に高忠実度のUIをつくってもよい

※ 具体化のフェーズでは、コンポーネントの役割 / 関係性やレイアウトへの理解が低いと、UIに落とし込む難易度が高くなる

そのため、以下のような取り組みを通じて、基礎を固めたり、引き出しを増やしていくことを推奨する

A. コンポーネントやレイアウトの基礎を理解する

一般的なUIコンポーネントの種類と役割を知る

iOS / Android / Web 各プラットフォームのガイドラインや、インタラクション / ナビゲーションのルールを知る

B. コンポーネントやレイアウトパターンの引き出しを増やす

UIトレースをおこなう

画面構成と具体化は同時並行で考え、それぞれの工程を反復しながら詳細をつめていく

具体と抽象の間を行き来して、アウトカムとアウトプットとの整合性を担保しながらすすめていく