用户研究 | The Kano Analysis 卡诺模型解析

今日当Medium看到同样首用研方法的牵线—— 卡诺模型(The Kano
Analysis)。
用于分析一个产品功效是否能如用户满意,这种方法的助益是会查获一个确凿的多寡结论,帮助决策。计算办法呢格外简单的,问卷操作也于便于简单,成本大没有。我本身特别爱这种能很快验证的低本钱措施,能以片的时跟人力资源条件下,也能快速得出可靠的多少参考和清丽的下结论。正使己落得亦然首文章介绍的法子同等,能大大提高沟通效率,减少无谓的斗嘴。本办法对职能的五种植划分为蛮有意思,让自身回忆锤子科技,锤子的无绳电话机便是专门强调软件达到的Delightful
Features而忽视任何硬件及之Required
Features。这就是恰恰说明了干吗锤子销量及咀嚼度无化正比。

原文我就是无都翻了,我才把关键之始末译生,由于Medium需要梯子,所以自己在征求作者同意的动静下将原先和粘贴在是。有楼梯的同学请点此传送。 

叫行为科学家赫兹伯格的复元素理论的启示,东京理工大学教授狩野纪昭(Noriaki
Kano)和他的同事Fumio
Takahashi于1979年10月登载了《质量之保养因素同激励因素》(Motivator and
Hygiene Factor in Quality)一柔和。

该措施将活功效区划为以下五栽:

Desired Features 期望功能 

当提供这功效,用户满意度会升级,当不提供这作用,用户满意度会落;

Required Features 必备功能 

当优化是意义,用户满意度不会见升级,当不提供这作用,用户满意度会大幅下跌;

Delightful Features 魅力功能 

用户意想不到的,如果不提供这作用,用户满意度不会见骤降,但当提供这功效,用户满意度会时有发生充分非常升级;

Indifferent Features 无差异功能

任由提供或非提供者功能,用户满意度都无见面生出改观,用户从不小心;

Anti-feature Features 反往功能

用户从都未曾这功效,提供后用户满意度反而会下滑。

艺术以问卷提问的法收集数据,最后通过数据整合得出一个功力的有数独系数:好听系数
Satisfaction Coefficient 
切莫满意系数 Dissatisfaction
Coefficient。要是满意系数过非惬意系数,该功能值得做。

以下是原文内容 Let’s Go:

The Kano Analysis

A Better Way Discover What Users Really Want From Your Product

by Brian
O’Neill

You’re on the design team for Crunchrr, a new app that helps users
discover cereals they’ll love. Users can:

– Create a profile and connect with others

– Discover cereals based on their preferences

– Rate and review cereals

Crunchrr is in the hands of some early adopters who are loving its core
features. Things are going great. That is, until the requests start
rolling in.

Annelise from marketing says: “Crunchrr needs a map view so users can
see where each cereal is made. People are really interested in where
their food comes from nowadays, so this is really a must! Besides, every
app has a map view.” Kevin from sales was at a meeting with a potential
advertiser who asks: “Where’s the chatbot? You can’tnothave a chatbot.
Conversational UI is the future!”

One of your early adopters pings you to suggest: “There should be a
button so I can email the cereal maker to request a gluten-free
version.” Another one says: “Maybe there could be something like Shazam
for cereal. That way, if I’m in a restaurant I can take a picture of
what the person at the next table is eating and it’ll show me what that
cereal is.”

The next thing you know, your backlog is a gaggle of suggestions,
requests, and demands. It seems that everyone has brilliant idea that
justhasto go into the next release.

This can’t be avoided. Everyone has an opinion and given the
opportunity, they’ll express it. And people easily fall into a “more is
better” mentality. More features equals a better product, and the more
of each feature, the better.

The obvious problem is that you can’t deliver on every request. Not only
that, but all ideas aren’t created equal, and users are often at a loss
as to how to articulate what they really want and need. On the other
hand, internal stakeholders tend to view features in the narrow context
of their own interests. How do you stop the madness?

“The most important thing that a team can do to help their design is
to say no to almost any idea for a feature”

— Jared Spool

You need a way to predict user satisfaction that lets you prioritize
feature releases and even re-evaluate existing features. And you need
hard data to support your decisions about what goes into Crunchrr and
when. That’s where theKano
Modelcomes
in.

The Kano Model

In 1984 professor Noriaki Kano presented a model that predicts how
satisfied people will be with a product based on its features. Since
then, the Kano Model has become a standard design tool because of how
effectively it can make typically invisible ideas about quality visible.
The core principle of the model is that satisfaction can be plotted
along five distinct
curves.[1]

Curve 1: Desired Features

Remember when I said more isn’t always better? Well,sometimesit is it
is. More storage space or battery life is better. Faster download
speeds? Better. These are all examples of where the user will usually
express greater satisfaction in direct proportion to how much of the
feature they get.

With desired features, satisfaction is directly proportional to feature
implementation

In the case of Crunchrr, desired features could be:

– Speed and responsiveness

– Number of users to connect with

– Suggestions based on stated preferences and past browsing behavior

– Options for quickly zeroing in on a kind of cereal (sorting,
filtering, etc.)

– Size of cereal selection

Curve 2: Required Features

Required features are the ones users expect and take for granted.

With required features satisfaction levels off once the basic need has
been met

Users are dissatisfied when a required feature is not present and
satisfied when it is. But that satisfaction levels off after a certain
point. This makes sense when you think about it. If a wheel doesn’t
roll, it will cause dissatisfaction. If it does roll, it will cause
satisfaction. But it’s hard to get anyone excited about a wheel that
rollsreally, reallywell. In the case of Crunchrr, as with most other
apps, this could mean things like:

– Reliable uptime

– Search

– Ability to create a profile

– Easy log in/out

Curve 3: Delightful Features

Delightful features are the ones that make an app fun to use and give it
a personality. They’re the features you love, but don’t expect. It could
be as simple as when the login form appears to shake its head when you
enter the wrong credentials. Or it could be the tone of the writing or a
fun mascot character or some unique interaction.

Users are satisfied with delightful features, but are not dissatisfied
when they are absent

As you can see from the graph, users express increased satisfaction with
delightful features. But there’s no dissatisfaction when they’re not
present. Also, as with required features, there’s a limit to just how
delighted a user can be. After a certain point, there are diminishing
returns. ­

Annelise’s map view is probably an example of a delighter because it’s
little more than eye candy, and it certainly isn’t solving any of the
currently defined business needs for Crunchrr.

Delightful features are an important part of the user experience, and
shouldn’t be ignored. Butthey come with a shelf
life,
in part because they’re so easily imitated. For a while, the swiping
interaction was a big part of Tinder’s unique identity. Now, Tinder is
justone of many
appswhere
users can swipe left or right. In other words, over time, delightful
features go on to become desired or even required features.

Curve 4: Indifferent Features

These are features the user simply doesn’t care about either way.
Whether they’re implemented fully or not at all, they won’t change
users’ opinions about the app, or change how they use it.

Neutral features don’t affect satisfaction one way or another

Curve 5: Anti-features

Anti-features are the features that users actively dislike.
(Remember Clippy?)
And the more these features are implemented, the greater the
dissatisfaction. Anti-features are like the mirror opposite of desired
features.

Anti-features are the ones that frustrate or annoy users.
Dissatisfaction is directly proportional to implementation

Putting it All Together

Looking at all of these features together not only provides a clear
pictorial representation of how features will be perceived, but also
helps you figure out strategic direction.

The complete Kano Model diagram

Desired Features:Resources should be invested heavily in these features,
because they are key to user adoption and retention, as well as
competitive advantage

Required Features:Resources should be invested heavily in these
features, but only until basic needs have been met.

Delightful Features:It’s fine to invest resources here, but not at the
expense of desired and required features. However, delightful features
are often key differentiators that can build loyalty and buzz.

Indifferent Features and Anti-features:Resources should be invested only
in identifying these so as not to waste cycles on building and
implementing them.

By now I hope you’re sold on the Kano Model. Then the next question is:
How do you find out which features belong to each category? That’s where
the Kano Analysis comes in.

The Kano Analysis

To find out which features belong where, we need to ask our users. But
remember, users are not usually great at identifying or expressing what
they really want and need. The Kano Analysis accounts for this by asking
questions in pairs: afunctional questionfollowed by adysfunctional
question. Let’s go back to Annelise’s suggestion of a map view for
Crunchrr. We could ask a question pair about this feature like this:

If Crunchrr let you see on a map where a brand of cereal is made, how
would you feel?

If Crunchrr did not let you see on a map where a brand of cereal is
made, how would you feel?

For both functional and dysfunctional questions, users must choose one
of the following answers:

– I like it that way

– I expect it that way

– I am neutral about it

– I can live with it that way

– I dislike it that way

You would prepare an entire questionnaire in this style for each of the
features in your backlog. Each user’s answers can then be analyzed by
plotting its outcome in the following table.

The analysis table tells you where a user would place a feature in the
Kano Model based on how the functional and dysfunctional responses
compare

It should be clear that if a user likes it when the feature is present
and dislikes it when it’s not, then that is a desired feature. The
designation ofquestionablehappens when the answers apparently contradict
each other. (This is often the result of the user not understanding the
question.)

Great. We’re almost done. The final piece is to aggregate all of the
survey responses to find the overall results for each feature.
(Alternatively, you could break this down even further and aggregate
responses based on personas.)

Coefficients

After you’ve aggregated all of the responses, you’ll calculate the
satisfaction and dissatisfaction coefficients. The satisfaction
coefficient is a number between 0 and 1: the closer to 1, the stronger
the influence on satisfaction. The dissatisfaction coefficient is a
number between 0 and -1: the closer the closer to -1, the stronger the
influence on dissatisfaction. We calculate the coefficients with these
formulas:

Let’s say that the aggregated responses for the map view breaks down
like this:

Desired: 5%

Required: 12%

Delightful: 4%

Indifferent: 23%

Anti-feature: 31%

Questionable: 25%

That would give you these results:

Satisfaction: (4 + 5) / (4 + 5 + 12 + 23) =0.2045

Dissatisfaction: (5 + 12) / (4 + 5 + 12 + 23) * (-1) = -0.3864

As you can see, the map view feature is having a significantly stronger
influence on dissatisfaction than on satisfaction. This clearly
indicates that we should leave it out of Crunchrr. Sorry, Annelise!
(Actually, if you saw these results in the real world, you wouldn’t even
need to calculate the coefficients. Seeing 31% anti-feature and 25%
questionable is enough to tell you not to include this feature. I used
these exaggerated figures to highlight the differences produced in the
coefficients.)

Other times, the coefficients will show little difference in influence.
Cases like those will require a judgement call or re-testing.

In Closing

A Kano Analysis is cheap and easy to perform and provides clear vision
into what users actually want and expect from your product. It also
provides hard data, which breaks everyone out of the trap of biased or
shortsighted thinking. There’s no need to argue and debate with internal
stakeholders about which features are in or out. The numbers don’t lie!

Brian O’Neill @brianeoneill is a designer in the San Francisco Bay Area,
currently at NVIDIA.

[1]These
curves go by many different names, depending on the source. I picked
these names arbitrarily. In the end, it doesn’t matter what they’re
called.

发表评论

电子邮件地址不会被公开。 必填项已用*标注