Nielsen second heuristic is match between the system and the real world, and what this means is the system should speak the user's language with words, phrases, and concepts familiar to the user rather than using system oriented terms. Also, follow real-world conventions making information appear in a natural and logical order. Why is this important? Well, first, it allows us to take advantage of users existing schema or the associations that they already have between different pieces of information and how they're connected to goals and actions. It also allows us to leverage perceived affordances and signifiers that suggest actions that are familiar to the users, and it reduces the difficulty of forming effective conceptual models because we're taking advantage of conceptual models that users already have. Again, there are a number of different ways that this heuristic manifests its specific designs. The first is through the use of language. So, the heuristic says, "Use words and phrases that are familiar to the user not system-oriented language." We often see examples of error dialogues and other dialogues that have traces of the programming that was done to produce the system that haven't necessarily been rewritten to make sense to users. So, here are a couple of examples: "Microsoft Office Update doesn't understand the event sysodisA message." This is clearly not a message that was intended to make sense to the user, but maybe it makes sense to the person that programmed this particular system, or here's another example. This is actually an example from an earlier version of Twitter, where the message simply says, "Error: node was not found." This is not something that's going to make sense to the user, and it's going to impede their ability to use the system or understand why whatever they did failed. Here's another example. This is a system called the Text Analysis Markup System or TAMS for short, and this is a very specialized tool that's used for people that do certain types of research using qualitative textual analysis, which isn't very important to understand, but if we look at the language that's used on this interface, we can see lots of examples where system, terms continue to show up that might make it hard for people to understand how to use the system. So, for example, init file, or path mode, or define codes, or various things like that are defined in terms that aren't going to necessarily be obvious to the users or be part of the user's vocabulary, but are going to be part of the vocabulary that makes sense to the system developer. By using system-oriented language, it's going to be harder for users to learn how to use this system and to master it. So, here's another example. Think about how you might create a document in the real world. You might pick up a piece of paper, you might write some stuff on it, maybe a letter to somebody, a memo, a note that you want to remember, a list, and only at that point do you decide if this thing that you've produced is valuable enough to save or whether it should be crumpled up and thrown in the garbage or recycling. Well, a similar order of operations has evolved for how we create digital documents. So, you start by creating the document, which is a blank page, and then you write some stuff on it. At that point, you decide whether this document is worth saving, and if so you save it, and then you give it a name and decide where to put it. You can imagine systems that ask you to name the item first and choose a location for it, which would end up forcing you to create a bunch of documents that you end up not needing that just clutter up your desktop, your file system and so forth. To extend this a bit further, a common way that the match between the system and the real world is manifested is through the use of metaphor, which we've talked about in earlier lectures. The two examples that I just gave are often embodied in digital systems through the shopping cart metaphor and the document metaphor, but these metaphor's go farther than just suggesting a particular order of operations that might be used to complete a particular task, but allow the user to infer other capabilities that might be available through the system functions. So, for example, the user might infer that the shopping cart would also allow them to add multiple items, and to remove items, and even to abandon their cart without buying anything. The document metaphor might suggest to users that they not only can create and save files, they can also delete them, they can copy them, and they can send or share them with other people. It's important to make sure that systems that we design match the real-world expectations of users, so that they can take advantage of what they know from the real world and use it to effectively use the systems that we design.
