こんにちは、阿久梨絵です！
「納品はした」
「要件は満たしている」
それでも、ユーザーは使っていない。
IT業界では、“ 使われないシステム ”が静かに量産されている。
それは単なる設計ミスではない。
ユーザー不在の意思決定とUX軽視が生んだ構造的な失敗だ。
なぜ“使われない”のか？構造的な原因
| 原因 | 現場で起きること | UX的な盲点 |
|---|---|---|
| 要件定義が業務都合のみ | 現場の声が反映されない | ユーザーの行動文脈が無視される |
| 設計者が“使う人”を知らない | 画面が複雑／操作が直感的でない | 心理的負荷が高く、離脱される |
| 導入後のフォローがない | 使い方が分からず放置される | 学習UXが設計されていない |
| “使われること”が評価されない | 納品＝成功という誤解 | 利用率や定着率が軽視される |
“使われないシステム”がもたらす信頼崩壊
・ユーザーの不信感：「また使いにくいものが来た」
・現場の疲弊：使いづらさを補うために手作業が増える
・組織の損失：投資対効果が見えず、改善も止まる
・開発側の孤立：「ちゃんと作ったのに…」という徒労感
UX設計の盲点：使われることが目的化されていない
UXとは、“使いやすさ”ではなく“使われ続けること”。
だが、現場では以下のような誤解が蔓延している。
| 誤解 | 実際のUX的視点 |
|---|---|
| UIが綺麗なら使われる | 文脈・習慣・心理的負荷が設計されているかが重要 |
| マニュアルがあれば十分 | 学習UX・導入UXが設計されているかが鍵 |
| 要件通りなら問題ない | ユーザーの期待値と行動が一致しているかが本質 |
“使われるシステム”にするための設計視点
・ユーザー行動の観察：業務フローだけでなく、感情や習慣も見る
・導入UXの設計：初回体験・学習コスト・安心感を重視
・利用率の可視化：使われ方を定量・定性で追う仕組み
・“使われること”の評価制度：納品ではなく定着を成果とする
まとめ
システムは、使われて初めて価値になる。
使われないシステムは、ユーザーの信頼を損ない、現場を疲弊させる。
「誰のために作るのか」
「どうすれば使われ続けるのか」
その問いを設計に織り込むことが、
UX設計者としての責任であり、信頼構築の第一歩だ。
