First of all

2. First of all For the User the User Interface IS the system The technical background is of no interest for her/him, that must „just work“ error-free !

3. What is Usability Definition (ISO): Usability is the "effectiveness, efficiency and satisfaction with which a specified set of users can achieve a specified set of tasks in a particular environment." Usability • is objectively measurable. • has concrete positive effects (e.g. financial, saftey-related). • can be achieved by use of structured and well defined processes.

4. Usability Criteria Classical Criteria: • Learnability. How quickly can a user learn to use a new system in order to perform tasks? • Rememberability. How quickly can a user remember the way to use a rarely used system? • Efficiency in use. What effort in terms of resources is necessary for experienced users to perform tasks? • Reliability in use. How does a system react to errors provoked by the user and what consequences do user errors have? • User Satisfaction. How satisfactorily can the system be used? Additional Criteria (User Experience): • Attractivity • Enjoyability • Trust

5. UI-Principles Basic user interface (UI) principles must be thoroughly consideredin the design of all (interactive) systems and user interfaces. They can be regarded as basic quality criteria: • Consistency • Feedback • Efficiency • Flexibility • Clearly marked Exits • Wording in users‘ language • Task orientation • Control • Recovery and Forgiveness • Minimize Memory Load • Transparency • Esthetics and Emotional Effect

6. Why it is important Bad usabilty • Costs time and money • Is a safety risk • Is a competitive disadvantage • Lowers costumer/employee satisfaction

7. Example: Efficiency Work efficiency • 250 user, 60 cases/day, 230 days/year • Improoved usability: processing time/case 10 seconds reduced • 250 User * 60 cases * 230 days * 10 sec = 958.3 hours saved The rule of thumb: „Every dollar invested in ease of use returns $10 to $100." Cost Justifying Ease of Use, IBM Report.

8. Example: Safety CD selection Title selection Title selection CD selection

9. Why is Usability so difficult to achieve: Bad systems aren‘t designed on purpose! Some Reasons: • One cannot go back to know nothing • Users interpret things different than experts/designers • Users behave in unexpected ways • Help doesn‘t • Details matter • Users don‘t „know“ what they „need“ • Nobody can get it right the first time • Patchwork-Design • ...

10. Usability Engineering • Process to achieve usable systems • Methodical and planed procedure Analysis Potentialization Implemen- tation Evaluation Design Prototyping

11. User centred design process ISO 13407 1. Plan the human centred process Meets requirements 2. Specify the context of use 5. Evaluate design against user requirements 3. Specify user and organisational requirements 4. Produce design solutions

12. 1. Plan the human centred process 2. Specify the context of use 3. Specify user and organisational requirements Process ISO 13407 User centred design process - plus CURE additions, derived from practice Meets requirements Detailed design Evaluate with users Conceptual, structural design 5. Evaluate design against user requirements 4. Produce design solutions

13. Methodical principles • Plan and structure the process • Usability doesn‘t happen on it‘s one. • Definition of goals • Define a breakpoint, don‘t rely on somebody to say it‘s good enough or wait until there‘s no more time available. • User involvement • You‘ll be surprised what users actually do. • „External“view • Get your blind spots uncovered. • Iterative process • Don´t be afraid of changing things. • Early Feedback • Don‘t waste your ressources on dead ends.

14. Activities Identification and development of product ideas from a user perspective POTENTIALIZATION ANALYSIS & SPECIFICATION DESIGN PROTOTYPING IMPLEMENTATION Gathering of user requirements, definition of context of use, analysis of related systems Realisation of User Interfaces Use of design methods EVALUATION Development of User Interface Prototypes Adequate Implementation Quality assurance throughout the whole process

15. POTENTIALIZATION Identification and development of product ideas from a user perspective Identification of market opportunities • from a user perspective • not only technology driven Generation/Evaluation of Ideas Typical Methods: • User inquiries • Focus groups • Market analyses Example: What do kids (8-12) want to do with communication devices?

16. ANALYSIS & SPECIFICATION Analysis of all aspects of the system: • User (target groups) • Tasks • Context of use • Requirements • Predecessor • Competing systems • Benefits • Technical possibilities • Innovative potential Typical Methods: • Workshops • Focus groups • Observations • Inquiries

17. DESIGN Structured process: • Information architecture • Conceptual Design • Detailed Design • Design of methaphors, icons, .. • Graphics Design • Use existing methods (parallel design, participatory design, ...) • Include existing knowledge: • Studies, experience, ... • Accurate team • Integrate users and costumers • Ongoing quality assurance • Iterative Process

18. PROTOTYPING User Interface Prototypes • Prototyps of system in different development stages • Paper or electronic prototypes • Horizontal/vertical Enables early feedback Example: Remote control and On-screen display for tv-set by use of digitiser tablet

19. IMPLEMENTATION Take care of usability aspects of technology • User groups • Context of use • Technical equipment Use of proper tools Plan for changes Documentation

20. EVALUATION Principles: • On time • Ongoing • Valid methods Different kinds: • User and expert-based • Standardised and tailored • Labor and field The more innovative, the more testing required

21. EVALUATION Identification of • Problems • Causes • Improovement possibilities (within given conditions) Typical Methods: • Tests • Walkthroughs (Expert Reviews) • Conformity Assessment • Coaching, Shadowing • ...

22. Example I: European Patent Office Relaunch of the EPO-Website Basic information: • Several hundrets of content pages • Integration of online services: • Patent-database • Online application for patents • Recherche in official communications • Access to legal documents (e.g. European Patent Convention) • Three languages

23. Activities • Usability workshop • Analysis of user, tasks, context • Initial usability review of 12 pages prototype • Review of cut through prototype • Guidelines and feedback for navigation structure • Testing of navigation structure • Usability test • Final Review • Documentation and Style Guide

24. Usability Workshop • Goals: • Development of common understanding of project • Stimulate communication • Sensitize for usability issues • Build knowledge • user-oriented design approaches • tools and technics • Identify chances, challenges & pitfalls • Two day-workshop • Participants from all involved areas: decision makers, designers, technicians, marketing, usability engineers, helpdesk, ...

25. Analysis Methods: • E-mail questionnaire • Focus groups • Analysis of server logs (of existing site) • Analysis of helpdesk-requests Results: User group defintion and characterisation Task description and priorisation Definition of technical requirements

26. Initial Review • 12 pages prototype (screenshots) • Focus: • Gereral concept • Navigation mechanism • Conceptual Design To be able to provide early feedback To focus ressources were they are most needed.

27. Navigation Structure General guideline document for designing navigation structure Quality Aspects • Naming of items • Length of items • Breath and deeph of structure Methodical/process guidelines • Whom to involve • How to do it Iterative expert feedback on drafts

28. Review of cut through prototype • 30-pages prototype • Complete paths down (5 levels) • Content pages • Subportals and microsites Focus: • Content pages • Cross linking • Detailed design • Integration of subportals/microsites

29. Testing of Navigation Structure • Simple html-prototype without graphics • Whole structure • Test persons of three main user groups • 25-30 search tasks • Automatic logging of search paths • Qualitative interviews

30. Usability Test • 60 pages functional prototype • Covered all main areas • 3x10 test persons: patent attorneys, patent applicants, generally interested persons • 3 realistic task sets (8-10 tasks) Focus: • Identification of remaining problems • Empirical answers to open design questions

31. Final Review • Final usability check of masterpages • Monitoring of changes • Check of Integration • Big Picture Methodical Note: • Done by usability engineers not involved in the project until then

32. Documentation and Style Guide • Provides the knowledge needed to guaranteeconsistent and durable appearance and behaviour • Keep evolving website consitent to initiallyintended design and behaviour. Contents: General considerations Description and determination of rules for • the website structure • and theirelements • specific interaction techniques used • the visual design and layout of page elements Documentation of design & usability engineering process

33. Example II: Consensus • Development of adaption engine that will enable programmers to • develop browser based applications for • a variety of different mobile devices • by the usage of only one tool. • The need to adapt applications manually to the different devices shall be minimised. • Usability research and empirical studies focusing on the requirements of different mobile devices make sure that the usability of the resulting applications meets high quality standards. • www.consensus-online.orgEU-funded (IST-program)

34. Recoding • semantic adaptation • device & application specific Transcoding • syntactic adaptation • technology specific Dilemma - Cost vs. Usability Integrated adaptation Usability CONSENSUS provides: • semantic information • context information to make integrated adaption possible because only transcoding or only recording is not sufficient Cost

35. Concept • Development of a mark-up language supporting the automatic adaptation of UIs for mobile devices (not part of this presentation) • Device classes (3 dimensions) • Presentation structure • Supported input modality • Mark-up language • Development of user interface guidelines for 8 device classes (Application Programming Guidelines) • Empirical studies informing the Application Programming Guidelines

36. Activities • Potentialization: Which applications are of use in mobile situations • Expert interviews, focus groups, online questionaire, analysis of existing solutions • Analysis: User/Task/context analysis of mobile business applications • Identification of user groups • Identification of use patterns • Identification of use contexts/constraints • Clustering of devices • Guidelines: • Literature, empirical studies & expert knowledge • Maximum level of application complexity per device class • E.g. maximum number of digits to be entered • Design principles • Decision on optimal interaction techniques per device class • Interaction modules per device class

37. Device classes Usability Input leads to a limited number of Device Classes which represent devices behaving similarfrom a users / usability perspective • Different devices require different interfaces • Infinite number of tests vs. clustering • 3 dimensions determining usability • Presentation structure (Output) • Input modality • Mark-Up Language (Widget set) Output Bandwidth NavigationBandwidth Input Bandwidth

38. Device classes Class 0: standard phone Class 1: Screen size: 64x96pixel, input: T9, WAP1 Class 2: Screen size: 176x220pixel, input: T9, WAP2 Class 3: Screen size: 160x160/240x320pixel, input: pen, HTML Class 4: Screen size: 640x320pixel, input: QUERTY, HTML

39. User Interface Guidelines - Approach UsabilityReport (D1) Literature PriorityHigh? No Yes EmpiricalStudy (planned) EmpiricalStudy Guidelines (D2) LiteratureResearch Research Question Guidelines (D2) InternalExperience

40. Example study IScrolling vs. pagination (set up) • Possible disadvantages of scrolling: • Handling of scroll bars • Loss of orientation within the text • 4 devices • Standardised text complexity and lengths • Measurements of • Comfort (Ratings 1 – 5) • Reading time • Text comprehension • Qualitative interviews

41. Example study IScrolling vs. pagination (results) Reading speed Comfort ratings • Scrolling is superior • Reasons: • Loading times • Reader looses context

42. Example study IILength of alphabetical lists (set up) • Maximum level of complexity • How many entries can a user handle • Threshold of pain • 5 devices • List lengths defined according to the devices’ vertical screen size • Measurement of • Task completion times • Pain levels (Threshold lines) • Comfort (Ratings 1 – 5) • Qualitative interviews

43. Example study IILength of alphabetical lists (results) Standardised“threshold lines” • Class 2 ratings due to hardware problems, not defined by the device classification • No limit, as long as the software and hardware interface is (almost) optimal • Results of unsorted lists are different

44. Application programming guidelines • Results of empirical studies and from other sources • Maximum complexity levels per device class • Definition of interaction techniques per device class • Design solutions • Interaction modules • Design principles (soft guidelines) • Target group (application programmers) • Electronic and task oriented version • Tree structured guidelines based on user tasks • Ongoing development(comments field) • Input to RIML and architecturespecification

45. Prototype Example Screenshot “Search Results” • These screenshots show the different outputsv of an search-results page and illustrate that lists are paginated differently depending on the target device’s input mechanism and on its screen size.

46. CURE Usability Engineering Labs • Ca 140 m2 Labs • 2 Control Rooms • 2 Monitoring Rooms • Office Lab • Leisure Lab • Group Room • 2 Mobile Labs

47. Thank You! CURE Center for Usability Research & Engineering Hauffgasse 3-5 A-1110 Vienna, Austria www.cure.at Johann Schrammel Manfred Tscheligi Phone +43 1 743 54 51 {schrammel, tscheligi}@cure.at