【新連載】良いユーザー体験を“維持”するために プロダクトにおける「体験負債」とは

【新連載】良いユーザー体験を“維持”するために プロダクトにおける「体験負債」とは
  • X
  • Facebook
  • note
  • hatena
  • Pocket

 複数のSaaSプロダクトを展開する企業も増えている昨今。そういった企業のなかには、ユーザー体験を低下させる「体験負債」に課題を抱えているケースも少なくありません。本連載では、そんな「体験負債」にフォーカス。マルチプロダクト化やスピーディな機能リリースが進むなか、デザイン組織内で「体験負債」解消に向けた取り組みを進めているログラスのデザイン部部長 高瀬光さんが解説します。初回は「体験負債とはなにか」がテーマです。

 近年、デジタルプロダクトにおける「体験」や「UX」の重要性が高まり、競争が激化する市場のなかで、ユーザーにとって魅力的かつ直感的な体験を提供することは、製品の成功に直結するひとつの要素となってきました。もはや、良いユーザー体験の提供は企業にとって必須の状態に近づいています。

 ですが、良いユーザー体験を“維持”することはプロダクト開発において、かなり難しいのが現状です。

 プロダクトをデザインしたそのときから、体験には一定の負債が発生し蓄積されていきます。もちろん負債をつくらずに「デザイン」と「開発」を進めていくことは重要ですが、プロダクトが成長すればするほどその難易度は上がっていきます。私はこれを「体験負債」と呼んでいます。

 本連載では、プロダクト開発で発生する「体験負債」について解説していきます。初回は「体験負債の概要」についてです。

体験負債とはなにか

 たとえるなら、エンジニアの分野でよく知られる「技術的負債」の「技術」の部分が「ユーザー体験」に置き換わったものだと想像してもらえるとわかりやすいかと思います。

 おもに技術的負債は、短期的な目標を達成するために急いで実装したコードやアーキテクチャによって生じる問題を指します。

 実装当時この負債は、効率的にプロジェクトを進めるための最適な選択に見えます。プロダクトの成長にともないシステムの保守性が低下し、開発のスピードが遅くなり、修正コストが増大するといった悪影響をもたらす特徴があります。この負債をどのように返済していくかはプロダクト開発と切っても切り離せない関係にあります。

 これと同様に体験負債も、短期的な目標やリソースの制約、組織構造における課題の影響を受けて負債が蓄積されていきます。たとえば、体験負債が発生するのは以下のような状況です。

  • 古い仕様や機能が更新されないまま残り、全体の使い勝手を損なう
  • MVP開発をもとにリリースをするが、初期のスコープが「良い体験がある状態」ではなく「機能がある状態」にとどまっている。使えなくはないが使いにくい。使えるようになるのに修練がいる
  • 組織やデザイナーの拡大にともない、デザインにおける十分な整備(デザインシステム、レギュレーション、ライティングルール)が行き届かないままデザインが行われ、UIやUXを統一できずバラバラな体験になってしまう
  • そもそも開発組織内においてデザイナーが足りておらず、エンジニアのみで開発するしかない状況がある

 技術的負債と同様に体験負債も最初は目に見えにくいことが多いですが、時間が経つにつれて、その影響が徐々に顕在化します。

 個人的には、プロダクト開発内で技術的負債は「市民権」を得ているのに対し、体験負債はまだ「市民権」を得られているほど認識されていないと感じています。

 ここでの市民権とは、組織/会社を超えた業界全体で「体験負債は返済する必要性があるよね」という共通認識とナレッジを指しています。

 技術的負債が広く認識されているのは、今まで数多くのエンジニアたちが主体となって向き合い、情報発信を行ってきたからこそだと思います。私は同じことが、「体験負債」にも必要だと思っています。それを誰がやるべきかと言えば、我々デザイナーではないでしょうか。良い体験を維持することは簡単なことではない――。そんな現実に向き合う必要があるのです。

 では、体験負債はデザイナー・デザインの未熟さに起因して発生するのかと聞かれれば、答えはNOです。もちろん熟練度による程度の差はありつつも、どんなに優秀なデザイナーであっても体験負債は発生してしまいます。その理由として私が感じているのは、プロダクト開発で主流になってきている「MVP(Minimum Viable Product)開発」の影響です。

MVP開発と体験負債の関係

 もし体験負債を限りなくなくしたいのであれば、完璧なプロダクトを作ってリリースする必要があります。「完璧なプロダクト」とはユーザーが必要とする機能と良い体験をすべて盛りこみ、あとから機能アップデートする必要性がほぼない状態です。しかしその状態を目指すことは、事業を上手く進めるうえで現実的とは言えません。

 その理由は大きくふたつあります。ひとつは、時間をかけて作った完璧なプロダクトが、必ずしも市場やユーザーのニーズに適合するとは限らない点。市場が刻々と変化していくなかで事業を立ち上げるということは、多くの不確実性が存在しています。そんな状況で、時間をかけてプロダクトを作ることはかなりリスクが大きいのです。

 ふたつめは、マーケットシェアの課題が理由です。完璧なプロダクトを作ろうとすると、開発期間が長期化します。その間に、他社が類似プロダクトを市場に先行投入すれば、競争力を失う可能性もゼロではありません。現在のデジタルプロダクトにおいては、マーケットシェアを速くかつ効果的に獲得することも重要だとされています。

 一方、MVP開発は、必要最小限の機能を持つプロダクトを迅速に市場に投入し、ユーザーからのフィードバックを得ることで、プロダクトをスピーディかつ効率的に成長させます。

  • 迅速なリリース:短期間で市場投入が可能
  • 市場の適応性:ユーザーの反応を基にプロダクトの方向性を調整できる
  • コスト効率:不要な機能の開発を省き、リソースを節約できる

 このようにMVP開発は事業を発展させていくうえで効率的な手法ですが、一方で体験負債が生まれやすい性質も持っています。