One of the most difficult challenges in creating a game or any product for that matter is figuring out what the consumer wants. Inexperienced developers will often just ask consumers what their preferences are or worse yet, list a bunch of features and ask whether they want them in the game.
It’s like walking a kid in a candy shop, pointing at every candy bin and asking, “Do you like this?” More than likely, you’ll end up with a lot of “likes”.
Kano modeling offers a more sophisticated approach to assessing consumer preferences but one that’s simple to use. By asking a series of questions about features, you can determine which features the consumer must have, would like to have, would be willing to pay more for and those she is indifferent to.
Over several product cycles, we struggled with a certain feature. It took significant production time to maintain. Some of us felt that it was an essential feature, others felt it was a wasted and cumbersome distraction. When we polled our users about how much the users ‘liked’ it, the response was tepid.
Believing that the feature was not that important, we were set to scrap it. Luckily we polled our users using Kano modeling and discovered that it was a ‘Must Have’ feature thereby avoiding a disaster if we had removed it.
It was a productive meeting; I just didn’t have anything to note.
I went to see my friend, Carolyn Marie Monroe, in Sound Theatre’s production of Pygmalion. En route, I stopped at a friend’s going away party and as I was checking my tickets I noticed a warning that the theatre could get very cold. And here I was wearing shorts!
My friend gave me a fringed blanket to take with me and I remarked that it was my George Bernard Shawl. Hahaha.
Anyway, the production was very smart and professional but despite the high quality, I wasn’t completely involved. I started to watch the actors being spoken to and noticed that some rarely ever reacted to what was being said. But once they spoke their line, they were present and animated.
It got me thinking that some actors just act ‘cue to cue’ and are blank in between. It’s like an animation that just goes from one keyframe to the other without any transition. And without that transition, the performance gets uncanny and lacks realism.
Many years ago, Ayu Othman introduced our office to the wonderful art of foot bagging or Hacky Sack. The general goal was to keep the bag in the air without using your hands but very quickly, the group began to modify this simple rule of play.
The goal of a round was changed to either have everyone make contact and keep the bag aloft for as long as possible (i.e, a Whozit as in Who is it going to go out on?) or to propel the bag between someone’s legs (i.e., a Wicket). It is interesting to note that these two goals are in conflict. The Whozit is more of a communal goal with everyone pitching in to try and ensure that the foot bag stays in the air, but a wicket usually stops the game.
Additional rules began to surface such as clarifying what constituted a wicket (e.g., if the foot bag was flicked between a person’s leg while the footbag was stalled on the ground, it was a flicket) or RLR, the Right Leg Rule which defined who would be responsible for kicking the foot bag if its trajectory was between two players. When we first starting using wikis we created a hacky sack wiki in part to maintain these rules but also as a way to get people familiar with the tool.
Recently we’ve adopted a ritual whereby the person who received the last wicket displays a clump of feathers on their cubicle as a mark of ‘shame’.
I proposed a rule to give those players who wicket someone who already had the feathers some additional mark of shame. My inner designer felt the current rule was too heavy-handed with weaker players and that the stronger players needed some governance. But we have not yet adopted this rule as the process is much more organic and ad hoc.
I just hope I don’t get wicketed as a result of my proposal…
One of my favorite interview techniques is to ask the interviewee to solve a vaguely stated question. This can sometimes make me look stupid but it reveals a lot about how a person approaches a poorly framed problem. Of course, if they start to ask questions to define the issue, you need to provide them with further information.
I also find this to be a useful technique when soliciting information from companies, especially initial estimates before the RFP process. It demonstrates that the company is thinking about the project and adding a level of accuracy to their quote.
And being Vague helped Julie Brown in her clever Madonna mockumentary, Medusa.