私はUXプロジェクト(これも 質問 以前に投稿したもの)のいくつかのメトリックを開発することを検討しており、 Kano モデルとそれがどのようにマップされるかについて読んでいますさまざまなユーザーの行動/期待。機能の有無に関するユーザーの認識(ref here )に基づいて製品の機能/機能を分析し、生成された機能がさらにあるかどうかを確認するために集計することが実用的かどうか疑問に思っていました期待された、または不満な経験ではなく興奮している。
ユーザーエクスペリエンスを評価するためのフレームワーク(たとえば、Googleの HEARTフレームワーク )の提案はありますが、これらのモデルは、キャプチャしたいユーザーエクスペリエンス全体を構成する実際のメトリックまたはコンポーネントまたはカテゴリへのマッピングを提供しません。カノモデルは、製品の機能と機能をユーザーエクスペリエンスの特定の側面にマッピングすることからの1つの出発点であり、残りのギャップを埋め始める他の方法を探しています。
問題は、ソフトウェア製品またはサービスの機能を3つのカテゴリーの1つに分類し、ユーザーが製品についてどのように感じるかについての値/メトリックを提供するために重み付けできるかどうかです。また、製品のライフサイクル全体でこれを追跡および監視して、ユーザーエクスペリエンスの1つの側面を提供することは現実的ですか?
短縮版:
はい、カノ分析を使用して、ユーザーが製品についてどのように感じているかについてのメトリックに到達できます。実際には、2つのメトリックですが、希望どおりではない可能性があります。
はい、製品のライフサイクルにわたってこのメトリックを再テストおよび監視することが現実的です。実際には、そうする必要があります。
長いバージョン...カップを手に入れ、快適な椅子に落ち着く...
問題は、ソフトウェア製品またはサービスの機能を3つのカテゴリーの1つに分類し、ユーザーが製品についてどのように感じるかについての値/メトリックを提供するために重み付けできるかどうかです。
ただし、それは大まかな指標であり、製品の可能性についてユーザーがどのように感じているかをより適切に表すことができます。
そして、それは実際には2つのメトリックでなければなりません。
カノモデルは、 Herzbergの2要素満足理論 のバリエーションです。これは、別の一連の要素が不満を引き起こす一方で、満足を引き起こす特定の要素があることを示しています。つまり、満足と不満は互いに独立して行動します。
ジェシージェームズギャレットを引用すると: "悲惨さの減少は喜びの増加とは同じではありません" 。
したがって、抽出する2つの指標は、満足度に対する全体的な影響と、不満に対する全体的な影響です。
これを1つのメトリックだけに蒸留しようとする場合、ベースラインと思われるすべての機能に少なくとも3倍の重みを付ける必要があります(別名 basic、必須、しきい値など) al )。否定的なことに与える3〜5倍の重み付けを正当化する研究への参照については、この TechCrunch記事 を参照してください。
また、すべてのベースライン機能が同じ程度の影響を与えるわけではなく、ユーザー数も異なります。カノ分析は後者を簡単に助けることができますが、前者はメソッドでのみ暗示されます。
各機能について追加の質問をして相対的な影響を評価するか、 選択ベースの結合分析 を組み込むことができます。ネットの重要度は、相対的な重要度にそのように感じるユーザーの割合を掛けることによって決定されるため、あなたが考えるほど重要ではありません。機能Xが本当に、本当に、本当に気の利いていると思う人が10%いる場合...機能Yがちょっと、ええ、ほとんど気の利いた人だと思う80%ほど、それほど重要ではないでしょう。
ただし、Kano Analysisのメトリックは、満足と不満の可能性のみを反映していることに注意することが重要です。モデルは、機能に対するユーザーの応答が機能の実行の度合いに応じて変化するという考えに基づいて構築されており、3つの主要なKano分類は応答ラインの形状を表します。
したがって、カノ分析から得られる分類とメトリックは、製品が実際にどの程度優れているかを示しません(それを取得するには、他の調査方法を使用する必要があります)。ただし、できることは他にもあるかどうかがわかり、適切に研究に集中できるようになります。
また、製品のライフサイクル全体でこれを追跡および監視して、ユーザーエクスペリエンスの1つの側面を提供することは現実的ですか?
はい。ユーザーのランダムなサンプルを調査することにより、カノモデリングの定量的データを収集し、定期的に収集して、そのように監視することができます(それが統計的サンプリングの美点です)。 毎回まったく同じサンプルを調査し続ける必要はありません。
調査の長さが気になる場合は、ユーザーのさまざまなランダムサンプルを調査することもできます。各サンプルには、特徴の短いサブセットがあります。もちろん、調査参加者の総数は増加しますが、個々に要求される努力はまだ低いです。各機能は他の機能とは独立して評価されるため、これはカノ分析で機能します。
また、時間をかけて調査する機能のセットを調整することもできます。たとえば、回答者の99%が機能Xは重要ではないと考えている場合は、単に機能について質問するのをやめます。また、チームが新機能の天才的なアイデアを思いついた場合は、それをミックスに投入して、他の機能とのマッピングを確認できます。悪臭を放つ場合は、早期に見つけて、それ以上のリソースを消費する前に削除することをお勧めします。
重要なことに、あなたはあなたの特徴の狩野分類を経時的に監視するべきです。 Kanoモデルの一部は、 Delighters として始まり、次に Performance になるフィーチャ分類が時間とともにドリフトするという事実を説明します/機能、 Baseline 機能として解決する前。
DelighterがPerformerになる時期を知りたいのは、モデルによると、その機能は満足感に貢献するだけでなく、不十分な実装が不満に貢献するためです。現在、機能を改善することが重要であり、単に全体的な満足度を高めるために単なる包含に依存するのではありません。 (カメラが組み込まれている電話に興奮していたときのことを思い出してください。カメラの電話はどれほどひどいものでしたか?カメラ内の電話はもはや楽しいものではないので、品質が必要です。)
同様に、機能がパフォーマーでなくなってベースラインになったとき、その機能を再配置したいと思います。それはもはやトランペットを鳴らすべきではなく、歌ったり踊ったりするべきではありません。必要なことだけを実行してから抜け出す必要があります。いまいましい方法。豪華なギフト包装はありません。
また、市場ランドスケープの特定の大きな変化がさまざまな機能の重要性に影響を与えているかどうかを確認する必要があります。特定の機能が、ある分類から別の分類へのドリフトを突然加速したり、単純に次の分類にジャンプしたりする場合もあります。例として、地政学的な悪党に目を向けてください。
最後に、私がカノ分析をどのように使用したかについて、いくつか例を挙げて説明します。
私たちは非常に複雑なオンラインアプリケーションを構築しており、機能要件の通常非常に長いリストがありました。絶対に必要な機能であり、後で遅延する可能性のあるハンドルを取得する方法が必要でした。
そこで、41の機能のリストを作成し、パネルサービスを使用して、狩野調査に45名の参加者を募集し、報酬としてかなりのインセンティブを提供しました。
数値を計算しましたが、これが結果です。
横軸は各機能の不十分な実装に否定的に反応する参加者の割合であり、縦軸は機能によってプラスの影響を受ける参加者の割合です。
灰色の点は、ほとんどの回答者が満足または不満のいずれについても重要であると見なしなかった機能です。機能のそのリストは、バックログにすばやくダンプされました。いくつかは境界線上にあり、私たちは後でそれらを監視しました。
青い点はベースライン機能です。ここでも、それぞれのコア機能のみに焦点を当てるように設計を簡略化しました。 ユーザーが私たちを憎まないようにするために何が必要ですか?
緑の点はパフォーマーの機能です。さらに注意を払う必要があるとわかっていたもの。それらはユーザーの基本的な期待に応える必要があり、そこからさらに改良することで満足のいく見返りが得られます。
黄色の点は、ほとんどの回答者が喜ばしいと見なした機能です。これらの機能は、設計を簡素化および縮小しました。また、ほとんどのユーザーは(定義により)他のディライターが欠落していることに気付かないことを知っていたので、ドロップデッドシンプルで真に差別化できるものを厳選しました。私たちが到達しなければならなかった基準はユーザーの注意を引くには何が必要ですか?
すでにマップから多くの価値を得ているため、すべてのデータを1つのメトリックに抽出することはしませんでした。非常に高レベルの戦略的指標が必要な場合は、( [〜#〜] nps [〜#〜] が高レベルの指標であるのと同じように) 。
これは小さくて短い運動でした。私たちは一連の利害関係者ワークショップとユーザーワークショップを実施しており、そこから新しいWebサイトの機能に関するアイデアのリストを作成しました。ご存知のように、小さなサンプルとグループダイナミクスを組み合わせると、ワークショップ参加者の熱意に頼って各機能の重要性を定義することができなくなったため、検証のために狩野調査を実施しました。
今回は ethn.io を使用して採用を行いました。私たちはクライアントサイトにJavaScriptをインストールし、3日以内に73人の資格のある参加者がいました。
これは分析のグラフです:
左下にある灰色のドットが見えますか?これは、ワークショップの全員がかなり気の利いた機能だと思っていた機能です。 computerはno と言います。
他のいくつかの機能の位置も、考えるための食べ物であることが判明しました。
たぶんあなたの質問への直接の答えではないかもしれませんが、私が何らかの価値を追加できると思います。とにかく、私は質問に対するいくつかのより多くの答えを見たいです。
「特定のユーザーが有効性、効率、および満足度を使用して特定の目標を達成するために製品を使用できる範囲使用する。"
基本属性、パフォーマンス属性、および興奮属性で製品の製品機能を区別する。
基本的な必要性を満たすためには、製品は効果的である必要があります。
例:タスクマネージャーアプリは私のタスクを保存できる必要があります
パフォーマンスの必要性は効率的なの方法で目標を達成したいという欲求かもしれません。
例:特注のタスクマネージャーアプリを使用すると、アプリのどこからでも2回クリックするだけでタスクを追加できます
excitementは、機能自体ではないかもしれませんが、satisfactionを増加させ、他の点では効果的かつ効率的な同様の製品との差別化要因となります。
例:タスクマネージャーは美しいデザインのUIを備えているため、使用するのが楽しいです
カノモデルは、製品に対するユーザーの満足度を評価するためのメトリックの表現です。満足度は非常に重要な指標ですが、ユーザーエクスペリエンスはその一歩先を行っています。歴史的な進化は、サービス品質->カスタマーケアと満足->カスタマーエクスペリエンスからです。 UX/CXは、ユーザビリティ測定、美的、感情的、認知的および経験的な全体的な概念です。つまり、ユーザーの満足度を測定することに重点が置かれている限り、カノモデルは適切です。ただし、ユーザーエクスペリエンスには、より多くの要素が必要です。そうしないと、モデルが混乱します。
「また、製品のライフサイクル全体でこれを追跡および監視して、ユーザーエクスペリエンスの1つの側面を提供することは現実的ですか?」
いいえ、確かに多くの機能があり、カノの状態を取得するには、それぞれに2つの質問が必要です。これは非常に長い調査であり、機能の満足度の現状を把握するためだけのものです。 UXは製品の価値と満足度以上のものなので、次のステップへの洞察を提供するメトリックの概念にあなたのエネルギーを投資することをお勧めします。
ISO/IEC TR 9126-3:2003は、内部測定基準(内部評価)を定義するために使用できます。あなたの用途に最適なオプションのようです。これは、UIが理解され、学習され、操作され、魅力的であり、ISOのユーザビリティ規制とガイドラインに準拠できる範囲を予測するために使用されます。たとえば、UIを次のような問題に分解します。
式は、全体的なスコアを生成するために使用されます。 Excelを使用でき、このテストを実行するのにUIの専門家は必要ありません。