デザインチームは、製品に対するユーザーニーズのリストを思いつきます。 エンジニアリング チームは、異なる機能のセットを持ってテーブルに着きます。 経営陣は、会社を儲けさせるような機能だけを欲しがります。 サポートチームは、修正すべき機能をまったく別に考えている。
デザイン研究者として、私たちは顧客の言動に依存し、顧客が何を望んでいるかを深く読み解くことができます。 しかし、私たちの多くは、これらのチームが一致するために、効果的な方法でそれらのニーズを定量化および視覚化する新しい方法についてしばしば苦労してきました。 顧客は確かに機能に対して投票し、ランク付けすることができます。これは素晴らしい概要を与えますが、すでに期待されているものよりも、何が必需品であるかという深い理解を常に与えてくれるわけではありません。
Kano modelとは1980年代に加納典明教授によって考案された製品開発と顧客満足に関する理論で、顧客の好みを5つに分類しているものである。 各特徴について、満足度とセンチメントの2つの尺度を評価することで、製品の特徴に対する顧客の視点を理解するための手法を提供している。 この2つの尺度に対する回答は、5つのカテゴリーのいずれかに分類される。 魅力的、性能、無関心、必須、望ましくない。
使い方
各特徴を個別にリストしたアンケートを作成します。 各機能について、可能であれば、プロトタイプまたはインタラクティブなワイヤーフレームを通じて、その機能ができることを示すのが理想的です。 このためのプロトタイプ作成に多くの時間を費やしてはいけません：アイデアを伝えるためのプロトタイプに過ぎません。 プロトタイプでも細部にこだわる人がいます。アイデアは気に入っていても、それがどのように実装されたかは気に入らないからです。
もし機能のデモが不可能な場合は、説明用のテキスト説明もうまく機能するでしょう。
プロヒント：他の IBM 研究者との議論で、より成功していた人たちは 15～20 の機能をテストしていました。 成功しなかった人たちは、30～40の機能をテストしました。
各機能を見た後、ユーザーは Kano アンケートへの回答を選択します。
- If you had (feature), how do you feel?
- If you didn’t have (feature), how do you feel?
（ダニエル・ザカリアスが、これらの質問をわかりやすく書くための優れた指摘をしています）
上記の2つの質問に対する標準的なカノンのアンケート回答は、次のとおりです。
- 好き
- 期待する
- どちらでもない
- 我慢できる
- 嫌い
またDaniel Zacariasはこれらの回答のための回答セットにいくつかの他の選択肢を提供しています。 基本的に、もしあなたがKanoモデルを試そうとしているのなら、彼の記事全体を読んでください。
Jan Moorman も、3 番目の質問を追加することを推奨しています。 この機能はどの程度重要ですか？ 彼女は、「まったく重要でない」から「非常に重要である」までの9段階のリッカート尺度を使用することを推奨しています。 しかし、重要度を表す9段階のリッカート尺度を綴ろうとすると、……ちょっと厄介なことになるのです。 7764>
答えが出たら、ダニエル・ザカリヤスが非常に詳しく説明している分析プロセスがあるんだ。
IBM の研究者が発見した 1 つの問題は、これらの数字を持つことは素晴らしいことですが、数字そのものは誰にも理由を教えてくれないということです。 あるチームは、Kanoモデルを使って約15回の定性面談を行いました。 別のチームは、40人からアンケートを取った後、5人の定性面談を行いました。 両チームとも、データに不足している文脈を与えるのに役立つ物語を追加するため、このプロセスに定性的なインタビューを加えることを強く推奨しました。 このチームは、機能を説明するために、物事が機能する現在の方法であると彼らが信じるシナリオを使用してアンケートを設定しました。 しかし、テストが進むにつれて、設計チームのシナリオは顧客が実際に製品をどのように使用したかを反映していないことが非常に早く明らかになり、テストはすぐに脱線しました。
機能を説明するためにシナリオを使用するというアイデアは良いのですが、彼らのアプローチを議論するにつれ、シナリオは事前に検証されなければならないことが明らかになりました。 加納＋シナリオの組み合わせは、現状を確立するジェネレーティブリサーチの後に威力を発揮するでしょう。
もう1つのアドバイスは、テストする機能の数を減らすことでした。 30～40の機能の長いリストを引き受けたチームは、少し集中しすぎて、テストが終わるころには顧客が圧倒されて疲れ果ててしまったと述べています。
Benefits
Kanoモデルは機能の優先順位付けに非常に優れています。 Kano モデルの根底にある理論は、Daniel Zacarias が “喜びの自然な減衰” と呼ぶものです。 革新的なアイデアや製品は、Kano チャートの一番上にある刺激的で新しいもの (魅力的) から、一番下にある期待される機能 (よく言えば必需品、悪く言えば難点) へと移行します。
無線インターネットを例にとってみましょう*。 2001 年、あなたは仕事で旅行中で、イーサネット ポートと WiFi を備えた最高級のラップトップを持っています。 ホテルで、インターネットに接続するためのイーサネットポートがあることを知ります。 宿泊料金に無線LANは含まれていませんが、ビジネスセンターでWiFiを利用することができます。 大喜びです。 すごいですねー。 なんて素晴らしいオプションだ！
Fast forward to 2017. あなたは仕事で旅行中で、WiFi が使える基本的なラップトップを持っています。 ホテルに宿泊し、インターネットに接続するためのイーサネットポートがあることを知ります。 宿泊料金に無線LANは含まれていませんが、ビジネスセンターで無線LANを利用することができます。 怒り心頭です。 インターネットに追加料金を払わなければならないなんて、このホテルは一体どこの惑星から来たんだ!
最初は魅力的な機能 (部屋のイーサネット ポート、ビジネス センターの WiFi) であったものが、16 年後に望ましくない機能になってしまったのです。 Kano モデルを使用した IBM の研究者のひとりは、自分のチームでこのことを指摘しました。 チームがとても楽しみにしていた機能があったのですが、それが “出る杭 “であることに気づいたのです」。「
さらなる可能性
私たちは Kano モデルについて議論する中で、このモデルには他にもいくつかの可能性があることを理論的に示しました。
- Gauging the depth of pain points
- Baselining features over a product lifecycle to assess the natural decay of delight over time
Depth of pain points
This model could help to reveal how bad existing pain points are ⧏35⧐ 既存痛点の悪化の程度を明らかにするのに役立つかもしれません。 加納式アンケートは、疼痛ポイントがなぜこれほど悪いのか、なぜこれらの機能が顧客にとってそれほど重要なのかを知るために、調査を深く掘り下げることを容易に可能にします。 7764>
機能のベースライン化
私たちは、Kano モデルを使って定期的に機能を評価し、どの機能が下位のカテゴリに格下げされているかを観察することを話し合いました。 この種の長期的なテストは、十分な数の顧客ベースがあれば、市場のトレンドと期待を示し、長期にわたって研究価値を証明し続けるのに役立つでしょう。 7764>
公開質問状
IBM のデザイン チームは、プロジェクトのコンサルタントとして活動することがあります。 IBMの一部のデザイン チームは、「ユーザビリティをきれいにする」ためにプロジェクトに参加し、発売直前の製品に魔法のUXの粉を振りかけるように依頼されます。
私たちは、議論の最後に1つの未解決の質問を残しました：製品に影響を与えることができない場合、Kanoモデルは有用ですか？ 製品がすでに開発中であったり、経営陣の反発があったり、設計チームが一時的に製品チームの一部であったりするために、製品に影響を与えることができないかもしれません。 Kano モデルを使用する努力をする価値はありますか。
それとも、製品に影響を与えることができなくても有用ですか。