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/02/13
Forget SCRUM failure debate for a minute…
What is really working on Agile projects ?
What kind of activities enable your team to deliver as fast as possible an outstanding product ?
Well, I’d say SCRUM; I’d say SCRUM practices but not only…
SCRUM is (too) popular now: latest statistics (2008) from Version One show that 71 % of agile teams are using it, with or without XP.
Great ! SCRUM is the best framework for project collaboration. It is also a simple process based on feedback and adaptation, ensuring high visibility and velocity.
SCRUM respects people and seeks to provide the highest value to the customer through powerful and mature practices: Integrated Team, Daily Scrum, Retrospective, Iteration planning, Short Iterations, Information radiators…
SCRUM is for sure the agile foundation of your projects, but this fantastic framework doesn’t cover everything :
- No recommendations on User Experience, Agile testing, Development practices, all so crucial on IT projects
- Partial and insufficient recommendations on Process Improvements and Cultural Changes (organization level)
My conviction : ADDITIONAL KEY ELEMENTS are required to succeed (their relative importance is contextual and depends on the nature of the project):
- User Experience activities (Interaction Design, Usability, Information architecture have proved their efficiency to support Team work and to facilitate project progress); and UX is directly linked to business value !
- Appropriate Agile Testing strategy, based for example on Brian Marick, Agile testing Quadrants (a great model)
- Lean thinking (Long term Philosophy and other management principles from the TPS or LSD, eliminate waste, amplify learning, deliver fast, …) applied to processes and organization
- XP Development best practices (still extreme in 2009?)
Anything else for you ?
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/18
12 best practices compiled by Jeff Patton that have proven their efficiency with multiple teams.
Here is the list of the emerging practices with a quick review.
1 Drive: UX practitioners are part of the customer or product owner team
MUST User Experience activities support analysis and prioritization tasks carried out by of the Product Owner (scrum) / Client (XP). This can go up to write User Stories and even play the Product Owner role. This position does not harm our cooperation with the development team. In one of my recent projects, we had a Product Owner Team (speaking one voice) working with the UX consultant to facilitate understanding and putting User Stories into context.It was very efficient.
2 Research, model, and design up front – but only just enough
MUST Sprint 0 offers us a good opportunity to do our job, but timeframe is diiferent … UX must go straight to the point: personas, quick modeling…Sprint are short (2, 3 or 4 weeks) and people expect expertise from us.
3 Chunk your design work
MUST No choice but not an easy thing. During the first iteration, it is a real difficulty.
4 Use parallel track development to work ahead, and follow behind
MUST It is a real challenge but it is also the most exciting part of the job in an Agile context. During a specific iteration (n), UX practionners have to:
- design the content of next iterations (n+1, n+2)
- collaborate with developers on the current iteration
- evaluate results of the previous iteration (n-1)
5 Buy design time with complex engineering stories
CAN Very contextual.
6 Cultivate a user validation group for use for continuous user validation
CAN It helps and it is great if the pool of users is the target (but the pool must be large enough). It could be also a way to initiate change…
7 Schedule continuous user research in a separate track from development
CAN A question of time and resources but impossible if there is only one UX guy in the organization…
8 Leverage user time for multiple activites
SHOULD OK, but do not forget that visiting users for nterviews, questionnaires, card sorting, screen reviews requires time for preparation, analysis and restitution…
9 Use RITE to iterate UI before development
MUST Feedback and adaptation are the keys. Teams do not want to wait; they don’t care about a formal and standard usability testing reports.
10 Prototype in low fidelity
MUST Paper, PPT, Visio, whiteboard … everything is OK if you give value to the team and the project.
11 Treat prototype as specification
MUST Always ! High level Storyboard + User Stories + Wireframes : a magic potion
12 Become a design facilitator
MUST It is my conviction : facilitation is the future of our profession !
Posted by jc-Qualitystreet on 2009/01/14
Bad Usability Calendar 2009 from Netlife Research is available for download.
I like very much February, May and October, but all are relevant …
