UI, UX and how users see world

Factors Measured in Usability Testing

The most common factors measured in usability testing include:

  • Effectiveness: a user’s ability to successfully use a website to find information and/or accomplish tasks
  • Efficiency: a user’s ability to quickly accomplish tasks with ease and without frustration
  • Satisfaction: how satisfied the user is with site
  • Error frequency and severity: how often users make errors while using the system, how serious the errors are, and how users recover from the errors
  • Memorability: a user’s ability to remember enough to use the site effectively after his or her first visit

Shneiderman’s “Eight Golden Rules”

1 Strive for consistency.
Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.

2 Enable frequent users to use shortcuts.
As the frequency of use increases, so do the user’s desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.

3 Offer informative feedback.
For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.

4 Design dialog to yield closure.
Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.

5 Offer simple error handling.
As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.

6 Permit easy reversal of actions.
This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.

7 Support internal locus of control.
Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.

8 Reduce short-term memory load.
The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

Mental Model vs conceptual model

“A mental model is the representation that a person has in his mind about the object he is interacting with. A conceptual model is the actual model that is given to the person through the design and interface of the actual product.” (Susan M. Weinschenk. 2011. 100 Things Every Designer Needs to Know About People)

So a mental model is the way the person thinks about what it is they are doing. For example, when getting a book out of the library, they form a mental model of the things they have to do to achieve this.

A conceptual model for an online library is the interface the person interacts with as a represented concept of a library.

Conceptual model: the mental representation of the design.

Mental model: the mental representation of the way the system works that emerges from its use.

Mental models constructed from comprehension of discourse have been Philip Johnson-Laird’s (1989) subject of study. He posited that a reader creates a mental model of the text being read, which simulates the ‘world’ being described, as the reader understands/interprets it. According to Johnson-Laird, ambiguous passages of text can lead to more than one competing mental model, which is something authors deliberately use to keep the reader confused about certain aspects of, say, a story in a novel. However, passages of text that unambiguously produce a single mental model are easier to comprehend.

Another area of relevance are discussions of ‘system causality conveyance’. The use of mental models in this sense was popularised in the HCI and interaction design community by Donald Norman in his book “The Design of Everyday Things” (Norman 1988). In his book, he used mental models to describe how a system is designed and implemented on the basis of the designer’s mental model. Similar to a reader of a passage of text, the user develops a mental model of how he/she thinks the system works through interaction of the system. This model is used to reason about the system, to anticipate system behaviour and to explain why the system reacts as it does. In other words, the designer reifies (materialises) his mental model of a given design, e.g. a computer system, which becomes the only means of conveying his mental model to the user.

Norman also speaks of conceptual models. In the article “Some Observations on Mental Models” Norman (1983) distinguishes between mental models and conceptual models: “Conceptual models are devised as tools for the understanding or teaching of physical systems. Mental models are what people really have in their heads and what guides their use of things.” In other words, the designer designs a conceptual model into the system in order for it to appear graspable and coherent to the user. If he/she manages to get the conceptual model right, the correct mental model (in the mind of the user) will follow. At least in theory.

Norman’s account is of course an over-simplification, but it captures some central dilemmas of interaction design by using mental models as a vehicle for explanation and illustration.

What is a conceptual model?

In order to understand why mental models are so important to designing user interfaces, you have to also understand what a conceptual model is. A conceptual model is the actual model that is given to the user through the interface of the product. Going back to the iPad ebook example, you have a mental model about what reading a book will be like in the iPad, how it will work, what you can do with it. But when you sit down with the iPad, the “system” (the iPad) will display what the conceptual model of the book app actually is. There will be screens, and buttons, and things that happen. The actual interface is representing the conceptual model. Someone designed a user interface and that interface is communicating to you the conceptual model of the product.

Normans Principles


The visibilty principle simply states that the basic functions of the system or product easy enough for a user to understand and use. All performance aspects of the product or system should be relatively obvious to the user. The user should not find it difficult to understand the product or system if the visibilty principle is followed. The functions of the system or product should be evident just be looking at the device.


The feedback principle states that while using the product or system there should be some immediate and obvious kind of signal to let the user know that there was a response or a result. Some sort of system feedback should let the user know that they have done something. These signals could be audio or visual cues or something that is obvious to the user and it will let them know that did something. The response must aslo make sense and let the user know if what they are doing is correct or incorrect.


The constraints principle is useful in stopping users form taking certain actions that are not suppose to be taken with certain devices. There are physical, semantic, logical, and cultural contraints. Some constraints are put into place because some actions should never be executed on some products or devices. Perhaps a certain action would destroy the product and a contraint is put in to prevent this from happening.
Examples of physical constraints: seat belt, locking mechanism, USB-port (only one way to insert the USB key).
Examples of logical constraints: speed limit, log-in system.
Examples of cultural constraints: language, keyboard for different languages.


Mapping principle also known as ‘natural mapping’ means that there should be a logical and/or cultural spatial/temporal relationship on how the product is used and displayed. There should be a relation between actions and intentions on using the product or system. The more clear the relationship is the easier it is for users to become accustomed to the product or device.
One problem that exists with mapping is that the more complex the system or device is the harder is it to make it easy to use. If you do not take into account previous relations, users will become confused on your random mapping.
For example, the cursor keys on the keyboard.


The consistency principle allows users to ‘get used to a product or system’ and therefore once they learn how to use it, they can continue to use it because given actions produce the same results so it is consistent every time. Consistency must also be taking into consideration as to other similar products or systems in the market, e.g. VCR, the key pad of cellular phones, and the layout of retail chains such as Home Depot and Starbucks.


“Does the design provide intuitive clues on what can or should be done?” e.g. to push or pull a door.

What Is Hierarchical Task Analysis?

A structured, objective approach to describing users’ performance of tasks, hierarchical task analysis originated in human factors. In its most basic form, a hierarchical task analysis provides an understanding of the tasks users need to perform to achieve certain goals. You can break down these tasks into multiple levels of subtasks. In user experience, you can use hierarchical task analysis to describe the interactions between a user and a software system. When designing a new system, hierarchical task analysis lets you explore various possible approaches to completing the same task. When analysing an existing system, it can help you to optimize particular interactions.

Once you’ve created a hierarchical task analysis, it can serve as an effective form of system documentation, enabling developers to rapidly understand how users interact with a system. As software engineers are all too aware, the intimate familiarity you may have gained with why users do something in a certain way can quickly fade in just a few days or weeks. A hierarchical task analysis is an effective means of capturing this information.

Applying Hierarchical Task Analysis to User Experience

Hierarchical task analysis requires a detailed understanding of users’ tasks. You can achieve this understanding by

  • identifying users’ primary goals
  • detailing the steps users must perform to accomplish their goals
  • optimizing these procedures

Let’s look at an example of a hierarchical task analysis. Our example is from a hierarchical task analysis I performed to better understand an existing system. We’ll consider a common task: ordering a book.

In this hierarchical task analysis, I’ve broken this task down into subtasks, expressing the relationships between the parent task and its subtasks through a numbering scheme. This hierarchical task analysis is very coarse from a user experience standpoint. It does not communicate anything about what is happening at the level of a user’s interaction with the system. However, it does give a clear understanding of the task’s high-level steps. A more complete task analysis would ultimately get down to the level of user interactions. To illustrate, Subtask 1.4, “Complete address,” would break down as follows:

  1. Locate the Full Name field.
  2. Move the insertion point to the field.
  3. Type the full name.
  4. Locate the Address Line 1 field.
  5. Move the insertion point to the field.
  6. Type the address.
  7. Optional: Locate the Address Line 2 field.
  8. Move the insertion point to the field.
  9. Type the address.
  10. Locate the Town/City field.
  11. Move the insertion point to the field.
  12. Type the town or city.
  13. Locate the County field.
  14. Move the insertion point to the field.
  15. Type the county.
  16. Locate the Postcode field.
  17. Move the insertion point to the field.
  18. Type the postal code.
  19. Locate the Country field.
  20. Move the insertion point to the field.
  21. Select the country from the drop-down list.
  22. Locate the Phone Number field.
  23. Move the insertion point to the field.
  24. Type the phone number.

Optionally, you can provide an illustration of the screen on which a user performs this task, helping to put this interaction in contex.

“Create a plan that describes the way in which a hierarchical task analysis assembles the subtasks that let users achieve a particular goal and any conditions the subtasks must fulfill.”

Combining different approaches to describing user interactions provides an understanding of tasks that is both broad and deep. The diagram shows how the high?level steps of a task relate to one another. The structured breakdown of the task into its subtasks describes each interaction in detail. The screenshot puts the interaction in context.

It is advisable to create a plan that describes the way in which a hierarchical task analysis assembles the subtasks that let users achieve a particular goal and any conditions the subtasks must fulfill. In many cases, users can simply work through the subtasks in a hierarchical task analysis, so keeping the plan separate from the tasks provides an additional degree of flexibility. For the example hierarchical task analysis, there could be two different plans, as follows:

  1. If a user is new to the system, complete Task 1.
  2. If a user has registered and is signed in, complete Tasks 1.1, 1.2, and 1.5.

The Benefits of Hierarchical Task Analysis

Understanding user interactions at multiple levels of abstraction provides several benefits.

  • It lets you objectively compare different approaches to the supporting same task—in terms of the numbers and types of steps the approaches require. For instance, reducing the number of steps in a task would probably enable a user to complete the task more rapidly, so replacing multiple fields with a single field would speed up the task. However, this would also make the address less easy to verify. The hierarchical task analysis provides a framework in which you can capture such a design rationale and refer to any related documentation.
  • There may be several competing approaches to the same problem, so ensuring your team uses common language and a consistent approach to hierarchical task analysis can help you to compare them fairly.
  • It enables effective UX design, because designers can understand how a system works, at whatever level of abstraction is most appropriate for what they are currently trying to accomplish.
  • It supports UX design reuse. UX design patterns are a useful step toward UX design reuse, but they describe only the high?level principles of interactions. Hierarchical task analysis lets you capture multiple implementations of a design pattern—expressing interactions in a common structured format—and identify new design patterns.


Although HTA has been used for over 40 years, it is still widely used in industry because it is simple and straightforward. The results of an HTA is a starting point for more detailed modeling methods, like GOMS.


  • HTA is a simple and flexible method that does not depend on a methodological context.
  • HTA enables the representation of a task hierarchy that could be further detailed.
  • Although HTA is task oriented and to some extent user oriented it still maintains a strong relationship with traditional software engineering.
  • HTA provides information, inefficiencies in tasks, that can be used for developing product requirements.


  • There are no strict rules for creating an HTA diagram so different analysts will generate inconsistent hierarchies at varying levels of detail.
  • HTA requires both training and experience. It is not a tool that can be applied immediately.
  • HTA is not a predictive tool. It focuses on existing tasks.
  • HTA diagrams can become quite complex.


When used in large project, HTA requires a lot of overhead work to revise / maintain task numbers and plans as tasks are edited and moved within the hierarchy. Also, it is difficult to synchronize the graphical and textual representations.

low-fidelity prototype

a prototype that is sketchy and incomplete, that has some characteristics of the target product but is otherwise simple, usually in order to quickly produce the prototype and test broad concepts.

high-fidelity prototype

a prototype that is quite close to the final product, with lots of detail and functionality. From a user testing point of view, a high-fidelity prototype is close enough to a final product to be able to examine usability questions in detail and make strong conclusions about how behaviour will relate to use of the final product.

Norman’s stages model of human action

Seven Stages of Action constitute three stages of execution, three stages of evaluation and our goals.

1. Forming the goal

2. Forming the intention

3. Specifying an action

4. Executing the action

5. Perceiving the state of the world

6. Interpreting the state of the world

7. Evaluating the outcome

[Total: 0    Average: 0/5]