Discovering the Table Stakes and Delighters

For years, user researchers have struggled to identify what product features will both accomplish users' goals and truly bring out delight. This week Jana Sedivy introduces a combination of the Kano method and outcome driven interviews to find those elusive delightful features.

Henry Ford is famously misquoted as having said “If I’d have asked customers what they wanted, they would have said ‘a faster horse.’” Yet the sentiment is true: users tend to limit their imaginations to their own paradigm. They have a natural tendency to think of features that provide incremental benefits, such as more storage space, faster speed, or more configuration options. But focusing exclusively on those features will result in only moderate improvement, and never reach awe inspiring heights. Designers can mitigate this risk by using a combination of Kano Model and outcome driven interviews to probe for features that will truly delight customers.

A big part of user research is discovering users’ requirements. After conducting many discovery interviews, I began to notice that my subjects didn’t see all product features equally – and yet the less discussed features were not the least important. Some features were taken for granted and never mentioned because people would be shocked if they were not there. Others were not mentioned because they were not expected, but people would still be delighted by their presence. I began to look for explanations of this phenomena and ways of coaxing the necessary information out of interviewees – to ensure the product we created would both meet expectations, and delight.

My search took me out of the UX world and into the world of business analysts and economists. I discovered the Kano model of customer satisfaction, and outcome driven interviews by Anthony Ulwick. The Kano model provided an explanation for what I was observing, and outcome driven interviews provided a foundation for getting the data I needed. Together they form a powerful combination.

The Kano Model

Developed by the economist Noriaki Kano, The Kano Model is a model of product development and customer satisfaction. It identifies three types of features defined by the level of customer satisfaction they instill. These features are called table-stake features, incremental features, and delightful features.


  1. Table-stake features are the “must have” features, those that users have come to expect. Although they do not create customer satisfaction by their mere existence, customers will be very dissatisfied if they are executed poorly. For example, a cell phone that doesn’t drop calls merely acts as expected, but a phone which does drop calls fails to meet the basic expectations of what it should do. These things comprise a product’s ambient experience.
  2. Incremental features are those of which “more is better.” They include things like memory, speed, higher definition, etc. Continuing on our cell phone example, a phone with more memory makes users more satisfied. In general, when customers talk about the features they want, they are referring to incremental features.
  3. Delighter features are those that customers do not expect. Accordingly, no one will miss them if they are not implemented. However, their presence creates a great deal of customer satisfaction. For example, the first iPhone introduced the pinch-zoom capability. This was not something that customers felt they were missing, but early users of the iPhone were delighted with this unexpected new feature.

Delighter features tend to become commonplace over time. As competitors begin imitating the original innovators, delighter features gradually become incremental features, and eventually even table-stakes.

Kano Model

Image from Baymard

All three of these feature types are important. However, when soliciting feedback from users, particularly in an anecdotal “tell me what you want” discussion, it can be almost impossible to identify table-stakes and delighter features. Table-stakes are too obvious and delighters are too-good-to-expect, so users don’t think to mention them.

From theory to practice

The question becomes: how can we uncover the elusive table-stakes and delighters? The method that Kano himself proposed is to create a specialized questionnaire. However, there are some problems with this methodology: namely, respondents are notoriously bad at self-reporting their preferences, and research indicates that Kano’s specialized questionnaire does not reflect actual purchasing decisions.

Another limitation of Kano’s questionnaire is its focus on features over goals. As many user-centered designers already know, users don’t think about features. They care more about achieving their goals. For example, in a product for helping with corporate conference calls, some proposed features might include:

  • Automatic one-click dialing into a conference call from a smartphone, based on the information in the calendar invite.
  • One click connection to a conference from the calendar invite from on a desktop computer using a VOIP soft client.
  • Conference dial-in information automatically appears in the meeting reminder.
  • However, none of these come up when asking a user “what do you want during your meetings?” What does come up is the goal: “I want to reduce the time I spend dialing into meetings.”

    With this in mind, we can adapt the Kano method to encompass goals: when designers are reviewing features, they should connect each feature they are considering to a pre-specified user goal. If the team cannot easily come up with a user goal that answers “why” we need the feature, it should probably be dropped.

    Getting to the data

    Anthony Ulwick’s method for outcome driven innovation interviews is a great technique for getting data about underlying goals rather than features. However, it does not consider the distinction between table-stakes and delighters that the Kano model articulates so well. With that in mind, I adapted Ulwick’s methodology into a two-part interview in order to tease out Kano’s categories.

    The first half of my two-part interview is very similar to Ulwick’s original outcome-driven innovation interviews. Its primary purpose is to identify important user goals that are currently not well satisfied. Here is how it works:

  • Researchers begin by constructing a list of hypothetical goals; that is, aspirational statements around which our product might be built. Again, these statements should not be about features. A good rule of thumb is to incorporate the words “reduce” or “maximize,” such as: “reduce time spent dialing into conference calls.” If participants begin to talk about features (“I want to maximize the meeting invite by including the dial-in information”), ask them what they are hoping to accomplish, to help them identify the bigger picture goal. If the design team has developed personas, a different set of goal statements is usually relevant for different personas.
  • For each goal, ask the interview participant to rate it on a five point scale along two dimensions: importance and satisfaction. The importance dimension quantifies the value of this particular goal, with 1 being very important and 5 not at all important. The satisfaction dimension indicates how they feel about their current solution, with 1 indicating very satisfied, and 5 meaning not at all satisfied.
  • After the participant has rated each goal statement, researchers can probe for details. Ask open-ended questions such as “it’s interesting that you rated x as important as y. Tell me more about that.” and “How do you currently accomplish that?”
  • After completing the list of goal statements, ask if there are any additional goals. This ensures that anything that might not have been in the list of goals will still be captured.

Overall, the purpose of this interview is to identify goals that are extremely important but very poorly satisfied. If something is important but people are satisfied with how it works now, it is not a pain point for them. Likewise, if something is not important and poorly satisfied, it doesn’t need to be addressed.

Designers often notice surprising patterns during this process. For example, it not uncommon for people to rate something “hmm… about a 3” in satisfaction and then, when pressed for details, to describe a horrible, convoluted and incredibly painful process. Most people are “moderately satisfied” with the majority of their goals. This is typical and is called a “normal distribution” in the world of statistics. This is why the next step in the process is to amplify the differences.

Getting Crafty

The second half of the interview amplifies the differences between each user goal and separates them into Kano’s three aforementioned categories: table-stakes, incremental features, and delighters. This is the part where participants get to be more hands-on.

Before the interview, in preparation for this second half, the researcher must print out each of the goal statements, and tape or glue each one to a index card. The researcher should also bring along some blank index cards to add any additional goals generated during the first half of the interview (see below).

Sample goal statements

The interviewer then hands the participant the stack of cue cards with instructions to choose five cards that they consider essential to the product. Even if the product is not fully defined yet, the interviewer can provide the participant with enough information to understand the purpose of the product. For example, the end product might be defined as“a system for sharing files” or “a system for managing your sales force.” The cards the participant chooses as “essential” to the product are the table stakes.

After the participant has chosen their cards, the interviewer conducts a dot voting exercise, giving the participant 10 sticky dots to distribute among the five chosen cards. These dots indicate the relative importance of each item. A money metaphor is often helpful here. The participants can think of each dot as $100, and they are distributing how much they would be willing to invest in each of their 5 essential goals.

The last step is the delighter phase. Here, the interviewer gives the participants two yellow sticky dots with smiley faces on them, to place on any two goals – not limited to the five “essential” goals. The goals they choose should be ones they are very excited about—ones that they would tell friends and colleagues about. They could also choose to put both dots on one goal, or even invent a new goal. People tend to have fun with this one, as they try to think “what would be really amazing?”

By the end of the interview, the participant’s key goals are glaringly obvious, based on the placement of the 10 “essential” and 2 “exciting” sticky dots.

Sample prioritization

Sample prioritization exercise using StormBoard

Getting customers what they want

Customer exploration interviews can yield misleading insights, and it’s our job as researchers to structure interviews in such a way that we learn both the users’ objectives, and some of the key features that users associate with those objectives. The benefit to structuring interviews using this Kano/Ulwick combination method is the ability to shine a spotlight on both incremental features and lesser-mentioned features – but our process doesn’t end there.

Ultimately, gathering this information is just one step in creating products that delight our users. It’s what we do with it that matters. As in any customer discovery process, interpretation plays a huge role in identifying insights. This methodology provides a starting framework to help with that analysis – leading us to creating truly delightful experiences.

About the Author

Jana Sedivy

Jana Sedivy is a user experience consultant who has spent a lot of time elbow deep in enterprise software guts. She is deeply uncool in a variety of other ways as well. She blogs at and tweets at @janasedivy.

Related Articles


  • Ted Goas Reply

    This was a fascinating read! There are a number of things in here I’d love to try out in our own product design workflow.

    One question that kept nagging me as I read through this: What happens if you follow these steps with your stakeholders, go away and build something based on the research gathered, and later present a prototype only to hear that the stakeholders have since changed their mind on the priorities?

    Reason I ask: I also work in enterprise(ish) product design and our team believes in research and iteration 100%, but we always seem to be making significant changes late in the game. I find myself torn between acting on new feedback and pointing to our original research.

  • Brian Coy Reply

    I agree with Ted. This is an incredible read which I want to duplicate with a current product that the entire team needs to revamp and stakeholders are pushing to improve.

    One item that I’ve run into in the past that would round this out is making sure to cross match the findings with the type of user and level of product engagement.

    Often companies I’ve worked with in the past want internal stakeholders who work in a product to be the ones tested and evaluated because of their product knowledge and contact with clients. This often leads to results that solve their work needs (which is fantastic) but ignores or assumes the end needs of the customers of the product. Often in my experience these are similar but not always the same.

    Ted: you can solve some of the research vs feedback dilemma by implementing A/B testing and making small changes with each release to measure the effect of the changes so that the findings elevate and reduce personal preferences/feedback.

Leave a Comment on This Article