1 The Process of Usability Engineering laura leventhal and julie barnes

2 Sources Protobook, chpt 4.

3 Building a UI - what do we know or can guess? Principles of UI development are neither obvious nor intuitive Principles of UI development are not applied as often as they should be Developing a UI is part of the larger problem of developing software

4 Software Development is Hard Some authors believe that software development is in a sort of “crisis” that is characterized by projects which miss deadlines and are delivered with errors. Numerous strategies to improve the process of software development have been offered including alternative development methodologies and computer-aided tools. Adding a significant user interface makes software development more difficult. Software engineering and usability engineering are related. It makes sense to understand a little about the process of software engineering as we are discussing the process of usability engineering.

5 Characteristic Software Development Activities There are activities that have to happen in software or usability engineering. These include Understanding and documenting the context of the project. Understanding and documenting the problem to be solved Designing and documenting a solution in the context. Implementing the solution. Testing and evaluating the solution. Documenting the outcome of the evaluation.

6 The software explosion (sometimes called "crisis") free falling costs increases the potential market for s/w burgeoning (diversification of) demand for functionality size and complexity of s/w is always increasing What are the big trends driving the field today? The Software Crisis Software Chronic Problem

7 Forget “crisis” Forget "crisis" according to Pressman, this is a chronic affliction. Symptoms: s/w takes a long time to develop costs are high s/w is often delivered with errors difficult to measure progress as s/w is developed

8 Special challenges to UI development The communications explosion The media explosion The usability explosion

9 The communications explosion. Essence of UI used to be one-user, standalone. Now moving more toward connectivity Internet WWW Businesses wanting CSCW (computer supportee cooperative work) Communications services Expanding user populations

10 The media explosion User interfaces offer a myriad of devices (media) Mice, pens, touch screens, video, speech, VR etc. To support these devices, UI code is half or more of the code Gets more complicated, the more the media (e.g., multimedia)

11 The usability explosion Users want usability. It is not an option. Users want *availability* (open architectures)

12 Incorporating UI into SE Benefits of including UE (usability engineering) as part of SE methodology The problem: Overhead

13 Software Life Cycle plus UE The Traditional Waterfall Model suggests a reasonable linear progression of the activities that takes place in Software development Waterfall model - Escher drawing systematic, sequential approach to software development begins at system level and progresses through a series of phases

14 Waterfall Picture

15 Phases Systems engineering and analysis Software requirements analysis Software design Code Testing Maintenance Memorize for tests and interviews!

16 Maintenance If development is 1 year, maintenance could go on for 10 years. Maintenance activities –Correcting errors –Adding features –Updating software to accommodate environmental changes such as a new operating system

17 Effort Guessing Game If my development involves 100 units of effort, how much do I spend on Specification and design? Coding? Testing?

18 Issues for the Waterfall Model The waterfall model is the oldest and most widely-used paradigm for software engineering.

19 Some benefits: Following any methodology imposes discipline on the software development process. It appears to be easy to specify a timetable and costing for s/w developed with the waterfall model.

20 Some problems: Real problems rarely follow the sequential flow that the model suggests. Iteration always occurs and creates problems in the application of the paradigm. It is difficult for the customer to state all requirements explicitly. The classic life cycle has difficulty accommodating the natural uncertainty that exist at the beginning of many projects. Customer must have patience. A working version of the software will not be available until late in the time span.

21 Building a Model that includes UE Problems with waterfall are especially significant when developing a UI How could we modify the waterfall model to make it more appropriate for a project that includes a significant UI?

22 Getting real... Even traditional software engineering projects often benefit from iteration and re-evaluation. How to know whether to go back or forward? Prototypes provide a basis for evaluation and control of iteration Evaluation can also be based on usability, risk analysis, projected future costs, expected market value or other criteria.

23 Our model Our model incorporates Waterfall phases UI development phases Iteration

24

25 Parallel SE and UE Activity Sample SE Activities Sample UE Activities Context Setting Systems Engineering Establishing need for interface. Req.ts Analysis Understand problem Identify user tasks Identify interface feature Identify user characteristics. Design - High level Architectural Design Design of interaction Architectural design to support interact Design - Detailed Algorithms, d. structures Design individual interaction Algorithms, d. structures Implementation Implementation Implementation Evaluation Testing flow and function Evaluation by experts or user testing Software testing

26 Savings from good UE Nielsen (1993) describes a number of examples of projects that benefited from good UE

27 Nielsen example (p.3) “A major computer company saved $41,700 the first day the system was in use by making sign-on attempts faster for a security application. This increased usability was achieved through iterative design at a cost of only $20,700. 9Darat, 1990)

28 Other SE issues The Design Team Participatory Design

29 The Design Team Activities of interface design throughout the software design and life cycle, the interface can't be produced or analyzed at one point by a group of interface specialists. The job of building a good interface has to be taken on by the team that designs the product as a whole.

30 Design Team Composition The design team needs to be composed of persons with a variety of skills share several common characteristics. They need to care about users They need to have experience with both bad and good interfaces They need to be committed to and optimistic about creating an effective system.

31 Design Team Composition - 2 The team should include representatives from the entire range of interface-related areas: Software engineers User interface and human factors specialists Technical writers Training package developers Marketing specialists

32 Responsibility Designers who create the software shouldn't sign off on their product and hand it off to an entirely separate group that creates the manuals, who then hand off to another group that handles training. All of these activities need to be coordinated

33 Command/Team Structure Distribution of activities and communications –Chief programmer team –Egoless programming Choice depends on group dynamic and type of problem –Exploratory problems may work better with egoless programming where familiar well- structured problems may be better with a chief programmer structure.

34 Participatory Design We have been assuming a split between the roles of designers and customers/users that has been traditional in U.S. system design. Designers generally are not customers or users; they gather information from users and reflect it in systems they build; they give these systems to users who use them or not. There is an alternative approach, pioneered by workers in Scandinavia, that rejects this structure.

35 Specifics/Participatory Design In participatory design, systems are designed by designers and customers/users working together: a slogan is DESIGNING WITH rather than DESIGNING FOR.

36 Defining Characteristics Blomberg and Henderson stress three defining attributes of participatory design (Blomberg, A.L. and Henderson, A. "Reflections on participatory design." In Proc. CHI'90 Conference on Human Factors in Computer Systems. New York: ACM, 1990, pp ). : The goal of the activity is to improve the work life of users The activity is collaborative, with all goals and decisions actively negotiated and not imposed The activity is iterative, in that ideas are tested and adjusted by seeing how they play out in practice.

37 Why Try Participatory Design Customer Satisfaction Having the customer on your development team should help you to define the “right” problem and to hit on the “right” design. The customer has a major stake in the project, not only as the customer but as a developer.

38 A Final Participatory Design Thought For commercial projects there are further challenges. At bottom, your objective as a commercial developer may really not be to improve the quality of somebody else's work life, but rather to make money for yourself. So you don't have the right goal to begin with.

39 Review - The Process of Usability Engineering Major Topics Software Development is Hard –Are we in a “crisis” Adding a significant user interface makes software development more difficult. There are activities that have to happen in software development. –The Traditional Waterfall Model suggests a reasonable linear progression of these phases. –For some types of projects, including those with a significant user interface, the Waterfall model may not make sense in its traditional linear form.

40 Review - The Process of Usability Engineering (2) Iteration is the key change to the traditional Waterfall model. The phases (activities) of the model are the same. The flow is more fluid. Evaluation of prototypes is the mechanism that drives the decision to move backward or forward through the activities. Evaluation may be based on usability concerns, risk assessment and so on.

41 Review - The Process of Usability Engineering (3) There is a lifecycle model for software engineering with usability engineering. The model supports iteration The activities (phases) of the Waterfall model have parallel activities for software and user interface development. Development of large software and user interface projects typically happens in teams. There are different models for team structure. There are different philosophies for development. We discuss development assuming that the development team and the customer are separate entities. In Participatory Design, customers are part of the Development team. –This model has the advantage that the customer’s satisfaction should be high.

42

43