The Design of Fuzzy Things

Another book-related post. This time I'm going to approach the topic of playful usability via The Design of Everyday Things (Don Norman). I don't think I this book needs any more recommendations, so let's just go ahead with some thoughts of my own*.

I'd like to start with the three models. There's designer's model, which is how the interface is designed to work. On the other end, the user's model, is how the user thinks the interface works. And in the middle is the system image, responsible for communicating how the interface works. In other words, the user's model is dependent on the system model. In fuzzy usability, the system image is intentionally non-obvious. The idea is not to directly communicate the workings of the system but rather present an interface that raises curiosity and allows the user to discover the workings. By obscuring knowledge we make it more desirable to attain.

My hypothesis for the benefits is that interfaces constructed this way are easier to learn. In a typical desktop interface such as the Firefox web browser I'm currently looking at, the user is immediately presented with a lot of actions. Wizards are often used to guide beginners. The downside is that wizards are separate interfaces for doing specific tasks and do not teach the user to use the program's interface. In a purposefully obscured interface, it is easy to start by presenting the most basic of tasks and reveal advanced features when the user "levels up". The application can reveal the presence of features when they become relevant.

We can think of interfaces separated into zones. Anything the user is already familiar with is in the safe zone, and the message is clear "you know these things, it is safe to work with them". On the borders of the safe zone, there is the uncertain zone. The user has an idea of what is there, and it's kind of saying "you might feel uncomfortable here, but these things can make you more powerful". Finally, there is the great unknown, beyond the uncertain zone. When the application realizes that the user is doing something that could be done better with an advanced feature, it can assign quests, sending the user to explore a particular uncertain zone or even an unknown zone. If the user wishes to find a particular feature, the help system can provide directions of how to get to that feature.

Unsurprisingly, this bears high similarity with playing openworld or sandbox games like Grand Theft Auto. The player can explore quite freely, discovering new areas progressively while learning new skills. But when the player wishes to get on with the story, there are certain things that are required, and hence the game sends the player on quests to meet these requirements. Add rewards for mastering new skills. One further way to think of this comparison is that of task. In a game, the task is to complete the story. In an application, the task is to complete some external goal. Typically the difference between these two tasks is their definer: in a game, the task is defined by its designer while in an application the task is defined by the user. The point remains the same though: why shouldn't the user/player have fun while learning the skills required to complete the task?

In terms of affordances, safe zones afford safe using of features with predictable outcomes; uncertain zones afford experimentation with features; unknown zones afford exploration. Restrictions can also be used by requiring certain features to be in the safe zone before the user is allowed to use particular advanced features. This will ensure that the user has grasped some important basic concept before trying to use a feature that heavily builds upon that concept. The restriction also comes quite naturally - the user needs to traverse through the prerequired features on his way towards the advanced feature.

Implementing an interface that conforms to this model should be an interesting task. Some key considerations in functionality are to ensure that 1) the safe zone really is safe and 2) the uncertain zone clearly supports experimentation. Predictability is key in the first consideration, while proper undo support is key in the second. Another implementation question is analysing user actions in a way that the application can decide when it is appropriate to advertise a feature.

* Similar thoughts can be encountered in several HCI articles, and I'll return to them later. Difficulty regulation is a good key word if you're looking for one.