A HTA can be represented by a structued, indented text, or using a structured chart notation. A text variant of the above structured chart may be: • 0. To photocopy a sheet of A4 paper: 1. Enter PIN number on the photocopier 2. Place document face down on glass 3. Select copy details 1. Select A4 paper 2. Select 1 copy 4. Press copy button 5. Collect output • Plan 0: Do 1-2-4-5 in that order; when the defaults are incorrect, do 3 • Plan 3: Do any of 3.1 or 3.2 in any order; depending on the default settings We can consider different types of plan: • fixed sequence (e.g., 1.1 then 1.2 then 1.3) • optional tasks (e.g., if the pot is full then 2) • wait for events (e.g., when the kettle boils, 1.4) • cycles (e.g., do 5.1-5.2 while there are still empty cups) • time-sharing (e.g., do 1 and at the same time, do 2) • discretionary (e.g., do any of 3.1, 3.2 or 3.3 in any order) • mixtures - most plans involve several of the above Is waiting part of a plan, or a task? Generally, task if busy wait - you are actively waiting or a plan if the end of the delay is the event, e.g., when alarm rings, etc... To do HTA, you first need to identify the user groups and select representatives and identify the main tasks of concern. The next step is to design and conduct data collection to elicit information about these tasks: • The goals that the users are trying to achieve • The activities they engage in to achieve these goals • The reasons underlying these activities • The information resources they use This steps can be done with documentation, interviews, questionnaires, focus groups, observation, ethnography, experiments, etc... The data collected then needs to be analysed to create specific task models initially. Decomposition of tasks, the balance of models and the stopping rules need to be considered. The specific tasks models then should be generallised to create a generic task model - from each task model for the same goal, produce a generic model that includes all the different ways of achieving the goal. Models should then be checked with all users, other stakeholders, analysts and the process should then iterate. To generate a hierarchy, you need to get a list of goals and then group the goals into a part-whole structure and decompose further where necessary, applying stopping rules when appropriate. Finally, plans should be added to capture the ordering of goal achievement. Some general things to remember about modelling are: • Model specific tasks first, then generalise • Base models on real data to capture all the wonderful variations in how people do tasks • Model why people do things, as well as how • Remember, there is no single, correct model • Insight and experience are required to analyse and model tasks effectively and to then use the models to inform design When you are given an initial HTA, you need to consider how to check/improve it. There are some heuristics that can be used: • paired actions (for example, place kettle on stove can be broken down to include turning on the stove as well) • restructure • balance • generalise There are limitations to HTA however. It focuses on a single user, but many tasks involve the interaction of groups to people (there is a current shift towards emphasising the social and distributed nature of much cognitive activity). It is also poor at capturing contextual information and sometimes the why information and can encourage a focus on getting the model and notation right, which detracts from the content. There is a danger of designing systems which place too much emphasis on current tasks or which are too rigid in the ways they support the task. There are many sources of information that can be used in HTA. One such is documentation - although the manuals say what is supposed to happen, they are good for key words and prompting interviews, and another may be observation (as discussed above) and interviews (the expert: manager or worker? - interview both). We could also consider contextual analysis, where physical, social and organisational settings of design need to be investigated and taken into account in design. For example: • physical (dusty, noisy, light, heat, etc...) • social (sharing of information/displays, communication, privacy, etc...) • cultural (etiquette, tone, reading/scanning style, terminology, data formats, etc...) • organisational (hierarchy, management style, user support, availability of training, etc) GOMS GOMS is an alternative to HTA that is very different. It is a lot more detailed and in depth and is applied to systems where timing and the number of keystrokes are vital. It is more complex to use than HTA, and it is not common. GOMS is an acronym for: • Goals - the end state the user is trying to reach; involves heirarchial decomposition into tasks • Operators - basic actions, such as moving a mouse • Methods - sequences of operators or procedures for achieving a goal or subgoal • Selection rules - invoked when there is a choice of methods Prototyping Users often cant say what they want, but as soon as you give them something and they get to use it, they know what they dont want. A bridge is needed between talking to users in the abstract about what they might want and building a full-blown system (with all the expense and effort that involves). The prototype is that bridge, it might be a paper-based outline of screens, a video simulation of interaction or a 3D cardboard mock-up of a device. Prototypes are very useful for discussing ideas with stakeholders, and it encourages reflection on the design and allows you to explore alternative designs without commiting to one idea and to make ideas from scenarios that are more concrete. Low fidelity (lo-fi) prototypes are not very like the end product and are very obviously rough and ready. They are cheap and simple to make and modify and it makes it clear to stakeholders that they can be criticised. They are fairly low risk; designers do not have much to risk with them, but they do not allow realistic use. One form of lo-fi prototyping is storyboarding, a technique used in the film industry. A series of sketches, usually accompanied with some text (e.g., a scenario), show the flow of interaction. This is useful if youre good at sketching, otherwise it can be daunting. Another method is using paper screenshots, where a sheet of paper or an index card is used for each page, and overview diagrams can be used to show links between screenshots. Some tools (such as Denim and Silk) exist to support this process, but they can keep the sketchy look of the prototype. Another method is the Wizard of Oz system. In the 1980s, a prototype system was created for speech recognition. At the time, speech recognition was not currently available, so a fake system was used, where a human actually did the recognition. The term is now used for any system where the processing power is not implemented and a human fakes it. There is no need to deceive the user for a Wizard of Oz system as it can work perfectly well if the user knows it is a Wizard of Oz system. High fidelity prototyping uses materials that you would expect to find in the end product or system and looks much more like the final system. For software, people can use software such as Macromedia Dreamweaver or Visual Basic, or in the case of web pages, writing prototype HTML code. With high-fidelity prototyping, you get the real look and feel of some of the functionality, it serves as a living specification, it is good for exploration of design features and evaluation and it is a good marketing and sales tool. It can be quite expensive and time-consuming however, especially if radical changes are possible; developers are often unwilling to scrap high-fidelity prototypes. Evaluators tend to comment on superficial design features rather than real design and user expectations can be set too high. When creating prototypes, you have to consider depth vs. breadth - do you prototype all of the functionality, but then not go into any specific detail (horizontal prototyping), or do you prototype one or more functions, but in a lot of depth (vertical prototyping). Evolutionary prototyping also exists, which is where you build the real system bit by bit and evaluate as you go along, and the opposite is throw-away prototyping, which is where a prototype is built in one system (perhaps repeatedly with changes), and then that thrown is totally thrown away and the real system is built from scratch (sometimes for efficiency, security, etc...). A final type of prototyping is experience prototyping, where using prototypes allows the designers to really understand the users experience, e.g., using a wheelchair for a day for different technologies like ATMs, etc... Cha-cha Yap Poquita
Posted on: Sun, 23 Nov 2014 11:10:50 +0000
Trending Topics
Recently Viewed Topics
© 2015