SuryaGinti.com

User Information Needs
Information needs can vary widely, and each type of information need causes users to exhibit specific information seeking behaviors.
Users don’t always know exactly what they want.
During the process of finding, they may learn new information that changes what they’re looking for altogether.

User Information Seeking Behavior
Searching, browsing, and asking are all methods for finding, and are the basic building blocks of information-seeking behavior.
There are two other major aspects to seeking behaviors: integration and iteration.

Integrated browsing, searching, and asking over many iterations:

Berry-picking Model
These different components of information-seeking behaviors come together in complex models, such as the “berry-picking” model* developed by Dr. Marcia Bates of the University of Southern California. In this model, users start with an information need, formulate an information request (a query), and then move iteratively through an information system along potentially complex paths, picking bits of information (“berries”) along the way. In the process, they modify their information requests as they learn more about what they need and what information is available from the system.

Pearl growing Model

Users start with one or a few good documents that are exactly what they need. They want to get “more like this one.

” To meet this need, Google and many other search engines allow users to do just that: Google provides a command called “Similar pages” next to each search result. A similar approach is to allow users to link from a “good” document to documents indexed with the same keywords Del.icio.us and Flickr are recent examples of sites that allow users to navigate to items that share something in common; in this case, the same user-supplied tag. All of these architectural approaches help us find “more like this one.”

Learning About Information Needs and Information-Seeking Behaviors

Search analytics involves reviewing the most common search queries on your site as a way to diagnose problems with search performance, metadata, navigation, and content. Search analytics provides a sense of what users commonly seek, and can help inform your understanding of their information needs and seeking behaviors.

Contextual inquiry, a user research method with roots in ethnography, allows you to observe how users interact with information in their “natural” settings and, in that context, ask them why they’re doing what they’re doing.

Other user research methods you might look to are task analysis, surveys, and, with great care, focus groups.

Organization Schemes

Exact Organization Schemes
Exact organization schemes divide information up into well-defined, mutually exclusive sections, such as:

Alphabetical: for example, residential telephone book (white pages) sorted by surname then first names.

Chronological: for example, press releases sorted by date of announcement.

Geographical: for example, weather forecasts sorted by country and region.

Ambiguous Organization Schemes
Sometimes categories are overlapping or items fall into multiple categories.

Common ambiguous organization schemes include:

Topical: for example, product categories, newspaper articles, Open Directory.

Task-based: for example, browse, sell, search, sign in (limited number of high priority tasks).

Audience-based: for example, novice or expert.

Metaphor-based: for example, desktop or sketch map.

Multiple Organization Schemes
In the real world multiple schemes may be present together, However, when you start blending elements of multiple schemes, confusion often follows, and solutions are rarely scalable.
In the example below this hybrid scheme includes multiple schemes. Because they are all mixed together, users can’t form a mental model. Instead, we need to skim through each menu item to find the option they are looking for.

Where multiple schemes are presented on the same page:

Preserve the integrity of each organization scheme.

Do not mix and match schemes at the same level.

Taxonomies and Hierarchies
As far as possible, category labels should be:

Phrased in the user’s language.

Unambiguous.

Mutually exclusive (non-overlapping), so users know where to look (scent). *

Comprehensively exhaustive: i.e. completely partition the parent category, so users do not suspect a category is missing.

* If the categories are not mutually exclusive (i.e. if items may appear in multiple places), the taxonomy is called polyhierarchical.
Sometimes it makes sense to cross-list items in multiple locations: E.g. Do tomatoes belong to fruit, vegetable, or berries? Probably all of them [The tomato is technically a berry and thus a fruit, although it is usually used as a vegetable.]
Are toner cartridges best listed under laser printers or printer supplies? Probably both.

Hierarchies: Breadth Vs. Depth
If a hierarchy is too narrow and deep, users have to click through too many levels. If a hierarchy is too broad, users must choose between a large number of subcategories at each level.

A medium balance of breadth and depth provides the best results.

If you expect the hierarchy to grow, tend towards broad-and-shallow (it is less problematic to add items to secondary levels of the hierarchy).

Note: The famous 7 plus or minus 2 study [Miller, 1956] investigated the number of items retained in short-term memory. It does not apply to choices which are visible!

Card Sorting
Verify the hierarchical structure by conducting card sorting tests.

Open Card Sorting
Users cluster concept cards into their own categories and sub-categories, which they then label themselves.
Too few concept cards and you will not get two levels of a hierarchy, only one.
Used in early phases of research.

Closed Card Sorting
Users sort concept cards into a predefined category hierarchy.
At the start, you can ask users what they think each category means.
Used in later phases of research.

Faceted Search
A full text search generates an initial set of matching items.
These are then narrowed down using facets.
The user specifies a query progressively, narrowing down along one facet at a time.
The system can display the remaining number of items matching current facet values.
Dead-ends can be eliminated by not offering choices which would lead to 0 items.

Controlled Vocabularies
Using CVs with Search
A CV can be integrated with a web site’s search engine to handle the following situations:

• Synonyms: two words with the same meaning, like “jeans” and “dungarees”.
• Homonyms: words that sound the same, but have different meanings, like “bank” the financial institution and “bank” the side of a stream or river.
• Broaden or narrow a search.
• Common misspellings.
• Changes in content: for example, countries that change their name or have multiple spellings.
• “Best Bets”: identifying the most popular pages associated with a certain term.
• Connecting a woman’s married name to her maiden name.
• Connecting abbreviations to the full word: for example, NY and New York, the chemical symbol Si with the element Silicon.

User-Generated Structures
Allowing users to generate their own structures.
Watching user behavior and then supporting also known as “paving the cowpaths”.

Social Tagging
Web 2.0 and the rise of user-generated content has sparked a new form of emergent structure: collaborative tagging.
Also called free tagging, collaborative categorization. Users tag objects with one or more keywords. The network effect of “harnessing collective intelligence”.

Navigation Systems
Provide Spectrum of Navigational Aids

• Multiple Taxonomies: categories to browse.
• Search: Attribute and full text search.
• Site map: either graphical or a topical table of contents.
• Site index: alphabetical index of common words and phrases.

A heuristic evaluation is a discount usability inspection method used to evaluate software applications and products.

In heuristic evaluation a group of usability experts examine a user interface design for usability and compliance with the ten heuristics and to identify problems associated with the design of the UI. Usability consultant Jakob Nielsen developed this method on the basis of several years of experience in teaching and consulting about usability engineering.

Jakob Nielsen’s Ten Usability Heuristics:

1. Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

2. Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

3. User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

4. Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing.

Follow platform conventions.

5. Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

6. Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

7. Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

8. Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

9. 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.

10. Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

During the evaluation session, the evaluator goes through the interface several times and inspects the various dialogue elements and compares them with a list of recognized usability principles (the heuristics). These heuristics are general rules that seem to describe common properties of usable interfaces. In addition to the checklist of general heuristics to be considered for all dialogue elements, the evaluator obviously is also allowed to consider any additional usability principles or results that come to mind that may be relevant for any specific dialogue element. Furthermore, it is possible to develop category-specific heuristics that apply to a specific class of products as a supplement to the general
heuristics. One way of building a supplementary list of category-specific heuristics is to perform competitive analysis and user testing of existing
products in the given category and try to abstract principles to explain the usability problems that are found (Dykstra 1993).

References

• Dykstra, D. J. 1993. A Comparison of Heuristic Evaluation and Usability Testing: The Efficacy of a Domain-Specific Heuristic Checklist. Ph.D. diss., Department of Industrial Engineering, Texas A&M University, College Station, TX.
• Molich, R., and Nielsen, J. (1990). Improving a human-computer dialogue, Communications of the ACM 33, 3 (March), 338-348.
• Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI’90 Conf. (Seattle, WA, 1-5 April), 249-256.
• Nielsen, J. (1994a). Enhancing the explanatory power of usability heuristics. Proc. ACM CHI’94 Conf. (Boston, MA, April 24-28), 152-158.
• Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY.

Abstract

The System Usability Scale (SUS) survey was administered over a period of six months to measure the usability of several internally deployed software tools and applications.
It was found to successfully benchmark and monitor improvements in usability between different versions of the same application and compare usability across the organization by providing a means to compare usability scores between different tools and applications. Its success made it part of the IT scorecard as a valuable indicator of projects/ apps success.

SUS being an attitude scale some additions were made to the original survey to capture user feedback to enable product managers to get some valuable input from the end users. Also for non-native English speakers the word “cumbersome” in Question 8 was changed to “cumbersome/ awkward” 1

While SUS is a good indicator of usability it does not help identify the usability problems with the artifact being reviewed. For identifying usability problems any of the usability inspection methods like usability testing, or heuristic evaluation can be adopted.

Introduction
To have a uniform measurement of usability across different systems and applications is a difficult task, since usability is defined keeping in mind the context of use and the user goals. So to provide a single usability assessment scale that works across different systems is somewhat of a challenge.

John Brooke in 1996 developed a five point scale questionnaire for Digital Equipment Corporation to do exactly this. The System Usability Scale 2 (SUS) is a ten item attitude scale, based on ‘Likert’ scale it evaluates each question between five attitude scales from ‘Strongly Disagree’ to ‘Strongly Agree’. Since it’s an attitude scale, at sufficiently high level of subjective assessment of usability it is possible to use it to make comparison between systems/ applications.

Recent research has shown that SUS provides good indicator for website usability when compared to other questionnaire based surveys 3

The SUS scale is used after a user has had an opportunity to use a system but before any debriefing or discussion takes place. Users should be asked to record their immediate response to each item, rather than thinking about items for a long time. All items must be checked

System Usability Scale questionnaire
© Digital Equipment Corporation, 1986

1.I think that I would like to use this system frequently
2.I found the system unnecessarily complex
3.I thought the system was easy to use
4.I think that I would need the support of a technical person to be able to use this system
5.I found the various functions in this system were well integrated
6.I thought there was too much inconsistency in this system
7.I would imagine that most people would learn to use this system very quickly
8.I found the system very cumbersome to use
9.I felt very confident using the system
10.I needed to learn a lot of things before I could get going with this system

Scoring the SUS
SUS scores have a range of 0 to 100.
To calculate the SUS score, first sum the score contributions from each item. Each item’s score contribution will range from 0 to 4. For items 1, 3, 5, 7 and 9 the score contribution is the scale position minus 1, e.g. position 2 will equal ‘2-1’ a score of 1.

For items 2, 4, 6, 8 and 10, the contribution is 5 minus the scale position, e.g. position 2 will equal ‘5-2’ a score of 3.

Multiply the sum of the scores by 2.5 to obtain the overall value of SUS. A score of around 60 and above is generally considered as an indicator of good usability.

SUS has been made freely available for use in usability assessment, and has been used for a variety of research projects and industrial evaluations; the only prerequisite for its use is that any published report should acknowledge the source of the measure.

Method
The method employed to administer the test was to make available the test online. The users were invited to participate in the survey, where they evaluated the questions and rated them as they found appropriate.

The survey was administered pre-deployment to measure and benchmark as-is version and then post deployment after the user had the opportunity to use the new system for some time. This enabled the comparison between two versions of the same application. It also provided score to compare between different applications and determine the usability score of a particular application in comparison to others.

Initially it was supposed to be just these 10 questions to gather the score, but it as found that the Product Managers were not comfortable with just the scores as they wanted to know the reason for low/ high scores. Before the introduction of SUS there was no such measure against which the applications were compared, though they did go through a final usability testing. But there was no number to compare different applications and determine how usable the applications were on a scale. Hence there was some resistance initially, and to make the product managers more comfortable three open ended questions were added to the questionnaire. The questions were “What I dislike about the application, what I like about the application, and what I would like to have”. These required user comments, and subjective qualitative data were collected through these questions. While they did provide valuable input, these questions did not form part of the final SUS score which was dependent on the original 10 SUS questions. One important function that these added questions performed was to give insight into what may be wrong with applications that had low SUS score. These also made the Product Managers more comfortable with the score as they could identify with the issues instead of merely being provided with a number.

Conclusion
The SUS score proved to be a good indicator to measure usability of applications across the organizations and also provided benchmarks to compare against. The subjective data collected through the open ended questions were found to be in agreement with the score, i.e. applications with high SUS score had positive feedback, with lot of features in the likable category and vice-versa.

Though SUS is a good indicator of usability it is not meant as a replacement for other usability practices and processes. Its use is to supplement them and provide a uniform measure of usability. However it cannot replace usability testing as it does not identify the problems and the reasons for them. It is merely an indicator of usability measured by attitude scales depending on the scores from the respondents. In our case we did provide three open ended questions, which gave us some idea about the problems or issues faced by the end users, but to get accurate and correct data user observations and usability testing were recommended as these observations were mere indicators of what could be wrong with the application, with low scores. To identify the actual usability issues end user observations and usability testing were recommended.

References

1 Finstand, Kraig. The System Usability Scale and Non-Native English Speakers – Journal of Usability Studies, Vol. 1, Issue 4, August 2006, pp. 185-188.

2 Brooke, J. SUS: a “quick and dirty” usability scale. In P W Jordan, B Thomas, B A Weerdmeester & A L McClelland (eds.) Usability Evaluation in Industry. London: Taylor and Francis. (1996)

3 Tullis, T.S., & Stetson, J.N. A comparison of Questionnaire for Assessing Website Usability. (2004)

4 Bevan, N, Kirakowski, J and Maissel, J, 1991, What is Usability? in H.-J. Bullinger, (Ed.). Human Aspects in Computing: Design and use of interactive systems and work with terminals, Amsterdam: Elsevier.

5 Kirakowski, J and Corbett, M, 1988, Measuring User Satisfaction, in D M Jones and R Winder (Eds.) People and Computers IV. Cambridge: Cambridge University Press.

SUS was designed by John Brooke for Digital Equipment Corporation