User-Interface Design Process

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

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

3. User Interface Design Process Requirements Development NeedsAssessment Competitive Analysis PersonaDevelop Task Analysis Design MockDesign PrototypeDesign WorkflowDesign ConceptualDesign WireframeDesign Formative Evaluation MockupDesign Evaluation MockDesign Summative Evaluation Gabriel Spitz

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 Spitz

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 Spitz

6. Requirements Development Gabriel Spitz

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: • Movie ticket kiosk – Selling tickets vs. Getting you into the show • Newton – was just too large & heavy • Others? Gabriel Spitz

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 Gabriel Spitz

9. Solving the Wrong Problem - Example Locate a CM VS. Locate a Problem Gabriel Spitz

10. Requirements • Requirements statements specify: • What the product should do – Functional req. • Store personal contact information • Enable users to add delete and modify contact info. • Print contact information • …. • 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 Spitz

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 • 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 Spitz

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

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: • Specific • Unambiguous • Clear Gabriel Spitz

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 Spitz

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

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

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 Spitz

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: • Observations – Watch people at work • Interviews – Talk to people • Questioners – Ask people specific questions • Review documentation – Read about their work Gabriel Spitz

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” • Ask the operator to articulate what s/he is doing and why Gabriel Spitz

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 Spitz

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

22. If There Is No System Yet • If there are no real users or tasks… • 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 1see Sato and Salvador, interactions 6(5) Gabriel Spitz

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 • Users find it easier to point at an object and use gestures than verbally articulate actions or object Gabriel Spitz

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

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 Spitz

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

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: • The type of information that is needed • General understanding, specific data, …. • Availability of resources • Money, time, people, …. • Access to users Gabriel Spitz