UIデザイナーとは？〜私たちが考えるUIデザイナー（中編）
セカンドファクトリー(以下、2FC)で、UI/UXデザイナーとして活動している鈴木です。2025年は「つくり出す」。色々なものに対して「つくり」も引き続きしますが、発信を含めた「出す」というところの活動も熱を持ってやりたいと思っています。
と言っている側から、前回の投稿から間が空いてしまいました。
前編に続き、中編ではUIデザインのメインとなる「UIをかたちにする」という段階から次の流れについてまとめてみます。
UIを提案する
きちんと要件に沿ったUIを形にすることができたら、次に重要なのは、そのデザインをチームで共有し、共通認識を持ったうえで実装に移ることです。
なぜこのようなデザインになったのか、実装にあたり懸念点はないか、といった不確実な点を解消し、チーム全体で合意を形成することが必要です。
そのためには、デザイナー自身が背景や要件、選択した理由などを丁寧に説明できる能力が求められます。
なぜそのようなUIを採用しているのか？
UIデザインには唯一の正解があるわけではありません。同じ要件でもターゲットユーザーの性質やプロダクトのコンセプト、機能追加のロードマップ、現在の事業の状況、一般的なUIのルールなどにより、さまざまなアプローチが考えられます。
なので、「こちらの方が良いと思った」という主観的な理由だけでは説得力に欠けます。具体的には以下のようなポイントを押さえていると、スムーズに説明できそうです。
誰のために、どのような機能を実現したくてこのUIを提案しているのかを把握している。
どのようなユーザーが、何の課題を持っていて、それをどのように解決できるからこのUIになっているなど、目的をきちんと踏まえられていないと、そのUIが「良いUI」かどうかの判断がしづらくなります。
「制約条件」を知っている
例えば、スケジュールにあまり余裕がなかったり、開発リソースに余裕がないながらも改善を進めたい場合、バランスの取れた提案になっていないと、せっかく良いデザインをしても採用できなかったりします。
100%の課題解決は難しいが、一番優先度が高く、事業に即効性のある課題に絞ってアプローチすることもあるでしょう。
UIコンポーネントの基本原則を知っている
なぜこの部分はこのUIコンポーネントを使っているのか？など、同じ「項目を選択する」機能においても、ラジオボタンやチェックボックス、トグルスイッチなどにはどういう意味合いがあり、一般的なUI言語としてどう利用されているのか？を知っておくことで、根拠を深めることができます。
よくあるUI
大手のサービスや利用者の多いサービスなど、スタンダードとしてよくあるUIを参考にする場合はあります。ユーザーも日頃頻繁に利用しているUIであれば、新たに学習するロスも少ないでしょう。
ただ、無思考にUIを採用をするのではなく、その理由を深く掘り下げておく必要があります。一般的なパターンが自分たちのプロダクトに適しているかどうかを再考し、場合によっては独自のアプローチが必要かもしれません。
フィードバックのもらい方
デザイナーの提案についてフィードバックをもらいます。
フィードバックのもらい方や、フィードバックを受けての深掘りなどはなかなか深く、感想や意見をただもらえれば良いというモノでもありません。これについては以下の本がおすすめです。
今回、「フィードバックの受け方」そのものはお任せするとして、以下のようなフィードバックをもらうことがあるかと思います。
実装都合とかけ離れ過ぎたデザインではないか？
「こうあるべき」を強い意志で貫くのは、時としてデザイナーに求められることでもありますが、「実装不可能」なデザインを提案しても、現実化されません。なんとか実装できる場合でも、その分工数をエンジニアに強いることになります。
そのサービスの「データ設計思想」であったり、「標準コンポーネントではない」アプローチだったり、本当に工数をかけてでも実現した方が効果があるかどうかは、エンジニアときちんと擦り合わせた上で、現実的な案を再検討する場合があります。
デザイナーが把握していなかった要件
後編で述べる予定の「UIを形にする前」の段階で、こまめに共通認識をとっていれば、この段階で問題が起きることはあまりないかもしれません。
万が一新たな要件が後から見つかった場合などでも、現在の進行状況と要件の重要度によって、どこまで検討し直すかの判断を冷静にしたいところです。
実際のユーザーへのヒアリングなどを経て
実際に形にしたUIを見てもらい、現場の視点や実際のユーザーの意見によって、新たな気づきが生まれることがあります。これらも柔軟に検討に取り入れられることが大事です。
俯瞰した目で見てもらって出てくるフィードバック
画面やUI単位のデザインに没頭していると、全体を見渡す視点が欠けることがあります。チームメンバーからの俯瞰的なフィードバックを活かしましょう。
対応すべきフィードバックと自身の意見のすり合わせ
もらったフィードバックをすべてそのまま反映するのではなく、自分の意見やデザインの意図を改めて咀嚼し、議論を通じて最適な解決策を見出す、つまり「一緒に作っていく」ことが大切です。その過程で新しく素晴らしいアプローチが見つかることもあると思います。
UIを仕上げる
もらったフィードバックに向かい合い、落とし所を見つけ、UIを仕上げていきます。これまでスピードと本質を踏まえた議論をしながら走ってきましたが、一旦落ち着いて「きちんとする」ことも大事です。
デザインファイルを整理する
「レイヤー 123」のようなファイル名になっていませんか？
デザインファイルが「荒れて」いると、自分で修正するときに困ったり、作業分担してもらう時に困ったり、後から再利用する時に困ったりします。
また、デザインの置いてある位置がまばらだったりすると、エンジニアがどのデザインを参考にすれば良いのかわからなくなって質問が来たりもするでしょう。
自分以外のメンバーと連携するときに支障が出たりすることが多いので、常にデザインファイルは整理しておきましょう。（と、自分に言い聞かせています…。
UIデザインは細部の積み重ねでもある
ユーザーの認識の齟齬なく機能さえ動けば、ひとまず目的が達成されたりはします。しかし、細かな空きや、フォントサイズ、情報強度のちょっとしたメリハリの違いで、情報にユーザーが向合う際の捉え方が変わる場合もあります。
読む気の全く起こらない行間の詰まった文字ブロックと、読みやすくするために適切な行間や、文字色、空間の確保などまで調整されたデザインとではユーザー体験に差が出るのは言うまでも無いことです。
細部も大事だが全体も見る
ユーザーが画面に向き合った時に、適切な情報量になっているか？目を引きたい要素などはちゃんと強調できているか？、改めて画面全体を見てみて違和感がないかどうかも忘れないようにします。
UIを実装する
デザイナーがFigmaでUIを仕上げて、エンジニアに連携したら、後はエンジニアがFigmaのDevモードの情報を見ながらよろしく実装が完了する？
そんなことはありません。
この段階でもエンジニアと「一緒に作っていく」流れは変わりません。
エンジニアからの疑問や相談に応える
実装過程でエンジニアからの相談が出てくる場合があります。
デザインを実際に実装しようとした時に、想定していなかった技術的課題が出てきたり、デザイナーで把握仕切れなかったデータパターンにエンジニアが気がついたり、どんなに綿密にデザインをチェックしていても、後から課題が出てくるのはそんなに珍しいことではありません。
その場合には、デザイン意図と技術的課題を見ながら、現実的な解決策を一緒に模索することが大事です。
実装されたUIのレビュー
実装されたUIがデザインの意図通りに反映されているかを確認することが大事です。意図からズレた実装のままでユーザーにリリースされてしまい、ズレが大きかった場合に、ひょっとするとユーザーの課題を十分に解決できないことになるかもしれません。
細かなズレや、解釈の違いを指摘する場合にも、その背景や理由、目的などをきちんと再連携して、丁寧な連携をすることが大事です。
取り組みを検証する
ここまでチームで検討してきた機能が無事リリースされ、顧客やユーザーに届けられたら、UIデザイナーの仕事は終わりでしょうか？
いや、まだ終わっていません。
そもそものチームの目的は、「UIデザインをすること」ではなく、「ユーザーや事業の課題を解決し、効果を発揮すること」です。デザインしたものが、効果を発揮しているかどうか？を確認する必要があります。
リリースした機能は十分利用されているか？
リリースした機能変更は混乱なく受け入れられているか？
リリースした機能で課題は解決されているか？
のような、課題の種類にもよりますが、いくつかの観点や指標で振り返ります。十分な効果が発揮されていなかったり、これまでの既存ユーザーに混乱を起こしている場合には、急ぎ追加の対応が必要になる場合もあるかと思います。
また、デザイナー自身の振り返りとしては、
今回採用したデザイン方針で良かったのか？
デザインの進め方などで「こうしたら良かった」など改善点はないか？
次に活かせることはあるか？
など、動き方やデザインアプローチ面での振り返りもあるでしょう。
「UIを形にした後」も大事だった
「UIを形にした後」という部分について、今回UIデザイナーの求められるところをまとめてみました。
UIはFigma上でかたちを作れば終わりではありません。ユーザーにプロダクトの価値が届き、上手くいって事業にインパクトを与えることが本当の目的です。
そのためには、かたちにした後も実装を経てのリリース、振り返りのプロセスを通じて、課題が解決されているか、ユーザー体験が向上しているかを継続して確認し続けることこそが重要です。
次回は「UIを形にする前」のプロセスに範囲を広げて、知っておかなければいけないこと、考慮する必要があることなどを改めてまとめてみようと思います。
2FCデザインチームは範囲を広げて活躍できるUIデザイナーを募集しています。
クライアントの期待に応え続け、デザイナーとしての価値を高めていきたいと考える、UIデザイナーを絶賛大募集しています。
以下応募要項から、2FCデザインチームの方向性や価値観に共感いただいた方、ぜひご応募ください。
ViViViTでまずはメッセージのやり取りからでも〜と考えていらっしゃる方はこちらも。
【メンバークラス】UI/UXデザインをもっと深く、次のステップを目指すデザイナー募集