設計債務はどのように測定または計算されますか？
設計者はおそらく開発者が「技術的負債」と同じように「設計負債」に関係することができると思います。研究、設計、および開発作業を行うことによって発生するコストの何らかの組み合わせであるUX負債の例さえあります。
これを過度に複雑な質問にするのではなく、特に設計負債に焦点を当てたいと思います。研究負債に比べて数量化はおそらく容易ですが、技術負債に比べて容易ではないからです。
設計慣行の変更のメリットを測定できるだけでなく、設計の負債を生み出す理想的ではない設計変更のコストを計算できる方法の例はありますか？
技術的な負債は技術面でほとんど普及していないので、私は少し懐疑的ですが、あなたの質問がUXの立場から厳密に回答されることを望みます。
という名前の論文を見つけました
技術的な債務管理の手法と方法の分析：アーキテクチャの観点からの反映
カルロスフェルナンデスサンチェスらによって書かれました。
それは多くの種類の負債を呼び込み、そのうちの1つはと呼ばれます設計と建築の負債Wordの設計が製品設計とコード設計のどちらを指しているのかわかりません。
設計およびアーキテクチャ上の負債：アーキテクチャ上の負債は、最適化されていない先行投資ソリューション、またはテクノロジーやパターンが優先されるようになると次善のソリューションになる可能性があります。
とにかく、それが私たちの「デザイン」に言及していなくても、提供された債務管理フレームワークはドメインだけでなくドメインでも使用できるほど抽象的であると本当に思いますが、UXには完璧ではないかもしれませんが、近いと思います当然のことながら、同意する場合は、その用紙を試してみてください。
UXプロジェクトの設計フェーズで必要な労力とプロセスに基づいて、設計債務の額を見積もる簡単な方法は次のように計算できると思います。
人的資源
- 設計者を採用する（社外で行う場合）、またはスタッフを（社内で行う場合）タスクに割り当てるのにかかる時間
- リソースが最初の設計タスク/アクティビティに費やした時間
設計の複雑さ
既知の要件の変更を満たすために新しい設計を作成するために費やされた時間（つまり、初期設計は、新しい要件に適応できるほど柔軟ではなかった）
既存のデザインと新しいデザインを再調整して、一貫したルックアンドフィールを維持するか、ユーザーエクスペリエンスを向上させるために費やした時間
その他
- 初期設計中に考慮されなかった予測可能な要件変更の結果として発生したその他の時間
これらのアクティビティに費やされたすべての時間を相当する$値に変換し、最初のデザインタスクに費やされた時間を除いたコストを合計すると、デザインの負債の大まかな見積もりが得られます。
（少なくとも設計から実装までのワークフローが理想的である場合は）設計債務が技術的債務に流れ込まないようにするか、少なくとも両方のタスクを実行する同じリソースであっても明確に定義する必要があることに注意してください（フル-スタックデザイナー/開発者）。
例
概観
私の目標は、登録プロセスでのコンバージョンを増やすことでした。私の分析と観察により、これは良い経験を提供していないことがわかったので、「日付ピッカー」を変更したい入力フィールドがありました
問題
日付ピッカー入力フィールドは、生年月日の入力に使用されました。カナダの問題は、私たちが誕生日を言うことであり、月/日/年の順序で誕生日について考える可能性があります。ただし、ユーザーが日付ピッカーと行う必要のあった操作は、年/月/日でした。私の見解では、ユーザーは年をどうやって効率的に変更するか（10年表示に切り替える）方法を理解できないということでした。これにより、最終的には登録が遅くなり、誕生日が正しくなくなり（正しいことが非常に重要でした）、ユーザーが諦めます。
設計債務
この改善の推奨事項は、1年以上にわたってバックログに残りました。私が新しい生年月日入力フィールドを表示したときにモックアップを更新し続けるのに苦労しましたが、クライアントのサインオフ用のモックアップを作成するたびに、UXが望む方法ではなく、配信時の外観を示す必要がありました。これにより、多くの場合、常に2つのモックアップを維持できます。
負債の測定
入力フィールドが最終的に実装されたとき、コンバージョンの1.2％の増加が観察されました。このUIパターンが1年前に実装されていれば、何人のユーザーを取得できるかを遡及的に分析することができました。次に、この数を取り、それを実現するための開発/設計作業を差し引きました。 UXチームは、UX/UIの推奨に関して、より多くのkloutを与えられています。
概要
これは1つの例ですが、製品へのさまざまな変更の一部としてUXチームが更新を要求したUIパターンが多数ありますが、実装されているのは一部だけです。 UIモックアップ（設計負債）と実際にクライアントに提供するモックアップを見たいので、UIモックアップの保守に多くの時間を費やしています。