10/19/2010

1

Diseño y Evaluación de Sistemas InteractivosCOM-14112-001

UI Requirements – Part 312 de Octubre de 2010

Dr. Víctor M. González y Gonzálezvictor.gonzalez@itam.mx

Agenda

1. Thinking about requirements and describing them2. Prototyping

10/19/2010

2

Thinking about requirements and describing them

Chapter 6: User Interface Design and Evaluation by Stone et al.

Usability Requirements

• Qualitative usability requirements are concerned with the desired usability goals for a computer system; for example, “the system should be easy to use” or “there should be user satisfaction.” Qualitative usability requirements can be subjective and are not always easy to measure or quantify.

• Quantitative usability requirements may be expressed in terms of specific performance measures, referred to as usability metrics. Examples of metrics used to assessperformance can include the completion time for specified tasks by a specified set of users, the number of errors per task, and the time spent using documentation.

10/19/2010

3

Usability Requirements

• Tyldesley (1988) compiled a list of 22 possible measurement criteria that could be used for developing usability metrics for testing the usability of a system. 1. Time to complete a task2. Percentage of task completed.3. Percentage of task completed per unit time (speed metric).4. Ratio of successes to failures.5. Time spent on errors.6. Percentage or number of errors.7. Percentage or number of competitors that do this better than current

product.8. Number of commands used.9. Frequency of help or documentation use.10. Time spent using help or documentation.11. Percentage of favorable to unfavorable user commands.

Usability Requirements

• Tyldesley (1988) compiled a list of 22 possible measurement criteria that could be used for developing usability metrics for testing the usability of a system. 12. Number of repetitions of failed commands.13. Number of runs of successes and of failures.14. Number of times the interface misleads the user.15. Number of good and bad features recalled by users.16. Number of available commands not invoked.17. Number of regressive behaviors.18. Number of users preferring your system.19. Number of times users need to work around a problem.20. Number of times the user is disrupted from a work task.21. Number of times the user loses control of the system.22. Number of times the user expresses frustration or satisfaction.

10/19/2010

4

Usability Metrics

Examples of Usability Metrics from ISO 9241 (British Standards Institution, 1998)

Modern-Day View of Usability

Design Approaches to Meet Key Usability Requirements (f rom Quesenbery, 2003)

10/19/2010

5

Constraints and Trade-offs in Relation to Requirements Gathering

• Costs/budgets/timescales– Fixed budget, deadlines

• The technology available and its interoperability with other hardware and software– Upgrading hardware dependencies– Several systems / interfaces

• The agenda of individuals stakeholders• Contradictory requirements• Organizational policies

• Trade-offs – Each evaluated in terms of its impact on the user’s ability to use the system

effectively

Problems with Requirements Gathering (1/2)

• Not enough user/stakeholder involvement in the requirements-elicitationprocess may cause the requirements to be incomplete.

• Lack of requirements management — that is, changes to requirements as a result of feedback and negotiation are not tracked properly or not properly recorded. As a result, the requirements are inaccurate.

• Related to the above, if the requirements-gathering efforts are not properly coordinated, some activities may not be carried out. Once again, the requirements will be incomplete or inaccurate.

• Communication problems related to different stakeholders with different levels of understanding can be problematic for sharing understanding of the requirements between all groups.

• Capturing the relevant application domain-related information can be difficult, as the knowledge exists in a variety of places: textbooks, operating manuals, and in the heads of the people working in the area.

10/19/2010

6

Problems with Requirements Gathering (2/2)

• People who do understand the problem may be heavily constrained by their workload and time, or they may be convinced that a new system is not necessary and be reluctant to participate or cooperate with those gathering the requirements.

• Organizational and political factors may influence the specification of the requirements, and these views may not tally with the end users. Related to this problem are the agendas of different stakeholders, which may make eliciting and negotiating requirements difficult.

• Some stakeholders will not know what they want from the computer system except in the most general terms, while others will be verbally forceful and detailed about what they want. Getting a balanced view can be problematic, as noted previously under constraints.

• Economic and business environments within organizations are ever-changing, as are employee roles within organizations. This, inevitably, changes the elicitation process, because stakeholders will change over the duration of the design and development of the application.

Requirements Specifications

• The conclusions of requirement-gathering activities are translated into requirements for the design of the system

• The focus of the requirement specifications is on what the system should provide, rather than how the system works

• The requirements specification document would typically include:– Requirements related to user characteristics.– Requirements related to tasks and task characteristics.– Requirements related to the various environmental factors.– Usability requirements.– Statements of constraints and trade-offs and any requirements

negotiations.

10/19/2010

7

Requirements Specifications

Guidelines for w riting requirements. (From Kotonya and Sommerville, 1998, p. 21.)

Requirements Specifications

Usability Requirements Document

10/19/2010

8

Prototyping

• A prototype, can be used early in the design process to communicate and share ideas between the UI designer and the users and stakeholders, so that requirements can be clarified. Later in the design process it can be used for exploring and demonstrating interaction and design consistency.

• The purposes of prototyping are as follows:– To check the feasibility of ideas with users– To check the usefulness of the application– To allow users to contribute to the design of the application– To allow users to test ideas– To validate the requirements (i.e., to reveal inconsistent or

incomplete requirements)– To negotiate requirements

Types of Prototypes

• Low-fidelity prototypes• High-fidelity prototypes

10/19/2010

9

Types of Prototypes

• Low-fidelity prototypes

Types of Prototypes

• The three main criteria for low-fidelity prototypes:– Easy and inexpensive to make.– Flexible enough to be constantly changed and rearranged.– Complete enough to yield useful feedback about specific

design questions.

• People are more comfortable criticizing paper prototypes

• Make some decisions before you begin:• What feedback do you need at this point in the design process?• How much of the design should you prototype?• Should you cover all of the areas but without great detail (breadth vs.

depth)?• Should you cover one area in great detail?

10/19/2010

10

Types of Prototypes

Adv antages and Disadv antages of Low-Fidelity Prototy pes (f rom Rudd et al., 1996, and Snyder, 2003.)

www.wiley.com/go/mobile

Types of Lo-Fi

• Basic layout

10/19/2010

11

1-21

1-22

10/19/2010

12

1-23

www.wiley.com/go/mobile

Lo-Fi – Interaction

• Using “Wizard of Oz”

10/19/2010

13

Guide to Salat – by Shahab Siddiqui

The functionalities of the ‘Guide to Salat’ are:• Locating Nearest Mosques• Prayer’s Timings• Prayer Reminders• Prayer Management• Providing Religious knowledge

Prototypes - Scenario – Guide to Salat

• Mr. Shayan arrives in Manchester International Airport from New York City on Monday morning to attend some official meetings for 10 days. He takes his mobile phone out from his pocket and set the England’s local time on his phone. He is a Muslim very busy professional person and always try to say prayers on time. He opens the application ‘Guide to Salat’ on his phone and selects the second option ‘local timings of prayers’, just to check the timings of prayers . Then he thinks to go to hotel to get fresh up there. After reaching hotel, he try to find out the location of mosques in this city, so he selects the first option of ‘Guide to Salat’ and he put in the name of the city or post code of the hotel. It is 12:30 afternoon, he receives a phone call from one of his colleague and he gets busy in talking with him. Then suddenly his mobile phone rings up and he sees areminder window on his mobile’s screen, which shows him, which prayer is due now.

10/19/2010

14

Conceptual Design – Prototypes

GUIDE TO SALAT

OPTIONS

LOCATE MOSQUES

LOCAL TIMIGS OF PRAYERS

REMINDERS OF PRAYERS

PRAYER MANAGEMENT

RELIGIUOS KNOWLEDGE

EXIT BACKMAIN MENU

PRAYER’S TIMINGS

CITY

FAJR

SUNRISE

DHUHR

ASR

MAGHRIB

SUNSET

ISHA

MANCHESTER

04:14

06:26

13:11

16:52

19:57

21:59

20:07

Conceptual Design – Prototypes

BACKMAIN MENU

ENTER YOUR CURRENT POSITION BY PUTTING IN POST CODE.

M8 9LN

OK

BACKMAIN MENU

MOSQUES MAP

1. KHIZRA

2. BILAL

3. MADNI

4. JAMAH

ARE YOU GOING TO SAY PRAYER RIGHT NOW?

YES NO

10/19/2010

15

Conceptual Design – Prototypes

Conceptual Design – Prototypes

10/19/2010

16

Conceptual Design – Prototypes

Conceptual Design – Prototypes

10/19/2010

17

Conceptual Design – Prototypes

Conceptual Design – Prototypes

10/19/2010

18

Paper Prototyping

• NNg Paper Prototyping cliphttp://vimeo.com/2273993http://www.nngroup.com/reports/prototyping/

• Blood Test Prototype• http://www.youtube.com/watch?v=_g4GGtJ8NCY

• Storyboard

10/19/2010

19

Types of Prototypes

• High-fidelity prototypes– Paper-based prototypes are quick and inexpensive, and they

can provide valuable insights. But they do not demonstrate functionality. For this, we need to turn to high fidelity prototyping.

– High-fidelity prototypes, which are based on software, provide a functional version of the system that users can interact with. As such, they show the UI layout and its navigation.

Types of Prototypes

• High-fidelity prototypes

Advantages and Disadvantages of High-Fidelity Prototypes (adapted from Rudd et al., 1996, and Snyder, 2003)

10/19/2010

20

Summary

• Typically, requirements gathering collects some information, which is analyzed, and negotiated with the users and other stakeholders.

• Then another round of requirements gathering takes place. This cycle of requirements-gathering–prototyping– negotiation continues until schedule pressures force the development of the application to begin (this is the normal terminating condition) or until all the stakeholders are satisfied with the requirements.