Kathy Sierra is one of the bloggers at Creating Passionate Users, which I already had on my Bloglines subscription, but ran into again in an IT-Conversations podcast, where she had some good insight on thinking about users. Here I’ll summarize those insights and combine them with other ideas I’ve gleaned from other places.

Her main argument was that in order to have users that are passionate about your site, they need to get past the “suck” phase. If you suck at something, then you won’t be passionate about it. OK, I can conceed that having some level of competence on a theme is a, but not the only requirement. So the first step is to analyze why people would want to use your service in the first place – what kind of new skills they will need to gain to use it fully? And why would they do that learning (5 why’s)? An example she uses is a Nikon photography guide site, that made her buy a better camera in order to take better shots.

The road to mastery of a skill is a long one, so most people need intermediate milestones. So it’s a good idea to show the vision of what mastery will give to them, but also make it clear that there are smaller steps to be taken, and each step does also produce some added value to the user. These visions could be communicated via images, or verbally (“wouldn’t it be cool if you could…”).

To get people to learn something voluntarily, you should aim for the flow experience. This means providing a challenge that is interesting enough, but not too hard for their current skills. Boredom and frustration are the alternatives to a flow experience if the situation is not balanced correctly.

For keeping up the motivation that users have initially gained, Kathy Sierra mentions levels in games. Gaining new levels of expertise give you new “superpowers”, that should be visibly demonstrated to the users. This is one very good idea, and more ideas about keeping users addicted to your service are in my previous blog post.

One important factor often neglected (or just done poorly) is user documentation. A technical, logically structured doument may be understandable to the designers of the system, but hardly so for the newbie user. The documentation should use conversational style (because the brain is more interested in conversations than monologues), and provide a story or stories (because the episodic memory of the brain is otherwise unused). Fun stuff should also be included (because fun equals play equals learning opportunity for the brain). And showing pictures of puppies and kittens (or snakes and spiders) also lights up additional areas of the brain. Leaving some things obscure or unclear or mysterious is also a good way to keep users interested.

Finally, featuritis is a good way to kill user enthusiasm and make them feel guilty for not understanding the whole system. Having good documentation, a user community for peer support, and of course, KISS (keep it simple, stupid!) are good ways of avoiding this.