企画書だけを見てデザインを作り始めていないか

※この記事は「COUNTER WORKS Advent Calendar 2025」の16日目の記事です。

カウンターワークスでUIデザインをしている小野です。

今回はB向けサービスなど、ユーザーと比較的距離が離れやすい開発チームで陥りがちな落とし穴と、その対処法について考えたいと思います。

企画書だけを見てデザインを作り始めていないか

PdM（プロダクトマネージャー）やPO（プロダクトオーナー）が書く企画書。「UI作って！」と言われて、記載されている課題・提供価値、あるいは仕様だけを見てUIを作り始めてはいないでしょうか。

もちろん小規模な開発だったり、議論の余地がないケースもあると思います。しかし、企画書のみを情報源としてUIを作り始めてしまうと、細かいUIを決めるときに判断軸がなく根拠の薄い意思決定になってしまったり、力の入れどころを間違えたりして、結果的に使われない機能になってしまうことが経験上多いと感じています。

思考の結果だけでなく、「ソース」を辿る

企画書には課題や背景、提供価値、仕様などが記載されています。しかし企画書というのは、わかりやすさのために情報を絞って書かれることも多いのではないでしょうか。

「どういう情報をもとに企画したのか」

図でいう①のプロセスをデザイナーがしっかり把握することが、実際の課題感やユーザー像をありありと想像することにつながりとても大事だと考えています。

「ソース」を情報として残して参照可能にする

分析クエリやGAレポートといった定量的な情報はもちろんですが、カウンターワークスではユーザーの声などの定性的な情報も蓄積しています（まだ一部ではありますが）。

誰が・どこで・どういう文脈で・どういった発言をしていたのか。こうした情報をデータベース化しています。

※現在はNotionから、インサイト管理に特化した別のサービスに移行しています。

ヒアリングなどの議事録から気づき（＝インサイト）を抽出し、蓄積しています。デザイナーはそうしたソースとなる情報を聞き出したり、自分で探したりして、企画書とセットで確認しながらUIを作っていきます。
もちろん必要に応じてユーザーにヒアリングさせてもらったりします。

思考のソースを把握すると、企画へのフィードバックや企画者とのディスカッションも捗る印象です。

ユーザーが触れるのは最終的にUIだという意識

規模が大きくなったり、B向けの業務システムだったりするとUIデザイナーがユーザーから離れやすくなるように思います。

しかし、ユーザーが触れるのは最終的にUIだけという非常に重要な仕事です。

直接ユーザーと接する機会がなくても、なるべくユーザーに近い情報を取りにいく行動を取っていきたいですね。