Are some of the foundational principles more important than others? If so, which ones? Why are some more important than others? Can you point to examples that illustrate the hierarchy you propose? Consider both Neilson’s and Norman’s lists.
While the hierarchy may vary depending on the specific goals of the project at hand, several of the principles stand out as integral aspects to most, if not all, interactive tools.
Consistency : Allowing for the user to adapt to a new interface can be challenging as devices and tools continue to change. By instituting already established rules and reactions into the interface, this consistency allows for quicker adjustment and a sense of familiarity. Ultimately, all interfaces are going to be used. I found Jeevan Kalanithi’s assessment of consistency in last night’s discussion to be so spot on when he asked, “What are you going to teach the user?” He asserted that you can choose one thing to be innovative about while leaving the other aspects alone.
From a designer’s perspective, I think this outlook brings in the tenets one finds in the established methodology of scientific study. Consistency, in a sense, acts as the controlled elements in an experiment. We generally know how someone will use, say, the volume buttons on the iPhone, because they reflect the language of an already-existent model used in a bevy of items. The innovation, on the other hand, is what it is that we’re actually testing. Is our hypothesis of how the innovative aspect will be perceived and used correct? Given a level of familiarity, these new aspects can then be more easily evaluated and improved for a person’s needs.
Feedback & Visibility & Mapping (A Muskateers-esque Trio) : At the most basic level, we need to a confirmation of our actions by the interface to understand it is responding to our actions and is working properly. This verifies our functional relationship with the object. Imagine a time when you’ve shared an anecdote with someone. When they did not respond and you immediately start to wonder, “Well, did they hear me?” In the real world, as in the relationship between the real world and a system, people have a certain expectation that if they execute task X, there should be some sort of reassurance that the task was actually completed.
If we go back to the iPhone volume button, a person would expect that if they depress the “+” sign button (consistency,) the button will go down and the volume will go up. Not only do they receive the audible feedback of the “click” when the button is depressed, they can visually see the volume setting rise incrementally as the ringer volume display pops up simultaneously to the button press. If the same person were to press the button down and not hear, feel or see the established feedback, there would be no way of knowing whether the ringer volume went up and how much until someone called.
Help Users Recognize, Diagnose, and Recover from Errors : “Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.” If this were indeed the case in every interactive system, I wouldn’t have quite so many phone calls from a certain someone in my life that struggles with technology. In an ideal system, we not only allow for the user to become familiar with the interface, but, hopefully, we empower this person to complete the given task with an assurance that not all is lost when something goes wrong.
While I may see these aspects as rather important, each of the principles that Norman and Neilson point out require awareness and, really, acceptance, in the design process.