UIデザインを作る時は、最初からデザインツールを開かない
フリーランスでプロダクトデザイン・フロントエンド開発をしている北國でです。
最近、4ヶ月ぶりに筋トレを再開しました。4ヶ月サボるとベンチプレスは80kg → 60kgに落ち、懸垂は1回もできなくなっていてとても悲しかったです。徐々に記録を戻していこうと思います。
筋トレ再開を機に、途中で止まっていた筋トレログアプリの個人開発も再スタートしました。年末年始に頑張って開発を進めたいところです。
さて、この記事では、普段私がWebサービスやモバイルアプリのUIデザインをする際、具体的にどのような流れで作業を進めているかをまとめてみました。
Motivation
自分のUIデザインのアウトプットの質を上げるために振り返りも兼ねて。
一緒に働くデザイナーさんから質問をいただくことが増えてきたので。
前提条件
この記事では、PMから要件またはワイヤーをもらっている状態を想定しています。
部分的にはUXデザインの領域も入っています。UIデザイン・UXデザインの定義の境目は人やチームによって様々です。いずれにせよ、UIデザインのアウトプットをより良くし、ユーザーに届く価値を向上させることを目的にしています。
では、本題に入ります。
UIデザインの流れ
なにはともあれ、まずはUIデザインを作る流れを紹介します。少し長いですが、前半が特に重要な点だと思っています。
機能開発のロードマップを把握し、手戻りが少なくスムーズに体験設計がつながるように意識する
要件を把握する
必要に応じて、要件についてPMと話しながら修正・改善する
この機能によるユーザーのゴールを定める
ゴール達成のためのUXの"おおまかな"ステップを書き出す
各ステップごとのUX(UI)のアイデアをテキストですべて書き出す。まだUIは作らない。
UXリサーチで得たファクト・インサイトとアイデアを照らし合わせる
書き出したアイデアに対して懸念点がないか、また別のアイデアがないかをセルフレビューする
既存UI・開発ロードマップ・今回の機能の3つの観点から、どのアイデアがベストか着地させる(場合によってはプロダクトビジョンに基づく我々が目指すべき所にアラインしているかも確認する)
影響範囲を洗い出す。今回の追加機能によって整合性が崩れる箇所がないかを確認する。必要であれば別画面の修正箇所も整理する。まだUIは作らない。
UIアイデアを何パターンか作る
一晩寝かせる
翌日セルフレビューし、どのパターンが最も良いか目星をつける
チームに推しデザインと理由を添え、複数案提案する
こうやった流れを書き出すと項目が多くて自分でもうげぇ…と感じますが、実務でやっている感覚ではそこまでたいそう大袈裟な感じではなのでご安心ください。
タイトルにもある通り、この流れの中で実際にFigma等のデザインツールを開いてUIを作るのは後半の方になります。
UIデザインのアウトプットの質を高めるためには、UIを実際に作るまでのステップが大事だと思っていて、そのステップの中から特に意識している箇所をピックアップして紹介します。
1.機能開発のロードマップを把握し、手戻りが少なくスムーズに体験設計がつながるように意識する
これは、いま目の前にあるチケット(要件・機能)だけを見ず、このあとに積まれているチケットを想定することを指しています。
大体の場合、プロダクトの改善のためにやりたいことが山積されていて、向こう1ヶ月程度であれば開発のロードマップがぼんやり見えていると思います。
UIデザインに取り組む際、そのロードマップ(全体像)を把握することで、局所的な対応になってしまうことを避けることができます。
例えば、デザインタスクA,B,Cの3つが今月〜来月にかけてある場合、BとCの要件をざっくりとでも理解していると、今回取り組むAのデザインがBとCにスムーズに繋がるように意識することができます。
もしBとCを意識できていない場合、Bに取り掛かった時にAと干渉してしまい、Aの部分も微修正が必要になったりします。これはデザイナー自身だけではなく、エンジニアの工数にも影響してくるのでとても重要です。
少し話が抽象的なので例を上げると、今月のデザインタスクAでは、グローバルナビゲーションに1つボタンを追加する必要がありそうだとします。現状のグロナビのスペースは余裕があるので、そのままボタンを配置して良さそうです。
ただ、次のタスクBとCで新しいページが追加されるため、グロナビに新たに2つボタンが追加されることが想定されることがわかりました。つまり、合計3つのボタンが配置されるので、それらをグロナビにそのまま置くことは難しそうです。
このような先読みができたので、今回のデザインタスクAの時点から複数のボタンを配置できるドロップダウンメニューを採用し、拡張性を持たせたUIデザインを作成する、といった判断が可能です(把握した上であえて拡張性を持ったUIはタスクBの時にやるという判断もありです)。
今回の例は小さな影響範囲での話ですが、影響範囲がこれよりもっと大きい場合も多々あるため、できる限り見えているロードマップは頭に入れておく、というのがUIデザインをする時の最初のステップにしています。
4.この機能によるユーザーのゴールを定める
チケットには要件やワイヤーが書かれていますが、この要件を満たす機能をリリースした時に、ユーザーにはどんなことを達成してほしいのかを改めて整理します。
丁寧なチケットの場合、この機能開発がなぜ必要になったかWhyの部分が書かれていると思います。そのWhyを把握し、ユーザーのゴールを定義しておくことで、UIデザインをした時に立ち返る場所を作っておきます。
実際に手を動かしてUIデザインをしていくと、デザイナーあるあるだと思いますが、細かな部分に目が言ってしまって、本来の目的・ゴールが意識から遠のくことがあります。
画面遷移はどうしよう、どんな状態パターンがあるだろう、配置はどうしよう、色はどうしよう、フォントサイズはどうしよう、スペースはどうしよう…と作業に没頭していった時に、「あれ、これってユーザーのゴールを達成できてるんだっけ？」と深呼吸し直し、冷静に立ち返る場所を作っています。
5.ゴール達成のためのUXの"おおまかな"ステップを書き出す
この段階ではまだUIは作成しません。上述の通り、UIを作り始めると細かい所に意識が向いてしまいます。なので、前段でゴール達成のためのユーザー体験のステップを書き出します。
ここはざっくり大まかでOKです。ユーザーがどんな手順を踏んでゴールにたどり着けるのかをざっくりと整理します。
6.各ステップごとのUX(UI)のアイデアをテキストですべて書き出す。まだUIは作らない。
手順を書き出せたら、それぞれの手順をユーザーが達成できるためにはどんなUIや操作・体験が必要なのかを「テキストで」書き出します。思いつくアイデアをできるだけ書き出します。
まだビジュアルとしてのUIは作成しません。理由は上述のとおりです。
例えば、とあるSaaSのリストUIがある画面において「データを非表示にできるようにしたい」という要件があったとします。
データを非表示にするステップにおいて、色々なアイデアが浮かびます。例えば…
シンプルにデータごとに非表示ボタンを表示する
3点リーダーアイコンを置いて、それを押したらメニューが表示されて非表示アクションが押せる
マウスをホバーしたら非表示ボタンが出てくる
チェックボックスを置いて、チェックをつけたらアクションボタンを表示する
こんな感じでテキストでいいのでバーっとアイデアを書き出します。UIをいちいち作ると時間がかかるので、まずはテキストだけです。
7.UXリサーチで得たファクト・インサイトとアイデアを照らし合わせる
テキストで書き出したアイデアの中でどのアイデアが良さそうかの目星をつけるために、多角的にアイデアを評価して優先順位をつけます。
UXリサーチでのインサイトやファクトを照らし合わせるとどうか
ステップ1で把握したロードマップ観点からはどうか
ステップ4で定義したゴール観点からはどうか
利用できるものはすべて利用して、できるだけ多角的に評価すると、アイデアの選定に自信が出てきます。
よくある問題として、「そのデザインに至った理由が説明できない」というものがあります。
「なぜそのデザインになったの？」という問いに対して、論理的に意図を説明できないケースです。この原因は、感覚的にそのUIデザインが良さそうと判断していることが多いです。
例えば先程の非表示ボタンの例だと、アイデア単体で見るとどのアイデアも大きな差は正直ありません。なので、競合他社のデザインを見てみてそれっぽいものを取り入れたり、今の画面として収まりや見た目が心地よいものをなんとなく選んでしまったりします。
一方、プロダクト・ユーザーのコンテキストにおけるデザインとして考えることができれば、「1ヶ月後の開発ロードマップでXXという機能があるからこっちの方が良い」や「AさんやBさんのユーザーインタビューからはYYだと想定されるので、こっちの方がいい」のような意思決定ができます。
UIデザインを作る前のアイデア出しの段階で、この判断が個人的にはとても大切だと思っているので、できるだけ全体を俯瞰し、ユーザーさんのことやプロダクトの全体像と将来像などの複合的な目線からアイデアを絞り出すようにしています。
意識しているポイントまとめ
少し長くなりましたが、UIデザインの流れで意識しているポイントをまとめておきます。
局所的な対応にならないようにすること。多角的に考える。多角的に考えることで、チームに提案する時にチームの納得度が上がる。また、手戻りが発生する可能性を減らせる。
できるだけアイデアを発散させて、全体の流れを俯瞰して着地させる。開発工数などを無視してあえて制約をなくした状態でアイデアを出したほうがいいアイデアが出ることがある。いいアイデアが出て初めて開発工数に関して相談して着地点をチームで見つければいい。
ステップごとにそれぞれアイデアを発散し書き出すことで、最初はA or Bの二者択一だったアイデアが、AもBも実現できる方法が思いついたりする。
UIをいきなり作らない。UIを作り始めると意識が局所的なUIだけに向いてしまうので、全体での体験を設計してから細かい部分を作るようにする。
なぜそのUIデザインになったのか自分で自分に説明できるようにする。自分で論理的に納得できれば、チームにも納得してもらいやすい。
この記事が気に入ったらサポートをしてみませんか？