Friday, September 12, 2008

Raising users

Instead of doing what I am supposed to be doing - sweating my ass off with the UI development - I decided to take a break and write my first post.

Let me begin with a disclaimer:

What I am about to present you struck me when I was trying to make our firstborn go back to bed rather than go "GÄK!" all over the place five o'clock in the morning. Therefore it might also take me few curves here and there to hit the sweet spot. Bare with me.

Now, as a responsible parent of a nine months old boy I have (of course) been reading a book or two about how to raise children (how else on earth would you know how to?). In one of the books the philosophy is based on an idea of a circle that surrounds and defines home. This circle is naturally forged together by addressing both affection and boundaries to the child. Parent's job is to make sure the child is forced outside the confinement of this circle as rarely as possible. As the child grows the circle is broadened on par with the child's capabilities to interact with the world by giving her more responsibility. Basic pedagogy stuff.

May I present you with an example from the book.

A mother is planning to go outside with his three year old daughter. For no apparent reason, the daughter refuses with all her might just as a child of that age might do. In such situations the parent should not give in, but rather dress the child and carry her outside no matter how loud she might scream?

Why? Why not give your daughter (and yourself) some slack and stay inside?

That is because the child seeks her mother’s leaderships. In fact, she craves for it. Giving the child control over whether or not to go out for a bit of fresh air puts her into the throne of the decision maker. If the mother gives in, that means the daughter should take responsibility of the course of events carried during the day - something that she naturally is not capable of yet doing.
Denying the choice to stay in presents the daughter the leadership she is looking for and will eventually make her emotionally attached to the parent. This is essential for both the child's inner development and to the healthy relationship of the two.

As much as allegories often "suck ass sideways" (as my colleague Huima might put it), I am willing to take the risk and present you with one:

Let's imagine our end user as a toddler who has just learned how to walk. This is not to make mockery of the capabilities of the end user. On a site a link is a link and a button is a button. No education required. Rather it is to say that once a new user comes to the site he is totally new to the inner concepts of the developers might have. Naturally these inner concepts must be communicated to the user. I'd say in the terms of the Internet, most of that must happen within the first 30 seconds.

Of course the user already sits on the throne, for he controls the browser. And he is the king or queen when the browser is within the boundaries of his or her kingdom (sorry for another piece-of-junk allegory).

Yet we must acknowledge that coming to a new service the end user seeks the site’s (or the development team's) leadership. Therefore, when providing services, hold the users hand from the get-go. Do not make her choose between tons of features. Show her what it's all about. After that the circle can be broadened. And later even more. This naturally goes with both the visual and the structural design.

...

Have you ever heard anyone saying the following:

"Like this could be linked to that and that could be linked to this and this could be embedded into that and then the user could have the option to either do it this way and or this way. And then every user could customize the way their ..."

By doing feature-bloated design we of course try to cater all the different use cases we can think of. At the same time we diminish or ability to speak to our audience, who probably didn't come for tons of different things and would feel much more safe if it resolved just one issue for them. Yes, you heard me: safer.

By safer I mean that our user is able to decice within few minutes whether or not the service has any value to him and if so - store it in a safe place, a cardboard box on the upper shelf of his mind waiting to be opened again if need be. Or in toddler-terms:

"Banging a wooden duck against a radiator seems fun. I just store this duck here on the floor until the next time I feel like driving the neighbourhood nuts."

In terms of UI design, "keeping it simple" doesn’t give enlightenment to anyone, right? Yet over the years of developing sites and services I feel this is something that cannot be stressed enough.
When digging head deep down in the mud during the development phase it is just too easy to get carried away with all the concepts and features and gadgets and whatnot. Keep reminding yourself that you with all your knowledge of the concept differ very drastically from the average user. Then do that again. Good.

Somehow I am inclined to feel that the situation has not been getting better over the years, either. With the emergence of RSS, gadgets and all the different APIs, it seems that nowadays everything can be everywhere (or anything). Take Plaxo for example.

I am mostly connected to same people in Facebook, LinkedIn and Plaxo. Naturally I have most contacts in Facebook, but I am connected to all of my Plaxo contacts also in the other two. What's the use of that? Shouldn't one or two – one for private contacts and one for business matters – suffice? When I originally signed into Plaxo it was advertised to me as a way to backup and share contact data (phone numbers, mail adresses etc.) online. Nothing more. Since, it has bloated into sort of wannabe-facebook-esque thing with all it's photo sharing capabilities, and now I am not sure what issue it should resolve for me. If they'd kept sharpening their key features instead of releasing a bunch of new ones I might've been a keen user. Add the fact that at the time I registered, the calendar sync feature did not quite work. Now all I do is receive a notification about one of my ten contacts becoming a year older soon. Woo-hoo.

Evolution is of course natural. But I challenge all the development teams to ask themselves the (perhaps ugly) questions: What is the core of your service? Does this new feature really deliver added value to the end user?

(I am saying all of this as much as to myself as to some lone soul that might still be reading.)

All of this comes down to my following rules-o-thumb:
  1. Present the user with the right amount of choices he is capable of deciding upon. Broaden the view later. (1)
  2. Take into account the attention span of an average user by presenting the added value - the sweet juices first and foremost. Design as if the whole world has turned ADHD (as if it hasn't).
  3. This might some day make your user to become somewhat emotionally attached to your service (yes, you spotted the allegory, didn't you?).
  4. And then... only THEN we MIGHT start to speak about brand... Ok forget I ever said that.

(1) Knowing what is enough but not too much, now that's what would cut the cake, right?