HCI Goals. The aim of HCI research is to make computer interfaces more accessible and user friendly.

As a result a number of goals have been formulated to guide programers in creating their interfaces so as to maximize their effectiveness. They are listed below with a brief explanation.

Proper functionality: the program works as it is expected to, e.g. a word processor is for typing documents into not playing games on. Consistency: a control works the same way every time it is encountered, it's function does not change inside the program. For example, a user always clicks a button, they do not click it sometimes and type text into at other times. Standardization: seeks consistency across programs so that, for example, a user could learn one word processor and then be able to use any word processor available to them, i.e. learn Microsoft Word and then be able to sit down and use Corel Wordperfect and ClarisWorks with a minimum of effort. Reliability: the program works without a flaw, it does not lock up or crash. Microsoft Windows 95 is a good example of an unreliable program, it crashes fairly often. Security and Data Integrity: the program protects the users' data from unwanted tampering and alteration. Hackers and viruses are two of the most common threats to security and data integrity however flaws in the programs code (bugs) can also alter and/or destroy users' data without warning. Integration: seeks to use multiple programs in conjunction with one another, e.g. Microsoft Office. In Office, you can type a document in Word and then insert a spreadsheet into the document or insert the document into a Power Point presentation. This is integration. Portability: is the least achieved goal of the eight presented here. Portability refers to the ability to use one program on multiple operating systems without recompiling it for every system, i.e. be able to install and use Microsoft Office off the same CD on Macintosh, Linux, and Windows 95 machines. Availability: is so obvious it is usually overlooked but is probably the most important goal. Availability is the principle that if users cannot find or access a program they will not use it but if it is readily available, especially if it is more available that its competition, a user is more likely to use the program. On the UVA campus the Simeon email client is a good example of an available program. It is available on practically every computer on grounds because it is on the network, therefore the vast majority of students use it over other email clients, such as Microsoft Outlook and Netscape Messenger.

What is User-Centered Design?

User-centered design (UCD) is an approach to design that grounds the process in information about the people who will use the product. UCD processes focus on users through the planning, design and development of a product.

An International Standard

There is an international standard that is the basis for many UCD methodologies. This standard (ISO 13407: Human-centred design process) defines a general process for including humancentered activities throughout a development life-cycle, but does not specify exact methods.

In this model, once the need to use a human centered design process has been identified, four activities form the main cycle of work: 1. Specify the context of use Identify the people who will use the product, what they will use it for, and under what conditions they will use it. 2. Specify requirements Identify any business requirements or user goals that must be met for the product to be successful. 3. Create design solutions This part of the process may be done in stages, building from a rough concept to a complete design. 4. Evaluate designs The most important part of this process is that evaluation - ideally through usability testing with actual users - is as integral as quality testing is to good software development.

The process ends - and the product can be released - once the requirements are met.
A Typical UCD Methodology

In this version, the UCD activities are broken down into four phases: Analysis, Design, Implementation and Deployment, with suggested activities for each phase. They are: Analysis Phase

Meet with key stakeholders to set vision Include usability tasks in the project plan Assemble a multidisciplinary team to ensure complete expertise Develop usability goals and objectives Conduct field studies Look at competitive products Create user profiles Develop a task analysis Document user scenarios Document user performance requirements

Design Phase

Begin to brainstorm design concepts and metaphors Develop screen flow and navigation model Do walkthroughs of design concepts Begin design with paper and pencil Create low-fidelity prototypes Conduct usability testing on low-fidelity prototypes Create high-fidelity detailed design Do usability testing again Document standards and guidelines Create a design specification

Implementation Phase

Do ongoing heuristic evaluations Work closely with delivery team as design is implemented Conduct usability testing as soon as possible

Deployment Phase

Use surveys to get user feedback Conduct field studies to get info about actual use Check objectives using usability testing

Guidelines for User-Centered Design

User-Centered Design (UCD) is a broad approach to technology design, in which the constraints and desires of the eventual user of the technology are taken into account throughout the design process. It might seem obvious that user needs should be taken into account, but in practice, many engineers and software developers end up focusing so much on technology and features, that they forget to incorporate actual users into the invention and development process. Although there are many schools of thought about how to do good UCD, most recommend steps like the following . 1) Spend time with actual users or potential end-users to identify challenges they face, often with respect to a particular issue. 2) Prototype potential solutions. 3) User-test to see how the prototypes work or dont work. 4) Iteratively prototype and test, repeating steps 2 and 3. 5) Conduct a rigorous user study of your best solution. (Optional, but recommended )

Task analysis
Task analysis analyses what a user is required to do in terms of actions and/or cognitive processes to achieve a task. A detailed task analysis can be conducted to understand the current system and the information flows within it. These information flows are important to the maintenance of the existing system and must be incorporated or substituted in any new system. Task analysis makes it possible to design and allocate tasks appropriately within the new system. The functions to be included within the system and the user interface can then be accurately specified.

Benefits
Provides knowledge of the tasks that the user wishes to perform. Thus it is a reference against which the value of the system functions and features can be tested. But note that according to the USERfit guide: The reader should be aware that task analysis can be a very time consuming activity if used with a high degree of detail on complex problems. ... It is possible to get caught in what is loosely termed analysis paralysis, where more and more detail is investigated.

Method
Task decomposition

The aim of high level task decomposition is to decompose the high level tasks and break them down into their constituent subtasks and operations. This will show an overall structure of the main user tasks. At a lower level it may be desirable to show the task flows, decision processes and even screen layouts (see task flow analysis, below) The process of task decomposition is best represented as a structure chart (similar to that used in Hierarchical Task Analysis). This shows the sequencing of activities by ordering them from left to right. In order to break down a task, the question should be asked how is this task done?. If a sub-task is identified at a lower level, it is possible to build up the structure by asking why is this done?. The task decomposition can be carried out using the following stages: 1. Identify the task to be analysed. 2. Break this down into between 4 and 8 subtasks. These subtasks should be specified in terms of objectives and, between them, should cover the whole area of interest. 3. Draw the subtasks as a layered diagram ensuring that it is complete. 4. Decide upon the level of detail into which to decompose. Making a conscious decision at this stage will ensure that all the subtask decompositions are treated consistently. It may be decided that the decomposition should continue until flows are more easily represented as a task flow diagram. 5. Continue the decomposition process, ensuring that the decompositions and numbering are consistent. It is usually helpful to produce a written account as well as the decomposition diagram. 6. Present the analysis to someone else who has not been involved in the decomposition but who knows the tasks well enough to check for consistency.

User Analysis
The reason for user analysis is straightforward: since youre not the user, you need to find out who the user actually is. User analysis seems so obvious that its often skipped. But failing to do it explicitly makes it easier to fall into the trap of assuming every user is like you. Its better to do some thinking and collect some information first. Knowing about the user means not just their individual characteristics, but also their situation. In what environment will they use your software? What else might be distracting their attention? What is the social context? A movie theater, a quiet library, inside a car, on the deck of an aircraft carrier; environment can place widely varying constraints on your user interface. Other aspects of the users situation include their relationship to other users in their organization, and typical communication patterns. Can users ask each other for help, or are

they isolated? How do students relate differently to lab assistants, teaching assistants, and professors?

User Classes
Many, if not most, applications have to worry about multiple classes of users. Some user groups are defined by the roles that the user plays in the system: student, teacher, reader, editor. Other groups are defined by characteristics: age (teenagers, middle-aged, elderly); motivation (early adopters, frequent users, casual users). You have to decide which user groups are important for your problem, and do a user analysis for every class.

Personas
One popular technique for summarizing user classes is to give each user class a fictional representative, with typical characteristics and often a little back story. These representatives are called personas. Personas are useful shorthand for a design group; you can say things like lets think about how Yoshi would do this, rather than a mouthful like non-English-speaking athlete. They also help focus attention on typical members of the user class, rather than extremes. And by putting a human face on a user class, albeit an imaginary one, they can encourage you to have more empathy for a user class thats very different from your own. (Alan Cooper, The Inmates are Running the Asylum, 1999). Some cautions: a badly-chosen persona, an extreme case, won't help focus on the typical user. And it's shorthand, so you're abstracting away the richness and diversity of the user class into a specific example. It's not too bad for scalar properties like age or education level, where a mean or median value has some meaning, but what do you do for categorical properties like gender? Say you have a user class that's 35% male and 65% female. Do you use a female persona, at the risk of ignoring the guys? Or do you split it into two user classes, and run the risk of designing for gender differences that really aren't relevant? Personas are essentially stereotypes. Technically, you want a persona to be a stereotype; it should typify its user class. But we all know the dehumanizing effects of stereotyping, so you also want the persona to be like a human being, an individual that you respect and love. So each persona implicitly has two parts: the stereotypical part, and the "color" we added to make it a real person. For example, Franny is an 8-year old child (typical of some user class), who happens to be a girl, lives in Chicago, and likes drawing bunnies and mushroom clouds (but those parts aren't typical for the class, nor do they really matter for our design). Everybody on the design team has to implicitly know what part of the persona matters and what doesn't.

Task Analysis

The best way to do user analysis is to find some representative users and talk to them. Straightforward characteristics can be obtained by a questionnaire. Details about context and environment can be obtained by interviewing users directly, or even better, observing them going about their business, in their natural habitat. Sometimes it can be hard to reach users. Software companies can erect artificial barriers between users and developers, supposedly for their mutual protection. After all, if users know who the developers are, they might pester them with bugs and questions about the software, which are better handled by tech support personnel. The marketing department may be afraid to let the developers interact with the users not only because geeks can be scary (and sometimes obnoxious), but also because usability discussions may make customers dissatisfied with the current product. (I hadnt noticed it before, but that DOES suck!) But this isnt a good idea. Developers should interact with users, if only so that they learn that their users are intelligent human beings with real goals, not just idiots who cant find the Any key. Some users are also expensive to find and talk to. Nevertheless, make every effort to collect the information you need. A little money spent collecting information initially should pay off significantly in better designs and fewer iterations.

The next step is figuring out what tasks are involved in the problem. A task should be expressed as a goal: what needs to be done, not how. One good way to get started on a task analysis is hierarchical decomposition. Think about the overall problem youre trying to solve. Thats really the top-level task. Then decompose it into a set of subtasks, or subgoals, that are part of satisfying the overall goal.