デザイナーとしてある程度経験を積むと、自分がどんなデザイナーなのか、今後どういうデザイナーであるべきか、といったことについて日々考えるようになる。デザイナーの種類やタイプもいろいろあると思うが、時代がデザイナーに求める共通言語の一つに「問題解決」というものがあることは確かだと思う。今回はこの「問題解決」を実現するためのデザイナーというものについてまとめてみる。
1. 「問題解決者」としてのデザイナーを極める
これからのUI/UXデザイナーは、「見た目を作る人」ではなく「価値ある体験を設計する人」、そして「ビジネス課題の解決者」としての役割がより強く求められる。以下のような視点で、自分の立ち位置を再定義してみる。
- デザインのアウトプットはUIではなく、「体験」や「成果」
- ユーザーだけでなく、ビジネスやチームにとっての意味を考える
- エンジニアやPMと同じ目線で、プロダクトを良くする視点を持つ
この立場を明確にできると、自身の価値を年齢やツールスキル以上のものにできるのではないか。
2. 意思決定や戦略に近いレイヤーへのシフト
これからのUI/UXデザイナーは、実務だけでなく設計や意思決定の上流工程にも関与する力が求められる。UIUXデザイナーとしての深い経験を活かして、以下のようなスキルを意識的に伸ばすことが重要となる。
- UXリサーチやユーザーテストのファシリテーション
- プロダクト戦略やロードマップ策定への参加
- ビジネス要件とユーザー体験の橋渡し
- 社内外のステークホルダーとの対話力
自身の経験があるからこそ、単なるUIデザインに留まらず、プロダクトの方向性そのものを支えるデザイナーへ進化できるはず。
3. 育成・チーム貢献へのシフト
もし職場に若手デザイナーがいるなら、「自分の手を動かす」から「チームとして成果を出す」方向に少しずつ重心を移すことも、今後の成長につながる。
- 若手のレビュー、フィードバック、育成
- デザインプロセスの体系化・共有
- ナレッジやベストプラクティスの言語化
- デザインカルチャーの醸成
これは「マネジメント」に限らず、チームで良いデザインをつくるリーダーシップの発揮という意味。
4. 「UIUXを超えた視野」を持つこと
デザイナーとしての価値を拡張していくには、デザイン以外の知識との掛け合わせがとても効果的である。例えば以下のようなもの。
- データサイエンスやAI、プロンプト設計
- ビジネスモデルやマーケティング
- サービスデザインや組織デザイン
こうした分野に少しずつ触れることで、「UIUXデザイナー」という肩書にとらわれない広がりを持てるようになる。
これまでの「経験」は自身の強み
40歳を超えた今だからこそ、若手にはない経験知・判断力・俯瞰視点を持っている。それはとても大きなアドバンテージである。「新しいことを学ぶ柔軟性」と「これまで培ってきた強み」を組み合わせて、自分なりのキャリアの形を少しずつ育てていく必要がある。
以上のことを踏まえて、問題解決型デザイナーが具体的にどう行動するべきかを次にまとめる。
具体的な行動
1. 課題の背景を理解するための質問をする
- 「なぜこの機能が必要なのか？」
- 「どのユーザーがどんな状況で困っているのか？」
- 「この施策のビジネス的なゴールは何か？」
👉 常に「与えられたタスクの奥」にある目的を探る。
2. チーム内の会話を観察・翻訳する
- エンジニアやPdMの会話からニーズや矛盾を拾う
- 技術的制約とUXをつなぐ橋渡しをする
- チームが気づいていない「認識のズレ」を可視化する
👉 単に手を動かすのではなく、「会話の構造」をデザインする。
3. ユーザー視点で仮説検証をする
- ユーザーインタビューやアンケートを実施
- ペインポイントを仮説立てし、プロトタイプで検証
- 「理想のUI」ではなく、「使える解決策」を重視
👉 見た目の美しさより、「ユーザーの行動変容」をゴールにする。
4. 数字やデータを根拠に設計を考える
- どの画面で離脱しているか
- フォームの入力完了率は何％か
- ABテスト結果を見て次の改善案を出す
👉 感覚や主観ではなく、ファクトベースで判断する。
5. 他チーム・他職種と協働して問題を解く
- PdMと一緒に要件を整理
- カスタマーサポートの声をUX改善に活かす
- QAやエンジニアからの声をUIに反映
👉 問題解決は「デザインだけでは完結しない」ことを理解する。
6. 目的から逆算して必要なものを選ぶ
- コンポーネントの統一より、「どんな体験が生まれるか」
- デザインツールやドキュメント形式に固執しない
- 自分の案が却下されても「それが正解ならそれでいい」と思える
👉 解決のためなら、自分の手法にこだわらない。
問題解決型デザイナーの行動を、以下のようにまとめる。
- 見た目を超えて、本質を探る人
- 課題を構造化し、対話で動かす人
- プロダクトとユーザーを橋渡しする調整役
- 正解を探すのではなく、最適を模索する人
問題解決型デザイナーになるには、
「この仕事の“本当の目的”は何だろう？」
「今、自分は表層を触っていないか？」
「他の職種の視点で見たら、このデザインはどう見えるか？」
こうした小さな問いの積み重ねが、思考を変え、行動を変え、やがて評価や影響力を変えていく。
思考・マインド面での特徴
| 観点 | 見た目重視型 | 問題解決型 |
|---|---|---|
| 思考の起点 | UIや表現から入る | ユーザー課題や事業背景から入る |
| 成果の定義 | クオリティの高さ | ユーザーの行動変化や課題解決 |
| 会話のスタイル | 手段の議論が中心 | 目的と仮説の対話が中心 |
| チームとの関係性 | 頼まれたものを提供 | 共に考え共に創る |
問題解決型デザイナーが価値を出すポイント
| 貢献内容 | 具体例 | 結果・価値 |
|---|---|---|
| 仕様の曖昧さを構造化 | 「その要件は、どのユーザー行動を変えたいのか？」とPdMに質問し、要件定義の粒度を整理 | チーム全体の認識が揃い、実装ミスや期待ズレが減少 |
| 早めのUXリスク発見 | エンジニアが実装しづらそうな部分をFigmaプロトタイプで視覚化し、複雑化を回避 | 実装工数を20%削減、開発ストレスの軽減にも寄与 |
| カスタマーサクセスとの連携 | 問い合わせ頻出機能の画面フローを観察し、「よくある誤解」をUIで防止する案を提案 | 問い合わせ数が1ヶ月で30%減少、サポートチームの工数削減 |
| デザインレビュー文化の導入 | Slackに「レビュー不要の進捗共有（見るだけでOK）」を投稿し始めた | 強制でなく自然なフィードバックの流れが生まれ、メンバー間の会話が増加 |
| チーム用ミニライブラリの作成 | 他人に共有しやすいUIコンポーネントのFigmaテンプレートを自作 | 作業時間の短縮＋一定のUI整合性を確保できるように |
コメント