Consider existing real world or user expectations when designing UI.
- When we create user experiences on the web or in apps, we can't help but refer to the real world sometimes. I'm not talking about skeuomorphic design where a note-taking app looks like a paper notebook or a poker game looks like it's on a green baize table. That stuff was fashionable for awhile, but thankfully we've moved on. Instead, I'm thinking more about parts of the everyday stories we tell that help us understand how things work. For instance, using shopping carts as a place to store items we want to purchase online or calling the main screen on a computer system a desktop.
Obviously the computer screen isn't a desk. The metaphor breaks down really quickly. Don't keep our trashcans on our desks. They sit underneath them. Our file cabinets also aren't on our desktops typically. In fact, for a lot of people, the only thing that is on their desktop is their computer itself. That could get recursive really fast. So we obviously have to be careful when we use real world items as metaphors for things that happen on the computer. I'd suggest that you do so where the item that you're representing digitally behaves in exactly the same way as in real life, but that you avoid those metaphors when the item behaves differently.
Some metaphors are so old or so outdated that we might not even realize they're in effect. For instance, do you know what CC and BCC actually stand for in email systems? That's from the days when you would put two sheets of paper in a typewriter with a sheet of carbon paper between them. That meant you could make two copies of a letter just by typing it out once. CC means carbon copy, and BCC means blind carbon copy. The recipient gets the letter for information only and isn't expected to be part of any follow-on conversation.
Another one is radio buttons. Anyone born after 1975 has probably never used a car radio with radio buttons. The buttons were for selecting preset stations. You pressed one in and the one that was currently pressed in popped back out. Knowing about this physical behavior of the station tuning buttons helps you to understand that one and only one radio button can be selected at a time compared to check boxes, where it's valid to have one, many, or even no boxes selected.
So, your metaphor has to stand the test of time, or it has to be suitably recognizable or learnable that people can use it even if they don't know the metaphor, like the floppy disk icon on the save button in some productivity software. It's hard to even buy floppy disks anymore, let alone find a computer that can read them, but the metaphor of the floppy disk as a storage medium for your files still persists, and the save button is used by people who've never even touched a floppy disk. In the rest of this chapter, we'll talk about some other physical issues that you need to consider when you're creating an interaction, making objects clickable, responsive, and intuitive, and also thinking about the cultural differences that you need to take into account to have your product accepted around the world.
- Designing around human limitations
- Telling stories
- How we group the things we see
- Making standard and consistent interfaces
- Smart defaults
- Reducing system latency and communicating during delays
- Making error messages into useful dialogs
- Designing for delight