今天当Medium看到同样篇用研方法的牵线—— 卡诺模型(The Kano
Analysis)。
用以分析一个成品功能是否能使用户满意,这种方法的长是能得出一个如实的数目结论,帮助决策。计算方法吗死简单的,问卷操作也比容易简单,成本非常没有。我我特别爱这种能很快验证的不如本钱措施,能当少数的时刻与人力资源条件下,也能够迅速得出可靠的多少参考和鲜明的定论。正使己上同首文章介绍的方同样,能大大提高沟通效率,减少无谓的争吵。本方对效益的五栽划分为蛮有意思,让自家想起锤子科技,锤子的手机便是特别强调软件达到的Delightful
Features而忽略任何硬件及之Required
Features。这即刚刚说明了干吗锤子销量与体会度无化正比。

“姑娘,今天失去跑了呀?你可是真的厉害!”北马终结的那天,我拖在半残的腿回到女人,电梯里赶上同样各项老爷爷看本身穿越正“北京遥远”的参赛服,这样问我。我万分认真的触发了接触头,随后倒来电梯,留下老爷爷饱含欣慰的秋波在身后。

原文我不怕无统翻了,我只是将重要的情节译生,由于Medium需要梯子,所以自己以征得作者同意的情下把原先和粘贴于此。有楼梯的同校请点此传送。 

今离开9月17日都久远都仙逝了十几龙之时空,但北马底余热还没散去。最近之各一样天,基本上跟之交谈的每个人,微信上挂钩的每个人且为此一般的句式和自我打招呼:

为行为科学家赫兹伯格的对因素理论的迪,东京理工大学教授狩野纪昭(Noriaki
Kano)和外的同事Fumio
Takahashi于1979年10月发表了《质量之调养因素同激励因素》(Motivator and
Hygiene Factor in Quality)一平和。

恭喜你呀,懿铭,成功完赛北马。

拖欠办法将活功能分为以下五栽:

什么,我的世界里每天都飘在五彩缤纷的气球。我思了跑了北马会有多勿等同的体验,但从不悟出会出如此多幸福之蝴蝶效应。而实质上,北马带来为我之远远不止这么。

Desired Features 期望功能 

当提供这功能,用户满意度会提升,当不提供者意义,用户满意度会下跌;

有人说,跑步是和活本身最接近的隐喻,它于众人又温习如何学习周遭、订立目标、训练、实战,再总结重新出发。

Required Features 必备功能 

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

过去眼看句话对自己吧恐怕仅仅是同一句冠冕堂皇的心灵鸡汤,现在,跑了北马之我,对就句话出矣初的体味和体验。

Delightful Features 魅力功能 

用户意想不到的,如果不提供者功能,用户满意度不见面降低,但当提供者意义,用户满意度会有酷老升级;


Indifferent Features 无差异功能

无论是提供或不提供这作用,用户满意度都非见面产生变动,用户从不留意;

6个月前,我或一个无限远距离只走了15公里的跑渣。隔三两样五走5公里就权当在减肥塑形道路达倔强的坚持不懈了。用30分钟跑5公里,时间不长不短,呼吸、心率、步频、步幅这些名词也不曾以自我的觉察里逗留了。

Anti-feature Features 反为效应

用户向还没此意义,提供后用户满意度反而会落。

方以问卷提问的方法募集数据,最后经过数量做得出一个效能的点滴只系数:如意系数
Satisfaction Coefficient 
未如意系数 Dissatisfaction
Coefficient。假设满意系数过非顺心系数,该功能值得做。

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

5只月前,我之好闺蜜Ruixin拉在自家一块到的首都长跑节(半马),报名的当儿自己没有感念了21公里和平日的5公里有多良之区别,只是单纯的觉得坚持跑至极限就顺风,实际上马拉松没有是一个粗略的事务。参加北京长跑节之前,我太丰富之距离只有跑过15公里,我于是15公里之训距离与了第一不善半程马拉松。

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.

1单月前,我于好闺蜜Ruixin的唆使下申请了北马,那时候我莫亮用到北马的号码牌是一律码多难以的从,作为中国田径协会市场化程度最高、规模极充分、最有代表性的竞,近10万人数申请的状态下,最后就生3万人足以到参赛权。而自也侥幸的中签了。一个尚未全程马拉松官方赛事成绩的人口会受到签北马,凭借的毕是天机。

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

面临签这起事对自己只是好打,茶余饭后也不时让人评说运气实在好。同样的,我非顶42.193公里的赛道意味着什么,无知者无畏说的约就是本身这么的总人口吧。但随着给自己完赛北马发生意见的人头越发多,我才发现及及时不是一个简便的娱乐。

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

有人说:过去而2.5钟头可跑了半马,剩下的一半全都负移动,是可以顺完赛全马的。

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

有人说:加油,我深信不疑你4小时得得走了马;(惊呆脸)

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

应有尽有的声都来,但我知了一致项事,赛前的正确训练得使产生矣。于是,隔天一软的健身房力量训练+10公里跑就成为了我之训练计划,这样坚持了大体上只月的流年,每次飞了5公里还面对不改色心不跳地挥发为10公里之时节,我体会到了训带来的体能改变。在一个岁月充裕的星期天,我当形成同样钟头力量训练后,一不小心跑了25公里,竟也无觉得十分懒。我的教练听说这起事后说,那你完赛全马毫无问题了。

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.

教练就是依照人说了当下句话,却为了自身大的信念,我先是蹩脚针对全马的完赛时间来矣预期,我之所以2.5钟头跑了半马之成就乘以2,再加上30分钟之余量时间,5时30分钟是自个儿完赛全马的对象。

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.

9月17日同大早天还未曾显示,去为天安门之地铁里即使挤满了穿在“北京漫长”参赛服的人,我看收获每个人心里都抑制非鸣金收兵的震撼,还有不少及自身同样第一次到北马、第一软走全马的健儿。

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.

只好说,从中签到完赛,我出了死频繁令人鼓舞的经验,但极致打动之都比较无了从跑前3万号称参赛选手在天安门面前一起唱国歌的一念之差于还我当自豪和荣耀。那是相同栽时想起都见面当内心雀跃的骄傲和震撼。


7:30,发令枪响,因为自以F区从跑,等我专业通过起点时一度7:50分开了,不过没什么,我再次同次等经过天安门,沿着长安街启了还要同样次于马拉松了,这正如什么还主要。

得益于赛前一个大抵月的教练,前21公里之奔走对自吧基本无感觉到压力,我竟然还惊奇这么快、这么轻松就走了一半了。直到30公里时,开始体会传说被之“撞墙期”,于是只好用走+跑成的不二法门,赛程中出很多志愿者和考察群众在为参赛者加油,每一样句“加油”我还听的清晰,我呢见到有人中途席地休息,有人以腿抽筋不得不停止比赛。在极度折腾的30公里处,为了更换注意力,我开回忆过去在里的种,我再三问了和睦简单独问题:

今昔底痛苦,痛得过第一坏失恋吗?

当今的磨难,比得过大住院的季只月也?

自身懂,过去的痛是真正,现在吧是。

我了解,过去的磨难是实在,现在吗是。

可自身还清楚,所有痛苦与折磨,都见面过去。

即使这样,我飞至了34公里处。在此间我看出了飞团里的亲属,见到了我之好闺蜜Ruixin,她吃了自己同就葡萄糖和一个大大的搂抱,我还要再度赶回了赛道。

剩下的赛程,我之记忆里只有剩下了太阳之暴晒和过剩的加油声,双腿在机械式的行路,有力气就走,没力气就动,就这么走至了终点。如我所预期的平,到达极限的那一个,所有的惨痛与折磨都成为了他人的故事,我好像只是看了相同场紧张的录像。

在本人之记事本里,写在这么一句话,我一直挺爱:

“马甲线只是如出一辙种历练身体、挑战意志、自律生活的开始,我们换得早睡早起,吃得精,我们学会专注以及坚持,马甲线是这种全新的存的糖衣炮弹,但大餐还于后,它们是丰富腿、是蜜桃臀、是脊柱沟,甚至是平等庙会半马、一庙会全马。”

2017年9月17日,我做到了人生之率先次等全程马拉松,计划成530,完赛成绩516。历练过身体、挑战过意志、学习着约生活的自身,可以欣慰理得的以全马后面打一个招了。

与其说人生是时时刻刻挑战自己的长河,不如说是去解锁更多有意思的事体的经过,人生来那多的好等正咱,去玩,去野,去跑,去发现。

若你开玩笑,去跑步吧。

要你切莫开心,去走步吧。