Accessibility

Dialog Box

Interface surgery: Design for mental models

Page 2 of 2
Previous Page

Table of Contents

  1. Introduction
  2. Allowing users to form their own mental models

Allowing users to form their own mental models

Instead of focusing on focus, implementation-model designs focus on covering all the bases. They sacrifice ease of use in favor of the fine level of control a system is capable of allowing.

Programmers, who are usually the first to admit they are more computer savvy than the rest of the world, often want incredible amounts of control over the applications they work with, so they surface everything they can in the applications they build, regardless of how difficult it makes a tool to learn for someone who lacks the experience of a programmer. Their users typically don’t want this fine level of control. They want to understand how to get their work done and go home to their kids and spouses and dogs.

2 lists

Just yesterday, I was shown a design for a blog template that featured a small section in the sidebar used to show a list of keywords associated with the post currently being viewed. The list could be shown in two ways. One way was as a tag cloud, which uses larger fonts to display more relevant keywords and smaller fonts to represent less relevant keywords. The other way was as a plain list where each item used the same font and font size. Two buttons, labeled Cloud and List, were offered so users could switch between the tag-cloud view and the list view. When I asked why the buttons were there, the designer told me a developer had said something like, “It would be nice if users had a choice to display the list both ways.”

I understand where the developer was coming from. Developers like to cover their bases and offer everything they can. If it’s possible to show the list in two ways, we think the choice should be offered. But most users viewing this particular page online will not know what a tag cloud is, and those who do will likely not want to switch between the two views. Providing them the choice is pointless. Users who see a tag cloud and understand it will benefit from being able to quickly discern between the relevancy of the various keywords, and those who don’t get it will still see a simple list of keywords. No harm, no foul.

But when presented with the option to switch between the two views, every user without preexisting knowledge of a tag cloud would have to try to figure out what was meant by the two buttons. Users would be forced to learn something they don’t need to know in order to become comfortable with the page. The choice doesn’t help anyone, and actually distracts users from achieving a basic understanding of the page’s functionality. The implementation-model design would have impeded a user’s chances of successfully using the page.

Thankfully, the designer decided to scrap the two buttons and just show the tag cloud.

A third trend that results from the use of implementation-model designs is that tasks often become cumbersome and frustrating because the system needs all sorts of particular bits of information to complete an operation, and it forces you to tweak and guide it at every step so it can complete the operation in the exact way you tell it. It doesn’t help you form a simple understanding of how to make it work; it forces you to understand it so it can get what it needs. To this end, it pokes and prods at you until it gets everything out of you it can.

This approach manifests itself as labels that mean nothing to someone who doesn’t know how the system works, positioned next to pieces of functionality that should never have been surfaced in the first place. Like a button labeled Cloud.

This behavior is, well, rude. It’s about making users do everything they can to make the system happy and not doing what makes users happy. Applications like this try hard to be all things to all people, and end up failing to be anything great to anyone. Yes, these applications can still succeed, but it is often because of other factors, such as the lack of any other application in the market that fulfills a similar purpose. This sad fact doesn’t make it OK for applications to be rude, but they end up that way far too often because the mighty implementation model rears its ugly head.

When applications work well, however, and allow users to easily form their own, more comforting mental models, everybody wins.

Where to go from here

For more information about web design and design philosophies, check out the following resources:

Page 2 of 2
Previous Page