UIデザイナーとは？〜私たちが考えるUIデザイナー（後編）
セカンドファクトリー(以下、2FC)で、UI/UXデザイナーとして活動している鈴木です。
前編と中編では、「UIをかたちにするところと、その後」について述べました。この後編ではUIデザインのメインとなる「UIをかたちにする」よりも「前」にする大事なことを、まとめていきたいと思います。
実際にかたちをつくる前に
所謂「UIデザインをする」という行為のうち、「Figmaを使って画面のイメージを作る」部分は、ほんの一部でしかないと思っています。大体のケースにおいて、Figmaを触り始める前にほとんど終わっているか、脳内に既にかたちが見えていて、それらをただツールを使って可視化しているに過ぎないという感覚を持つことが多いです。
ということを踏まえると、実は「UIをかたちにする前」が非常に重要なプロセスになります。
UXデザインの5段階モデル
有名な図として、Jesse James Garrett氏著の『5段階モデルで考えるUXデザイン』で提唱されている、このようなものがありますが、これらを下から順番にきちんと押さえていくのと似ているのかもしれません。
必ずこの通り順番にやっているというものでもなく、経験のあるデザイナーであれば、検討の状況やチームでの議論の状況によってこれを無意識に「行き来」しながら、「UIをかたちにために」を行なっていることが多いでしょう。
課題を見定める
今回のデザインによって「何を解決したいか？」を明確にします。そもそもここがずれていると、せっかく検討したデザインが何の価値も出せずに終わってしまう可能性があります。
それはどんな課題か？
サービスやプロダクトを利用するユーザーの課題であったり、現状のサービスやプロダクトそのものが抱える課題であったり、また事業側の課題であったり、様々な観点で課題を捉える必要があります。
それはどのような人物の課題か？
利用ユーザーであれば、そのユーザーはどんな背景を持っていて、どのような文脈でその課題に悩んでいるのか？また、その課題をどうしたいと思っているのか？など、対象となるユーザーのペルソナを正しく掴んでおきたいところです。
ユーザーの前提が変わることで、課題そのものが無くなったりすることもあります。
何のために今その課題に取り組むのか？
また、課題解決の先にある「目的」ももちろん重要です。そもそも何のためにこの課題に取り組むのか？によって課題の捉え方も変わってきます。
例えば「この画面は日本語で提供されているので、英語をネイティブとするユーザーには意味が伝わらない」とした場合、もちろん英語化していくのですが、
その目的が「現在、サービスを契約しようと思ってもらっている大口顧客がいるのだけど、英語で利用するユーザーがほとんどなので英語の画面がないと使えないという顧客に応える」のと、
「今サービスを利用している顧客から、英語で利用するユーザーが何人かいるので、英語の画面も提供して欲しいに応える」では、課題に取り組む時の前提が大きく変わってきます。
課題が解決されることによって、目的が達成された状態を明確にイメージできていることで、「どのように解決するか？」の判断に大きな影響があります。
要件を決める
あらかじめ掴んだ「目的」や「取り組む課題」を踏まえて、どんな機能で先述した課題を解決できそうか / するのか？を明確化します。
取り組む範囲（スコープ）
課題を解決するにあたって、ピンポイントで局所的に対応できる場合もあるでしょうし、全体の体験設計に手を入れて根本的に改善する場合などもあるでしょう。
ベストを追い求めればどこまでもやれてしまいますが、その機能を実現することでの影響範囲や見込まれる成果を考慮して現実的な落とし所を考える必要があります。
「どこまでもとことんやるのか」「そこまではやらなくて良いのか」ですね。
優先順位
検討する機能によっては、必ずしも「絶対これが良い。デメリットはまったくない。」とわかりやすく言い切れるような状況ではないこともあります。
その場合には、「より多く課題を解決できる機能アプローチはどれか？」を、検討項目に優先順位をつけて整理をしながら検討することになります。
スケジュール
考えうる最善の要件を検討することはもちろん大事ではありますが、それにいくらでも時間を費やしても構わないというかというと、そこは別でしょう。
緊急度が高く、なるべく早く解決することが一番大事なのであれば、多少ベストのアプローチではなかったとしても、80%の課題解決さえできれば…という場合も多いはずです。
また、サービス/プロダクト上、ものすごく大事な機能と考えられるため、ある程度時間がかかったとしても、慎重に根本的な改修を行い、確かな動作をすることを優先することももちろんあります。
機能上の制約
「ユーザーにこの情報を全て見せることができたら…課題が解決されるかも？」と考えたとします。
しかし、そのためには複数のデーターベースからデータを持ってきて、データの集計を行う必要があり、結果的に膨大な処理時間がかかってしまい、「ユーザーが気軽にその情報を見ることができない」のであればどうでしょうか？
その場合には、「この情報を全て見せる」機能を別の捉え方をするなどして、検討する必要があリます。
技術的な制約
その機能は実現することはできるが、そのために既存の仕組みの深いところまで手を入れる必要があり、いざ、そこに手を入れるとなると不具合を生まないように慎重に作業する必要がある。
など、運用中のサービスやプロダクトだからこその、センシティブな問題もあります。
デザイン方針を決める
要件を踏まえて、その機能をどうデザイン検討しようか？
明確化した要件を踏まえて、どのような方向性でデザイン検討を行うかの見当をつけます。例えばある1つの機能をデザインする場合でも、いくつか複数の方向性が考えられる場合も多いです。
あらゆる可能性を検討すること自体は良いと思います。
ただ、闇雲に思いつくままに検討を進めるというよりも、今回はどんなアプローチを取れるかを仮設定しておくだけでも、狙いを絞ってより解像度高く取り組めたりします。
デザイン方針の当たりをつける際には、前提となる要件は当たり前として、デザイン上の制約、既存の画面構造、実装上の制約、ユーザーの使いやすさ、サービスの世界観など、いろいろな条件が関係してきます。
ユーザーストーリーを確認する
改めて「ユーザーストーリー」などを省みて、そもそも「誰が」「何のために」「何をしたい」のか？
について考え直すことで、要件を俯瞰して捉えることができ、デザイン方針のバランスが取れているかを見ることができたりします。
ユーザー体験のバランスを考える
実現する機能は「とにかくユーザーにとってわかりやすく、すぐに使える機能であれば良い」わけでもありません。
「直感的に操作ができて、瞬時にタスクを終えられること」が要求される機能もあれば、「事前に正しく内容をじっくり認識してから確実に安全にタスクを完了すること」が重要であるなど、機能によって求められる体験は変わります。
前者であれば、なるべくシンプルな構成のUIと最小限の情報提示を検討しなければならないですし、後者であれば如何に正しく認識を持ってもらえるか？間違いを起こさないためのインタラクションは何か？という視点で情報提示の仕方を検討しなければならないでしょう。
システムとのインタラクションを考える
上で述べたような「ユーザーが間違いを起こさない」ような機能を考える際には、あえて設定項目をいくつかの画面に分割した上で、ユーザーにセクションごとに項目を入力して送信してもらい、システム側で入力項目の確認を行って、その結果をフィードバックし、OKであれば次の画面に…など、
一度に膨大な情報を登録させるのではなく、段階的に確認しながら登録させる方が効果的だと思われます。
実現性や実装工数を意識する
「これって実装できますか？」おそらく大概のことは実装できるのではと思います。ただそれには、「期間」であったり「工数」が潤沢にあれば…です。
実現したい機能に対して、ものすごく大掛かりな実装になったり、複雑性の高い実装であれば、その分期間や工数に影響が出るでしょう。
それだけの期間や工数をかけてでも、解決される課題がサービスやプロダクトに良い結果をもたらすことが、チームで認識が取れているのであれば、その案は問題なく採用されますが、コストに見合わない場合には難しくなります。
そもそも、実現できなければ、課題を解決することができなくなってしまうのは当たり前のことかなと思います。
情報を設計する
さて、ここまで丁寧に検討してきたら、
ようやくこの機能の追加される画面をFigmaで検討していけますか？最後にもう1つ気をつけたいことがあります。
ある機能の実現を考える際に、ポン！と単純にその機能に関する1画面を検討して済むケースはあまりありません。
プロダクトの全体を考えた時に、その機能が扱うオブジェクトはどこと関連性があるのか？
また、ユーザーはどのような導線を辿ってそこに行き着くのか？タスクが完了された場合には、どこに戻って引き続きサービスを利用するのか？など、「プロダクトの中の機能としてどう落とし込まれるべきか？」も重要です。
サービス及びプロダクト全体から見た情報構造
つまり、現状のサービスが扱っている「情報」がどのような構造になっていて、ユーザーはその構造をどのように認識しているか？というものを考慮する必要があります。
でないと、機能を追加するたびに新しくボタンを設置しなければいけなかったり、ユーザーがその機能に気が付けなくて、利用されないままだったり、迷ってどうしたら意図したところに戻れるかわからなくなったりする可能性があります。
なので、機能に関わるその1画面だけに注目をするのではなく、サービス全体から、あるべき「ナビゲーション」や画面遷移、UIで扱うラベルなどの「そのものを示す名称」がこれまで扱われてきたサービスの文脈に繋がっているものであるか？など、その画面の前後含めて設計を意識する必要があります。
必要な情報の想定
ユーザーに丁寧に情報を伝えたいと考えたとして、「ユーザーに知らせたい情報全て」を単純にそこに提示してしまうと、情報過多になってしまい、返ってわかりにくいレイアウトになることは多々あります。
情報の優先度に従って、そこに全て表示しなくても「ヘルプページやマニュアル」で説明すれば、サービスやプロダクトの前提として十分認識してもらえる情報なのか、
ツールチップで「その瞬間だけ提示すれば事足りる」情報なのかの判断をした上で出し分けることも、ユーザーに迷いなくタスクを完了してもらうためには重要な要素です。
情報の優先順位と階層
1画面のデザインを検討する場合でも、情報の優先順位や情報階層の構造に従って、スタイルの強弱や、マージンの使い分け、レイアウトの順番などを適切に設計することが、ユーザーがその画面の情報をスムーズに把握して、操作をしやすくすることにつながります。
「UIを形にする前」でほぼ決まる
「UIを形にする前」という部分について、今回UIデザイナーの求められるところをまとめてみました。
実際にFigmaを触りながら「UIの可視化」をする前段階での整理や判断でほぼどういう「かたち」にすべきかは固まっていることが多いです。
また、Figmaを触りながら、もしくはFigmaのアートボード上にそういった前提情報を整理しながら明示することもあります。
さて、3回にわたってまとめてきました、単純にUIデザイナーと言っても、「Figmaを使ってUIの表現をかたちにする仕事」ではないと弊社では考えています。
様々な情報や観点を紐解いて整理しないといけない、大変なプロセスに関わっていますが、だからこそデザインの力でサービスやプロダクトの価値向上や事業の成功に寄与できるのだと思っています。
2FCデザインチームは範囲を広げて活躍できるUIデザイナーを募集しています。
クライアントの期待に応え続け、デザイナーとしての価値を高めていきたいと考える、UIデザイナーを絶賛大募集しています。
以下応募要項から、2FCデザインチームの方向性や価値観に共感いただいた方、ぜひご応募ください。
ViViViTでまずはメッセージのやり取りからでも〜と考えていらっしゃる方はこちらも。
【メンバークラス】UI/UXデザインをもっと深く、次のステップを目指すデザイナー募集