Posted by jc-Qualitystreet on 2009/05/06
And a tool so valuable :
-
To understand user’s needs
-
To benchmark services
-
To identify usages
-
To prioritize your product backlog and your development
-
To drive your vision and your strategy
-
Or just to know your product.
The Kano model has almost 25 years … but you can still easily apply it to your own Projects (IT or not).
The strengths of the model : simplicity, and the user feedback (questionnaire).
Thus, the Kano model is both a precious User Centered Design tool and a precious decision-making aid tool.
The Kano model seeks to connect requirements (response to needs, product attributes) and customer satisfaction, and classifies 3 types of requirements, that will influence the final customer satisfaction. Very useful and very efficient.
Must Have ( « Basic needs »)
These basic requirements are not always expressed but they are obvious to the customer and must be met. If you don’t do it, « you’re dead ! »
These requirements are not a source of satisfaction but can cause major disappointment. They’re not the priority in term of development but must be there the D day.
E.g. brakes of a car; a bed in a hotel room …
Performance needs (« Linear »)
The need is expressed and customer satisfaction is proportional to the level of performance (and quality) of what is implemented. It is a strong source of customer satisfaction and a priority for Development.
It must be shown as soon as possible to the Users.
User feedback on these functions is crucial.
Delighters ( « exciters « )
These requirements are not necessarily expressed. Sometimes they’re unconscious.
This is the happy surprise that can make a difference, and an important source of satisfaction. If not there, no dissatisfaction, no frustration: they’re not expected.
Thus in terms of development, they are usually not a priority, except if it is your product or firm strategy.
E.g. The glass of champagne when you arrive at the restaurant, the wifi on the plane or in your hotel room, the mobile touch screen…
Exciters are the keys to Innovation.
Obviously, the model is not fixed and a specific function tends to go to” “the Must have”). The mobile world is the perfect illustration.
HOW DOES THE KANO MODEL WORK ?
The model is very simple: select a representative panel of users (20 … 30), pass them a questionnaire, analyze the responses and make the right decisions.
Step 1
Survey users (mostly by questionnaires) on each function through a pair of questions (functional and dysfunctional)
Functional question : « How would you feel if the product had feature X ? »
I like it
I expect it
I’m neutral
I live with it
I dislike it
Dysfunctional question : « How would you feel if the product didn’t have feature X ? »
I like it
I expect it
I’m neutral
I live with it
I dislike it
Step 2
Analyze responses for each function and each user questioned.
You have 6 possible categories (I = Indifferent; Uncertain Q = R = Reverse, and the top 3)
Step 3
Communicate final results for each function :
-
The function x is a « Must Have »
-
The function is a need expressed « Linear »
-
The function z is a requirement attractive « Exciter »
…
Posted by jc-Qualitystreet on 2009/01/23
Use cases and user stories are two popular ways to capture functional requirements. They’re both goal-oriented (a very good thing), can be discovered during user / customers workshops, can be easily combined with UX activities, and are used in Agile contexts.
Use cases and user Stories look similar; actually, they’re different. Here is the list of 14 major differences I’ve observed:
- A user story is a brief description of functionality as viewed by the user (Role → Goal); it doesn’t model the interaction between the actor and the system, what the use case does. A user story is not a sequence of actions.
- A user story is short and consist in one or two sentences written in the language of the user (example: As a recruiter, I can submit job vacancies). A role and a goal, then it is discussed. A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.
- A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension
- User stories are used for planning. They play a major role in project estimation and planning (via story points and velocity). Use cases are not used for planning, even if you can use « use cases points » technique to estimate project size.
- User stories emerge faster than use cases; use cases require more time for analysis and writing
- User stories are more readable than use cases; use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template
- User stories are easier to maintain than a 150 pages Use cases Document
- User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details. Use case is a textual model (associated with diagrams): every thing is written !
- User stories are in theory written on cards (remember the 3 C rule: Card, Conversation, Confirmation): they’re not intended to be archived unlike use cases.
- A user story must be implemented and tested in one iteration; a specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …
- User stories can be more easily written by a user or customer; most of the time use cases are written by user proxies (BA, Consultants …)
- User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation
- Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !
- Finally, Use cases and user stories were originally associated with two different methodologies (Unified Process vs eXtreme Programming). But both can be used with agile methods and unified process !
My preference:
I have almost a ten years experience with use cases. Alistair Cockburn’s book « Writting effective use cases » used to be my bible for years… but now, my preference tends to go to user stories model. And this is usually my recommendation to Agile Teams.
Why ?
- User stories focus on what is really important
- User stories are more appropriate for collaboration
- User stories can perfectly be combined with UX activities (Personas, Storyboard, Wireframes):
User stories + UX artifacts = Just enough
Posted by jc-Qualitystreet on 2009/01/08
Tell me and I’ll forget
Show me and I may remember
Involve me and I’ll understand
A Chinese quote and a principle that we should apply everyday on our projects. So encourage good learning, seek maximum cooperation, stimulate interactions, raise the feedback… ENGAGE clients and stakeholders in order to make our intervention really valuable !
Posted by jc-Qualitystreet on 2009/01/07
My name is Jean Claude Grosjean. I am a consultant and an Agile coach.
User Experience and Agile methods are my interests, those I want to promote through this blog.
French readers can still folow me on Qualitystreet.fr (Ergonomie, Experience Utilisateur et Methodes Agiles) and Ux-mobile.com (Pour une expèrience Mobile réussie).
