プロダクトに眠る時限爆弾「UX負債」との向き合い方

デザインにもある『負債』

作ってから指標を考えるのではなく、何を計測すべきか事前に決めたほうがデザインがしやすくなります。作る目的がハッキリしますし、目的に沿った デザインフィードバックができるのもメリットです。

プロダクト / サービスの成長のためには、適切な指標をもつことが必須です。しかし、すべての施策が計測できるわけではないのが悩ましいところです。例えば「ボタンの一貫性を整える」といった施策に取り組んだところで、クリック率は上がらないですし、ユーザーテストをしても判断が難しい場合があります。

だったらすぐにユーザーインパクトのある施策をしたほうが良いということになって後回しになりがち。こうした『しっかり考えて作ったほうが良いけど、優先順位が落とされてしまう施策』はたくさん眠っています。他にも大事なことがあるのは間違いありませんが、放置しておくとだんだんプロダクトの『負債』が溜まっていきます。

技術負債だけでなく、デザインにも同じような負債が存在します。最近はそれらを UX Debt （UX 負債）と呼ぶことがあります。

UX 負債とは、Nielsen Norman Group の記事「UX Debt: How to Identify, Prioritize, and Resolve」をはじめ様々な媒体で使われている言葉。技術負債と同様、短期的な課題解決のために生まれた小さな問題を指します。技術負債はコードの書き方、採用しているフレームワーク、バグ、複雑化したアーキテクチャなどがありますが、以下のような場所に UX 負債が表れることが多いです。

• UI の見た目
• UI の使い方 / 出し方
• ナビゲーション
• 情報構造
• コピー / ラベル
• ユーザーフロー
• アクセシビリティに関わる要素

これらに問題があったとしても、実装できてしまいます。また、中には抜本的に考え直さなければならない部分もあって、期間内に作りきれない恐れも出てきます。さらに、他部署を巻き込んでプロセスから見直さなければいけない課題もあるので、大掛かりなプロジェクトに成らざる追えない場合もあります。そうした理由から負債になると分かっていてもそのまま作って出す経験をされた方はいると思います。

負債と向き合うための仕組みを作る

技術負債もそうですが、UX 負債を未然に防げるものもあれば、必ずできてしまうものがあります。負債によってどういうリスクがあるのか理解した上で進める場合もありますし、トレンドやソフトウェアの刷新など外部要素から生まれる負債もあります。

負債はできてしまうものという前提のなか、可能な限り少なくしていくための対策が 4 つあります。

まず書き出してみる

漠然と「負債があるよね」と思わず、具体的に何が負債なのか書き出してみると良いでしょう。例えば下図のようにスプレッドシートなどで、重要度や影響はどういったものか書き出してみると、比較検討がしやすくなります。中には想像していたより楽に実行できるものが見つかるかもしれません。

施策がうてる窓口をつくる

ユーザーやビジネスにインパクトがある施策はうちやすいですが、負債返済は計測が難しいことから優先順位が上がりにくい場合があります。ユーザーやビジネスにインパクトがある施策とは異なる種類のものなので、負債返済の施策は『プロダクト品質向上のための施策』と位置付けて提案・実行できるような仕組みを作ると良いでしょう。

仕組み作りだけでなく、「我々が大事にしている品質は何か？」はチーム内で共有したほうが良いでしょうし、時にはデザイン原則のようなものを作るところから始める必要があります。

ガイドラインやチェックリストを作る

ライティングも UI デザインも、ある一定以上の水準を保ちたいのであればガイドラインは必須です。ガイドラインだけでなく、デザインをハンドオフをする前にチェックリストは確認するといったワークフローも合わせて考えたほうが良いでしょう。

UX 負債を防ぐために作られたかのように見えるデザインシステムですが、皮肉なことにデザインシステムそのものも負債が貯まっていきます。ただ作るだけでなく運用体制を作らなければいけないのもそのためです。デザインシステムがあれば大丈夫と考えるのではなく、短期的な負債を未然に防ぐための手段と捉えたほうが良いでしょう。

全体が見れるマネージャーをたてる

ここで言うマネージャーは部署で働くデザイナーの管理をするマネージャーというより、プロダクトマネージャーに近い存在かもしれません。技術側では、作る技術を高めていくエンジニア職と、技術の現在と未来を見据えた上でアーキテクチャ / システムを全体的な視点から考え、設計するマネージャー職がいます。

UX 負債の返済はデザイン側だけで解決するものだけでなく、技術 / 実装まで踏み込まないと解決しない問題もあります。プロダクト、ビジネス、技術を踏まえた上で、デザインはどうあるべきか考え、提案できる人がいると UX 負債の取り組みがしやすくなります。