1. User-Interface Design Process Lecture # 6 1Gabriel Spitz

2. What is Process A process is a: o Collection of tasks or steps that are tightly related o Initiated in response to a need or a specific issue o Achieves specific result for the customer of the process A process is a way or the set of steps to solve a problem Gabriel Spitz2 Information Technology and Services Syracuse University

3. User Interface Design Process Gabriel Spitz3 Needs Assessment Competitive Analysis Persona Develop Task Analysis Mock Design Workflow Design Conceptual Design Wireframe Design Formative Evaluation Mockup Design Prototype Design Requirements Development Design Evaluation Mock Design Summative Evaluation

4. UI Design process - Iterative Design Use wireframes for early concepts Later concepts use richer implementations Every concept is evaluated – Users involved in all iterations More iterations generally means better UI Gabriel Spitz4

5. Why Follow the UI Design Process To ensure that the problem is resolved To ensure that the resolution meets usability criteria To ensure a quality team work Gabriel Spitz5

6. Requirements Development Gabriel Spitz6

7. Why Articulate Requirements Many IT projects fail because their design is based on an inappropriate, and/or incomplete set of requirements Such products solve the wrong set of problems, or the right set of problems in the wrong way For example: o Movie ticket kiosk – Selling tickets vs. Getting you into the show o Newton – was just too large & heavy o Others? Gabriel Spitz7

8. 8 Apple Newton MessagePad (1993) Was -Large-7.5”X4.5”X0.75 -Heavy-480 gr -Expensive-$1000 Palm Pilot -Size- 4.7X3.2X0.7 -Weight-160 gr -Price-$300

9. Solving the Wrong Problem - Example Gabriel Spitz9 Locate a CMVS. Locate a Problem

10. Requirements Requirements statements specify: o What the product should do – Functional req. Store personal contact information Enable users to add delete and modify contact info. Print contact information …. o How it should do it – Non-functional req. Contact info should be organized as a “ business card ” Contact name and title should appear in bold type face …. Gabriel Spitz10

11. Requirements Development Get in touch with real people who will be potential users of our system prototypical categories extremes Learn about their real tasks o articulate concrete, detailed examples of tasks they perform or want to perform that your system should support routine infrequent but important infrequent and incidental Gabriel Spitz11

12. Iterative Design Helps meet users requirements by o Iteratively designing the UI and evaluating it with actual or potential users we force the issue of requirements to the front o By identifying requirements through systematically modeling users ’ roles, tasks flows associated with each role and information needs for each task Gabriel Spitz12

13. Usability Requirements … Are user related goals that were established prior to UI design Often are based on results with other systems To be useful should be: o Specific o Unambiguous o Clear Gabriel Spitz13

14. Generating Requirements Requirements do not happened Requirements do not exist out there Requirements are often difficult to identify Requirements need to be developed Gabriel Spitz14

15. Steps in Developing Requirements Developing requirements involves o Gathering data o Interpreting the data o Extracting requirements This sequence of steps is iterative and therefore requirements evolve over time Gabriel Spitz15

16. Gathering Data To understand users and their tasks we need to gather data about how users: o Think o Act o Feel o Adapt Within the context of interacting with the target system or its predecessor Gabriel Spitz16

17. Criteria of Data Gathering Ensure that sufficient, and appropriate data is available to develop a stable and comprehensive set of requirements The scope of data gathering efforts should be wide enough to ensure effective coverage of the different aspects of the applications ’ use Data gathering should include information about users, their tasks, and the environment in which tasks will be performed Gabriel Spitz17

18. Data Gathering Techniques Only a few basic techniques are generally used to gather behavioral data These techniques, however are flexible and can be combined in a variety of way to ensure effective coverage of the design space The most common techniques include: o Observations – Watch people at work o Interviews – Talk to people o Questioners – Ask people specific questions o Review documentation – Read about their work Gabriel Spitz18

19. Observations Involves watching and recording how users actually performs a function or a set of tasks Often conducted at the workplace of the user Observations are very effective when the task involved is primarily physical For tasks that are primarily cognitive we should add “ talk aloud ” o Ask the operator to articulate what s/he is doing and why Gabriel Spitz19

20. Good Task Examples Focus on what users want to do not on how they will do it Are specific Describe a complete job Specify who the users are Are evaluated As a set, identify a broad range of users and task types Gabriel Spitz20

21. If Tasks Do Not Exist If all else fails … o describe your expected set of users, o describe your expected set of tasks These will become your ‘ assumed users and tasks ’ o verify them later as information comes in o modify them as needed Gabriel Spitz21

22. If There Is No System Yet If there are no real users or tasks … o think again, there probably are! Jeff Hawkins, the inventor of the Palm Pilot, was said to have carried a small block of wood around in his shirt pocket … As various everyday situations arose, he would take out the block of wood and imagine how he would use the device. 1 Gabriel Spitz22 1 see Sato and Salvador, interactions 6(5)

23. Interview One on one interaction between a designer and a user Often it is a face to face interaction but can also be over the phone or a “ chat room ” Interviews can be either structured or unstructured Task related interviews are most effective when conducted at the work place o Users find it easier to point at an object and use gestures than verbally articulate actions or object Gabriel Spitz23

24. Questionnaire Requires active user participation Intended to elicit specific information Questionnaire come in different forms o Open ended o Multiple choice o Yes/no Suitable for gathering information from a large group of people distributed over a wide geographic area Require careful design and evaluation Gabriel Spitz24

25. Review of Documentation Involves reading available user-guides, FAQ, help files, etc. and developing an understanding of what users do and need Documentations is a good source of information about available functions, features and procedural aspects of tasks Should be used as a first line of attack in developing requirements But should not be used as the only method of data gathering Gabriel Spitz25

26. Usage of Data Gathering Methods Observation o Develop a detailed understanding of tasks, and procedures in the real world – How is it used Interview o Explore issues and develop use scenarios – What is missing Questionnaires o Gather specific information Documentation review o Develop a high level understanding of features, task, and procedures – what is there Gabriel Spitz26

27. Choosing Data Gathering Method Most of the time we use all methods during the UI design Invocation of a specific method is driven by: o The type of information that is needed General understanding, specific data, …. o Availability of resources Money, time, people, …. o Access to users Gabriel Spitz27