Usability Engineering

Usability Engineering

Contents • Usability Engineering • Know the user • Task analysis • Usability metrics • The usability engineering process

Usability Engineering • Usability Engineering tries to make the product suit the task for which it was designed • This involves not just the functionality of the product but the ergonomic considerations that make a product easy to use

Usability Engineering • Usability engineering depends on understanding three aspects of a product • Know the user • Know the task • Know the environment • If all of these are understood, you will be able to design a better product

The Need for Usability Engineering • We have all seen products which are cumbersome and confusing to operate • Other products are obvious in how to use them and a joy to use • One product is preferred over another based on its ease of use, even though functionality is the same • Usability engineering can help turn a poorly designed product into a well designed one

The Need for Usability Engineering • The ease of use of a product has a major impact on how well that program will do in the market • The ease of use of a product is one area where one manufacturer can distinguish their product from competing products

The Need for Usability Engineering • Only 30% of IT systems are successful • The rest fail to produce the expected productivity increases • Often, the failure to produce expected results is a lack of ease of use that hinders attempts to use the product

The Need for Usability Engineering • How does one determine if a product meets the needs of the user? • How does one determine if a product is easy to use? • You cannot produce a quality product until you can answer these questions • Usability engineering addresses these questions

Usability Engineering:A Definition • “…the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in particular environments…” ISO DIS 9241-11

Usability Engineering:A Definition • “…a process whereby the usability of a product is specified quantitatively and in advance. Then as the product itself, or early ‘baselevels’ or prototypes of the product are built, it is demonstrated that they do indeed reach the planned levels of usability.”D. Tyldesley, Employing Usability Engineering in the Development of Office Products, in Human Computer Interaction, Preece & Keller (eds), Prentice Hall, 1990

Know the User • The first job is to discover who the end user of the system will be • Once you have identified the user, you must determine • What level of expertise they have • What they will assume about the system • What is the environment in which they will use the system

End User Classes • It is often helpful to be able to break the users into classes • Of course, there are several axes which can be used for user classification • We will consider two axes: • How they use the system • The level of user expertise

Classification by System Usage • Direct Users • Make direct use of the system to carry out their duties • Data entry clerk or secretary who uses a word processor • Indirect Users • Ask other people to use the system on their behalf • A passenger who asks a travel agent to check the availability of a flight

Classification by System Usage • Remote Users • Uses who do not use the system themselves but depend on services it offers • Bank customers depend on the bank systems for their account statements • Support Users • Members of the administrative and technical teams which support the system • Help desk staff, administrators, technicians

Classification by System Usage • We identify two extra categories which might overlap the previous categories • Mandatory Users • Those who must use the system as part of their job • Discretionary Users • Do not have to use the system as part of their job • Might make infrequent use of the system • Probably have less familiarity with the system

Classification by Expertise • Categorizes users as • Novice, intermediate, or expert • These categories can be further decomposed into • mandatory, discretionary, and intermittent users • Categorizing users allows us to generalize across types and eases design and development

Classification by Expertise • Novice users • Have little or no experience with computers • Might be hesitant to use a computer • Need feedback that they are doing things the right way • Like to progress at their own speed • System must be robust to deal with a user who does know what he/she is doing

Classification by Expertise • Novice Users • Users need to be guided through processes • Need the availability of human help • Lists of answers to common questions and problems can be created • Actions should not have side effects so that the system is easier to learn and understand • In large systems, more complex areas can be hidden from the user unless they are needed, making the interface simpler to deal with

Classification by Expertise • Intermittent Users • Use the system occasionally with possibly long periods without using it • Display both novice and expert characteristics • Often remember general concepts but not low-level details • Need access to good manuals and help facilities

Classification by Expertise • Expert Users • Require less help • Perform many operations for the first time • Make extensive use of help systems • Should be provided with accelerator keys so that they have a faster alternative to menus • Should be allowed to customize their typed commands to make interface look like others they know

Gathering Information about Users • To know the user one must gather information about the user • This can be done by • Formal & informal discussion • Observation • An expert on the design team • Questionnaire • Interview

Formal & Informal Discussion • Talking to users will reveal many unknown details about how they work and their environment • Although users are not design experts, they have insights into which designs will work for them • Talking to users makes them feel part of the design process • Making users part of the process causes them to want the project to succeed whereas leaving them out often makes them wish it would fail

Understanding the User’s Workplace • Before designing a system, you must know the environment in which it will be used • For example, secretaries said that they did not want audible alerts when a mistake was made since they did not want others in the office to know

Understanding the User’s Workplace • When you interview a worker’s boss you find out • How the boss thinks the job is done • How the job used to be done • How the boss wants the job done • When you observe the worker in his/her own environment, you find out how the job is actually done

Expert on the Design Team • This involves putting one of the end users on the design team • This person can provide valuable insight into the needs of the users • If the user spends too much time on the design team, they become a designer, not a user • Therefore, the user on the design team is often rotated to keep them representative

Questionnaires • Questionnaires are good for subjective responses – less good for objective ones • Questionnaires produce large amounts of data which can take a long time to analyze • Creating a good questionnaire is very time consuming

Questionnaires • Questionnaires can be either • Interviewer administered • Interviewer can explain meaning of questions • Very time consuming • Different interviewers must treat subjects in the same way • Self administered • Does not stop some groups answering a particular way if they have an axe to grind • Questions have to be clear to avoid misinterpretation • Faster than interviewer administered

Questionnaires • Questions can be either • Open • Gain broader information by allowing respondents to answer in any way they choose • Produces so much data that it can be difficult or impossible to interpret • Closed • Restricts answers to a few possibilities • Can distort the answers by suggesting responses the respondent would not have thought of on their own

Problems Designing Questionnaires • Questionnaires must be prototyped and tested before being administered • This will pick up • Misinterpretation of questions • That additional material is needed to understand a question • Questions not worded precisely • Questions that bias the respondent. • Eg. Giving a list of computer applications the respondent knows might cause them to tick off more so that they seem more competent

Questionnaire Types • The simplest questionnaire selects yes/no or from a limited set of responses * Usability Engineering, Xristine Faulkner, Macmillan, 2000

Questionnaire Types • Checklists are useful when there are multiple possible responses • They also have the advantage that the user does not have to remember which aspects of the system they have been using * Xristine Faulkner

Questionnaire Types • Scalar questionnaires ask the user to register an opinion on a scale • If there is a middle position on the scale, it allows the user to register “no opinion” • This might be a good thing or bad, depending on the question * Xristine Faulkner

Questionnaire Types • A Likert scale is used to gather the strength of an opinion * Xristine Faulkner

Questionnaire Types • A ranked order questionnaire asks users to rank a set of responses based upon some criteria * Xristine Faulkner

Observation • Observation can be a very useful tool to find out how people actually work • One of the major dangers is that the users alter their behaviour when they know they are being observed • The Hawthorne effect was noticed on a study of electrical workers when it was observed that productivity increased as light level were reduced to the point where workers could no longer see

Observation • There are two ways to circumvent the Hawthorne effect • Expose the users to the observer for a long period of time until they ignore the observer • Use videotape to record the workers without an actual observer being present • In most cases, acclimating the users to the observer produces the best results

Observation • Video tape takes a long time to set up and often records far more than is necessary • This makes it less effective than just recording a couple minutes of crucial activity • Users behaviour is changed as much by the act of videotaping as by being observed by a human directly • Generally, the use of videotape is less effective than it was anticipated to be

Activity Logging • This involves simply logging what the user does and how long it takes • The logging can be done by • The user, although this affects performance • An observer • The computer system itself

Activity Logging • Using an observer is effective but the user will have to become acclimatized to the presence of an observer • If the system does the logging, the user must be told of this • This is required ethically and is enforced by law in some areas • A period of acclimatization will be necessary for system based logging as well

Interviews • Interviews can range from open ended questions to closed question, with every variation in between • Open ended questions • Useful when first starting interviews • Useful when the interviewer does not know what to ask • Let’s the interviewer refine and direct the questions as the interview proceeds • Often uncovers new facts

Interviews • Closed questions • The interview is directed by the interviewer • Only a limited range of responses are obtained • The interview time is reduced • Mixed Questions • This uses closed questions but allows the interviewee to add additional thoughts • The interviewer can also add questions or direct the interview in new directions • This is often the most effective interview style

Task Analysis • A task is some human activity which will achieve a goal • The result of task analysis is to gain an understanding of what a system should do • A task is decomposed into a hierarchy of subtasks • Good design can be performed once the user’s tasks have been understood

Task Analysis • A task consists of • An input • An output • A process to convert the input to output Output Input Transformation

Task Analysis • In order to break a task into subtasks, we must ask a series of questions • What information is needed to perform the task? • What are the characteristics of the information sources? (reliable, wrong format, etc.) • What affects the availability of the information?

Task Analysis • What are the errors which might occur? • The goal is to design a system which can avoid the errors • What initiates the task? • Often a task depends on the completion of a previous task before it can begin • The questions about the input should be followed by questions about the output

Task Analysis • What are the performance requirements? • What happens to the output? • This will determine if the output is sent to another process and whether it needs to be in a certain format • How does the user get feedback on the progress of the task? • Then, we need to ask questions about the transformation

Task Analysis • What are the decisions which are made by the entity performing the transformation? • What are the strategies for decision making and how can these be incorporated into the new system? • What skills are needed for the task? • Users of the system will need to be trained and kept up to date with these skills • What interruptions can occur and when can they occur?

Task Analysis • How often is the task performed and when is it performed? • Does the task depend on another task? • What is the normal and maximal workload? • This will allow you to design a system to deal with this load • Can the user control the task workload? • Sometimes the user can delay a task or control the flow of data to a task

Usability Engineering