You are on page 1of 8


What is a PACT Analysis?

Design Process

 People: relevant user characteristics and skills  Activities: how is the activity currently carried out? Why?

What can be improved?
 Context: the environment of the activity  Technologies: what tools are used now, and how might

new developments be used?

 week2

 week2

People, Activities, Context, Technology (PACT)
 People undertake activities, in contexts using

What is a PACT Analysis?


 A student uses a phone to send a text message

whilst sitting on a bus

 Air traffic controllers work together using

computers and flight strips to ensure smooth running of an airport in the air traffic control centre.  A 70-year-old woman presses various buttons to set the intruder alarm in her house.  It is the variety in each of the PACT elements - and their combination - that makes interactive systems design so fascinating

 week2

 week2


infrequent tasks should be easy to learn or remember Well-defined or vague Continuous or interrupted . hearing. learning abilities.frequent tasks should capabilities in sight. different Activities  Goals. pleases and engages .…  Psychological differences”: -Different ways of working. different amounts of attention at different times. physical abilities. tasks and actions  Regular or site users are (normally) heterogeneous . then interface must be particularly 'helpful' as users will forget how to complete complicated tasks. cognitive capabilities.blindness. memory. different memory abilities. In the US a tick is used for acceptance and the cross rejection. differences in designing for a heterogeneous group or a homogeneous group    be easy to do. weekly? Yearly? . ability to recognize things or remember things.novice v's expert Language Culture .if users are normally infrequent. one labeled with a cross and the other a tick. People  Special needs . but in Ireland a tick or a cross can be used to show acceptance (e.  week2  week2 People  Physical differences:-Height. deafness. wheel chair      perception. What motivates.affect Experience & expectations . discretionary users of technologies. spatial ability. users of a company's intranet are (generally) homogenous  Discretionary vs committed users . weight.g.For example.does the user have a choice? if yes. a cross on a ballot paper).level and duration of attention. user  Homogenous vs heterogeneous user groups . touch. fears.  week2  week2 2 .10/14/2010 People  Cognitive characteristics . in Microsoft Excel there are two buttons. then you need to encourage them to return  Infrequent vs frequent users .age differences. personality characteristics Physical characteristics .many different types of people. colour blindness.user may need to 'find their place' again Current task practices Individual vs co-operative work Multi-tasking vs serial tasks Passive vs active. Different „mental models‟     Usage differences:-Experts versus novices.

cold. tasks and actions  Regular or unusual.presentation of error messages. how to deal with them.presentation of error messages. structure. significance of errors. significance of errors.peaks and troughs of  Context Physical environments . how the system accommodates them.user may need to 'find need for fast response  Coping with errors . how to deal with them.frequent tasks should be easy to do. dirty. mobile. weekly? Yearly? .peaks and troughs of working. safety critical errors  week2  week2 3 . uses dangerous materials. how the system accommodates them. infrequent tasks should be easy to learn or remember  week2 their place' again  Current task practices  Individual vs co-operative work  Multi-tasking vs serial tasks  Passive vs active. centralisation vs decentralisation. training materials working. safety critical errors Goals. Activities  Well-defined or vague  Continuous or interrupted . stressful.channels of communication. wet.10/14/2010 Activities  Quality vs quantity trade-off  Data input requirements  Length of time on tasks . sunny  Social environments .  week2 Activities  Quality vs quantity trade-off  Data input requirements  Length of time on tasks .noisy. need for fast response  Coping with errors . home.

role. speed.  Safety critical systems. between devices. video vs. security  Output . screen)  Communications .What is connected to what?  Size of screen  GUI or not?  Sound?  week2  week2 Technologies  Networked or stand alone. . deskilling. interruptible? Response time.g. other staff. Now everyone will have to buy a ticket before they travel. demonstrations.Between people.Characteristics of different displays (e. getting commands.  Always on or dial in?  Real-time systems.Getting data in. new skills photographs.relationships with customers.tuition. media  What mental model would you want to engender in people. kiosks) / Office Designing a ticket machine  Ramses station is introducing a new system of automatic barriers. co-operation? Vague/well-defined? Safety critical? Errors? Data requirements.10/14/2010 Context  Organisational context . job loss.g. effect on work practices and job content. Regular/infrequent? Peaks and troughs. new knowledge. manuals. etc. shift in power  Circumstances under which activities happen (time. place.  Walk-up-and-use systems (e. Technologies  Input . How would you design for this?  week2  week2 4 . Write down the characteristics of this activity  systems/ Palm pilot application / Web site. pressure of work/time)  Amount and type of support for activities . speech vs.

or menu items? Need to provide change?  week2  week2 5 .10/14/2010 Different Contexts of Use  Activities always take place in some context  „Context‟ sometimes means things that surround an Different Technologies  Hardware and software to consider  Input  How to enter data and commands into the system. need to specify ticket type  Press button (depending how many stations). need to provide     the activities and the people. etc. need to say when complete.  week2 Ticket Machine  So. Bandwidth.need to specify destination. Suitability of medium for different contexts/activities  Output  Characteristics of displays .„streamy‟ media versus „chunky‟ media. de-skilling. Also feedback is important  Communication  Between person and technology. Options as buttons. changes in life style. What technology will you design for the new ticket machines? Consider Input Output Communication Content payment. Printing facility needed. taking into consideration the contexts of use. Characteristics of the content. Pay by mobile phone?  Output . speed. acceptability of certain designs  Organizational context  Power structure. need to provide a ticket.need to specify options. Have touch screen (gets greasy). communication between devices  Content  Functional systems versus systems more focused on content  week2 activity and sometimes what glues an activity together  Physical environment is one sort of context  ATM or ticket machine versus computer at home  Social context is important  Help from others. Ticket Machine ideas  Input .  Ticket could be electronic or paper.

flat or bedroom.g.we could put a in.  When could you start with requirements. Could be Design Process Challenge:  Think of decorating your house. that cupboard I saw in Ikea could be used to store things in my flat. fresher. that colour would get dirty very quickly…  week2  week2 6 . here‟s a sketch of my ideas for a cupboard. Probably button presses are easiest  Content .need to specify stations.10/14/2010 Ticket Machine ideas  Communication . I want the room to be lighter. need to build a cupboard to store things in. I am going to paint the walls „apple-white‟  Start with envisionment . that cupboard would get in the way.need to create an area for working in. but it could have lots of local information.e. cleaner…  Start with conceptual design .that partition would be too expensive. Help with travel planning? conceptual design a physical design or a prototype/ envisionment?  What processes would you go through after you start?  week2  week2 Re-decorating your flat  Start with requirements . I need a space to work Re-decorating your flat  Start with a physical design .look at this person‟s flat in this magazine with a neat working area. partition up in the corner of the bedroom. I want to get rid of some clutter. Bluetooth. you know the colour of Rod‟s bedroom…  Then evaluate .must be simple. paint the walls a lighter colour.

Unlike this iterative design process. however.  It is linear. 1996. software developers have treated each The Classic Life Cycle for Software Development (Waterfall model) Sommerville.  week2 phase of the software design life cycle as an independent part of software development.10/14/2010 Classic Life Cycle for Software Development Classic Life Cycle for Software Development  Traditionally. which must be completely satisfied before moving on to the next phase. sequential. Interface Design and Evaluation Process Greenberg.  week2 User-Centered Iterative Design User-Centered Iterative Design  The essential difference between the classic life cycle and user-centered interface design is that user interface design and development is based on the premise that users should be involved throughout the design life cycle. the process should be highly iterative. This view is simplistic. Moreover. the development stages overlap and feed information to each other. the waterfall life cycle generally leaves evaluation to the end. systematic.  Additionally.  In practice. so that the design can be tested (or evaluated) with users to make sure it meets the users‟ requirements.  week2  week2 7 . 1995. there are many iterations up and down between stages.

Key features  Evaluation is central to designing interactive systems. for example. sometimes we start with a prototype. 1993. Everything gets evaluated at every step of the process  The process can start at any point – sometimes there is a conceptual design in place. plus inside-out and outside in development”  week2 8 .  week2  week2 Star Life Cycle  the star life cycle is “intended to be equally supportive of both top-down and bottom-up development. sometimes we start with requirements  The activities can happen in any order. requirements might be evaluated and a prototype built and evaluated and some aspect of a physical design might then be identified Star Life Cycle (Evaluation-centered) Hix and Hartson.10/14/2010 Star Life Cycle Star Life Cycle .