以下の内容はあくまで個人の経験に基づくものであり、全ての企業やチームの状況を代表するものではありません。これらの観察を通じて、UI/UXデザイナーが現実の協業において参考にできる別の視点を提供できれば幸いです。
多くの人が考えているユーザー体験／インターフェースデザイン
UI/UXの主な業務は、操作ロジックの分析、機能の一貫性チェック、インターフェースの美的整理を行い、システムが視覚的に使いやすく、実際に混乱しないことを保証することです。
しかし、時間が経つと気づくのだが、UI/UXの仕事は想像以上に複雑だ。
時にはエンジニアに論理を説明し、時にはPMのアイデアを画面に落とし込み、さらには上司に「売れる可能性を感じさせる」デザイン案を理解させる必要がある。
「ユーザー中心」がデザインの出発点だと思っていた。実際にUI/UXを作り始めて初めて、この言葉は口で言うほど簡単ではなく、実践するのは非常に難しいと知った。
多くの人はデザイナーの任務は「画面を美しくすること」だと思っている。
しかし真の課題は、画面ではなく「コミュニケーション」にある。明確な論理がなく、一貫したプロセスがなく、共通の言語がない場合、
プロジェクト全体は、ナビゲーションを間違えた車のようなものだ。UI/UXの役割は、おそらく横で方向を指摘することだけで、車がどこへ向かうかを決めることではない。
私たちにできることは、少なくとも路線があまりにも大きく外れないようにすることだ。
ユーザーリサーチ？それともユーザー推測？
チームは毎日「ユーザー中心」を口にしている。理想的な状況ではインタビューや観察、アンケート調査が必要だが、現実は時間もなく、予算もなく、人手もない。
時には営業が言う：「お客様はもっとシンプルにしたいんです。」時には上司が言う：「この方が直感的です。」
データもなければ、ユーザーもいない。明確な状況もない。
デザイナーは経験に頼って輪郭を描くしかない。ペルソナやユーザージャーニーを作成し、ユーザーフローを理解してもらいたい。
エンジニアが数秒間見た後：「これは何だ？複雑すぎる。とりあえず使わないでおこう。」
聞いたときは理解できなかったが、考えられる状況は：ユーザーを気にかけていないのではなく、ユーザー調査をどう「読み解く」べきか誰も知らないということだ。
理論上、これがUCD（ユーザー中心設計）の最も核心的な部分である：設計は推測ではなく、データと洞察に基づいて行われるべきだ。しかし時間とリソースが不足している場合、「リサーチ」はしばしばスローガンに成り下がる。結局、設計は「ユーザー中心」から「作業者の利便性中心」へと変質してしまう。
UI/UXの仕事は、まさにこのジレンマと曖昧さの狭間で立ち往生している。
PRDはファイル、UI/UXは翻訳コンニャク
上司は「設計はPRD通りに進めろ」と言った。しかしファイルを開くと、かえって頭が痛くなった。
半分は使えるが、半分は霊感が必要だ。同じプロジェクトに三つのバージョンがあり、内容はそれぞれ異なる。
「現在の真実」がどれかを自ら判断し、それを実際に実行可能なインターフェースに変換しなければならない。
後になって気づいたのだが、PRDは説明書などではなく、言語テストだったのだ。
エンジニア、PM、デザイナーの三部門は、それぞれが自分のバージョンを語っているのに、お互いに理解しているはずだと思っている。
理想的な状態は、皆が考えを揃えて合意を形成することだが、現場はむしろバベルの塔のようだ。だから日々の仕事は、画面や体験デザインだけでなく、要求が本当に一致しているかを確認することである。
UI/UXの「デザイン」は、多くの場合、部門横断的なコミュニケーションと翻訳作業である。どんなに美しいデザインでも、目的を達成できなければ、すべては幻に過ぎない。
設計は間違っていないが、最終的な画面はそうではない。
プロジェクトが終わるたびに、まず深呼吸して心の準備をする。なぜなら、最終的な成果物は必ず予想外のものになるからだ。
エンジニアは実は知っている、Figmaを直接フロントエンドに変換できないことを。しかしシステムをスムーズに動かし、コードが壊れないようにするため、実装時に「自分たちで調整」することが多い。その「調整」こそが、往々にしてデザイン崩壊の始まりなのだ。
文字間隔、ボタン、動線、一つ一つが「システム内で動作するバージョン」に置き換えられた。
デザイン案のリズムが変更され、比率が圧縮された。最終的な画面はまだ使えるが、もはやあのデザインではない。
エンジニアの責任者は後でこう言った：「君たちの設計は間違っていない。ただエンジニアが実現できなかっただけだ。」この言葉は慰めではなく、現実だ。デザインシステム、コンポーネントライブラリ、ハンドオフ文書…これらは確かにギャップを減らせるが、解決するのはスタイルの一貫性であって、「理解の一貫性」ではない。
その後、彼も率直に認めた。既存のフレームワークに適合し、壊れない形でFigmaを直接コードに変換できるプラットフォームが欲しいと。
実は双方が同じことをしている：画面と論理を現実に近づけようとしているのだ。ただ、異なる方法で苦闘しているだけだ。
最終的に、双方は互いに受け入れられる方法でそのシステムプロジェクトを完了させる。画面は当初の仕様とは異なるが、少なくとも動作し、実行可能で、使用できる状態である。
時には、これがすでに最大の合意である。
UI/UXの仕事とは、こうした隙間でバランスを求めることだ。画面をデザインするだけでなく、共存できる現実をデザインすることである。
混乱の中で働くときも、方向を忘れないでください
設計とエンジニアリングの距離は、バージョン管理のようなものだ。
永遠に同期を追いかけても、永遠に遅延は生じる。誰のせいだとは思わない、ただ誰も「正しい」を本当に定義したことがないだけだ。
ここでは、デザイナーが実際のプロジェクトでよく遭遇する状況を記録したいだけです。似たようなことはほぼ全てのデザイナーが経験していますが、シナリオが異なるだけです。
デザイナーの存在は、おそらくすべての問題を解決するためではなく、問題が見えるようにするためであり、時にはそれで十分なのだ。
理想は豊満だが、現実は骨ばっている。だからこそ、何度も問いかけるのだ。「これで本当に使いやすいのか？」と。
その問題こそが、デザインの出発点である。
使いやすさはデザイナー、エンジニア、ユーザーが共に定義するものです。絶え間ないコミュニケーションと修正の中で、デザインは架け橋となり、ユーザーの声をチームに届け、チームの努力をユーザーに理解させる役割を果たします。
これこそがデザインの存在意義の最大の価値かもしれない。
💬あなたへの問い
デザインの価値は、ユーザーにシステムを理解させることか、それともシステムに人間を理解させることか？もし双方が理解し合えないなら、それでも「ユーザー中心」と言えるのだろうか？
#UIUX#デザイン日常#プロジェクト管理#デザイン思考#デザイン職場#プロダクトデザイン#職場体験記
