Building a Winning UX Strategy Using the Kano Model

[Ron Wheeler]

This video is about the strategy surrounding the user experience.
https://www.youtube.com/watch?v=Hr1rN3jibIk

There are a lot of ideas about how to use the Kano Model to determine
what features should be included in a product.
- There are features that are so basic that they do not show up in user
requirements - Accounts must balance; Orders should not be lost.
   These are typically expensive to include and if they work, you get no
user satisfaction but if they don't, you create a lot of user
dissatisfaction.

- There are features that users consider key to the performance of the
application and show up as "Features" in marketing docs and RFPs - good
documentation, search, multi-tenancy, support for eCommerce gateways, etc.
   These have a linear line from "few features, unsatisfactory user
experience" to "many features with great user experience"

- There are features that generate "the WOW reaction". They are not
expected to be there but users/buyers are impressed when they are.
   If they are not included, this does not generate dissatisfaction but
if they are there they generate user enthusiasm.

The trick is to know where each enhancement requested or suggested fits
in the space.

As time goes on, the "WOW" features move into the performance class and
eventually to the expected class.
For example, I can remember when touch screens were really exciting but
now a tablet or phone that only supports a keypad could hardly be sold.

One of the more interesting parts of the discussion is about why you
need a process for saying "No." to new features.
How do you keep a piece of software at exactly the right level of
complexity?

Enjoy.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[JulienNicolas]

Hello Ron,

It's really interesting, thanks!

Julien.

Le 20/11/2015 07:41, Ron Wheeler a écrit :

> This video is about the strategy surrounding the user experience.
> https://www.youtube.com/watch?v=Hr1rN3jibIk
>
> There are a lot of ideas about how to use the Kano Model to determine
> what features should be included in a product.
> - There are features that are so basic that they do not show up in
> user requirements - Accounts must balance; Orders should not be lost.
>   These are typically expensive to include and if they work, you get
> no user satisfaction but if they don't, you create a lot of user
> dissatisfaction.
>
> - There are features that users consider key to the performance of the
> application and show up as "Features" in marketing docs and RFPs -
> good documentation, search, multi-tenancy, support for eCommerce
> gateways, etc.
>   These have a linear line from "few features, unsatisfactory user
> experience" to "many features with great user experience"
>
> - There are features that generate "the WOW reaction". They are not
> expected to be there but users/buyers are impressed when they are.
>   If they are not included, this does not generate dissatisfaction but
> if they are there they generate user enthusiasm.
>
> The trick is to know where each enhancement requested or suggested
> fits in the space.
>
> As time goes on, the "WOW" features move into the performance class
> and eventually to the expected class.
> For example, I can remember when touch screens were really exciting
> but now a tablet or phone that only supports a keypad could hardly be
> sold.
>
> One of the more interesting parts of the discussion is about why you
> need a process for saying "No." to new features.
> How do you keep a piece of software at exactly the right level of
> complexity?
>
> Enjoy.
>
> Ron
>

[Jacques Le Roux]

Interesting indeed

Jacques

Le 20/11/2015 09:47, Julien NICOLAS a écrit :

> Hello Ron,
>
> It's really interesting, thanks!
>
> Julien.
>
> Le 20/11/2015 07:41, Ron Wheeler a écrit :
>> This video is about the strategy surrounding the user experience.
>> https://www.youtube.com/watch?v=Hr1rN3jibIk
>>
>> There are a lot of ideas about how to use the Kano Model to determine what features should be included in a product.
>> - There are features that are so basic that they do not show up in user requirements - Accounts must balance; Orders should not be lost.
>>   These are typically expensive to include and if they work, you get no user satisfaction but if they don't, you create a lot of user dissatisfaction.
>>
>> - There are features that users consider key to the performance of the application and show up as "Features" in marketing docs and RFPs - good
>> documentation, search, multi-tenancy, support for eCommerce gateways, etc.
>>   These have a linear line from "few features, unsatisfactory user experience" to "many features with great user experience"
>>
>> - There are features that generate "the WOW reaction". They are not expected to be there but users/buyers are impressed when they are.
>>   If they are not included, this does not generate dissatisfaction but if they are there they generate user enthusiasm.
>>
>> The trick is to know where each enhancement requested or suggested fits in the space.
>>
>> As time goes on, the "WOW" features move into the performance class and eventually to the expected class.
>> For example, I can remember when touch screens were really exciting but now a tablet or phone that only supports a keypad could hardly be sold.
>>
>> One of the more interesting parts of the discussion is about why you need a process for saying "No." to new features.
>> How do you keep a piece of software at exactly the right level of complexity?
>>
>> Enjoy.
>>
>> Ron
>>
>
>

[Ron Wheeler]

http://www.kanomodel.com/ has a short article with a graphic that shows
the relationship between the various types of product features.

Ron
On 20/11/2015 4:32 AM, Jacques Le Roux wrote:

> Interesting indeed
>
> Jacques
>
> Le 20/11/2015 09:47, Julien NICOLAS a écrit :
>> Hello Ron,
>>
>> It's really interesting, thanks!
>>
>> Julien.
>>
>> Le 20/11/2015 07:41, Ron Wheeler a écrit :
>>> This video is about the strategy surrounding the user experience.
>>> https://www.youtube.com/watch?v=Hr1rN3jibIk
>>>
>>> There are a lot of ideas about how to use the Kano Model to
>>> determine what features should be included in a product.
>>> - There are features that are so basic that they do not show up in
>>> user requirements - Accounts must balance; Orders should not be lost.
>>>   These are typically expensive to include and if they work, you get
>>> no user satisfaction but if they don't, you create a lot of user
>>> dissatisfaction.
>>>
>>> - There are features that users consider key to the performance of
>>> the application and show up as "Features" in marketing docs and RFPs
>>> - good documentation, search, multi-tenancy, support for eCommerce
>>> gateways, etc.
>>>   These have a linear line from "few features, unsatisfactory user
>>> experience" to "many features with great user experience"
>>>
>>> - There are features that generate "the WOW reaction". They are not
>>> expected to be there but users/buyers are impressed when they are.
>>>   If they are not included, this does not generate dissatisfaction
>>> but if they are there they generate user enthusiasm.
>>>
>>> The trick is to know where each enhancement requested or suggested
>>> fits in the space.
>>>
>>> As time goes on, the "WOW" features move into the performance class
>>> and eventually to the expected class.
>>> For example, I can remember when touch screens were really exciting
>>> but now a tablet or phone that only supports a keypad could hardly
>>> be sold.
>>>
>>> One of the more interesting parts of the discussion is about why you
>>> need a process for saying "No." to new features.
>>> How do you keep a piece of software at exactly the right level of
>>> complexity?
>>>
>>> Enjoy.
>>>
>>> Ron
>>>
>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Ean Schuessler]

There are some great ideas in this talk. I don't agree with the notion that
adding features is always a negative but an interface becoming too
complicated from feature bloat is a reality.

One idea we talked about some time ago was a notion of UICAs (User
Interface Condition Actions) that would allow for the insertion of UI
elements by components. This would allow a component to insert new buttons
and menu entries at engineered insertion points at various points in the
applications. These would allow a component like the Facility Manager to
insert its tabs in the catalog and so on but if facilities weren't needed
then those extra tabs would disappear.

The whole system could be trimmed back to a base platform with these
insertion points throughout it.

On Fri, Nov 20, 2015 at 3:32 AM, Jacques Le Roux <
[hidden email]> wrote:

> Interesting indeed
>
> Jacques
>
>
> Le 20/11/2015 09:47, Julien NICOLAS a écrit :
>
>> Hello Ron,
>>
>> It's really interesting, thanks!
>>
>> Julien.
>>
>> Le 20/11/2015 07:41, Ron Wheeler a écrit :
>>
>>> This video is about the strategy surrounding the user experience.
>>> https://www.youtube.com/watch?v=Hr1rN3jibIk
>>>
>>> There are a lot of ideas about how to use the Kano Model to determine
>>> what features should be included in a product.
>>> - There are features that are so basic that they do not show up in user
>>> requirements - Accounts must balance; Orders should not be lost.
>>>   These are typically expensive to include and if they work, you get no
>>> user satisfaction but if they don't, you create a lot of user
>>> dissatisfaction.
>>>
>>> - There are features that users consider key to the performance of the
>>> application and show up as "Features" in marketing docs and RFPs - good
>>> documentation, search, multi-tenancy, support for eCommerce gateways, etc.
>>>   These have a linear line from "few features, unsatisfactory user
>>> experience" to "many features with great user experience"
>>>
>>> - There are features that generate "the WOW reaction". They are not
>>> expected to be there but users/buyers are impressed when they are.
>>>   If they are not included, this does not generate dissatisfaction but
>>> if they are there they generate user enthusiasm.
>>>
>>> The trick is to know where each enhancement requested or suggested fits
>>> in the space.
>>>
>>> As time goes on, the "WOW" features move into the performance class and
>>> eventually to the expected class.
>>> For example, I can remember when touch screens were really exciting but
>>> now a tablet or phone that only supports a keypad could hardly be sold.
>>>
>>> One of the more interesting parts of the discussion is about why you
>>> need a process for saying "No." to new features.
>>> How do you keep a piece of software at exactly the right level of
>>> complexity?
>>>
>>> Enjoy.
>>>
>>> Ron
>>>
>>>
>>
>>

--
Ean Schuessler, Brainfood Co-Founder
[hidden email]
214-720-0700