Process The of Usability Engineering
laura leventhal and julie barnes
1
Sources
s
Protobook, chpt 4.
2
Building a UI - what do we know or can guess?
s s
s
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
3
Software Development is Hard
s
s
s
s
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.
4
Characteristic Software Development Activities
s
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.
5
The software explosion (sometimes called "crisis")
s s
s
s
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
6
Forget crisis
s
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
7
Special challenges to UI development
s
The communications explosion s The media explosion s The usability explosion
8
The communications explosion.
s
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
9
The media explosion
s
User interfaces offer a myriad of devices (media)
Mice, pens, touch screens, video, speech, VR etc.
s
To support these devices, UI code is half or more of the code
Gets more complicated, the more the media (e.g., multimedia)
10
The usability explosion
s
Users want usability. It is not an option. s Users want *availability* (open architectures)
11
Incorporating UI into SE
s
Benefits of including UE (usability engineering) as part of SE methodology
The problem: Overhead
12
Software Life Cycle plus UE
s
s
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
13
Waterfall Picture
system engineering Classic (waterfall) lifecycle model analysis
design
code
testing
maintenance
14
Phases
s
Systems engineering and analysis s Software requirements analysis s Software design s Code s Testing s Maintenance
Memorize for tests and interviews!
15
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
16
Effort Guessing Game
s
If my development involves 100 units of effort, how much do I spend on
Specification and design? Coding? Testing?
17
Issues for the Waterfall Model
s
The waterfall model is the oldest and most widely-used paradigm for software engineering.
18
Some benefits:
s
Following any methodology imposes discipline on the software development process. s It appears to be easy to specify a timetable and costing for s/w developed with the waterfall model.
19
Some problems:
s
s
s
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.
20
Building a Model that includes UE
s
Problems with waterfall are especially significant when developing a UI s How could we modify the waterfall model to make it more appropriate for a project that includes a significant UI?
21
Getting real...
s
Even traditional software engineering projects often benefit from iteration and re-evaluation. s 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. 22
Our model
s
Our model incorporates
Waterfall phases UI development phases Iteration
23
SE development activities
Requireme nts Specificati on
Design
Implementati on
Testing
Architectur al Design
Low-level Design
System Engineering & Context Setting
UI development activities
Interaction Design
Interface Design
Task Analysis
Design
Implementati on
User Testing
Figure 1: Parallel SE and UI development activities
24
Parallel SE and UE
Activity
Context Setting Req.ts Analysis
Sample SE Activities
Systems Engineering problem
Sample Understand UE Activities
Establishing need for interface. Identify user tasks Identify interface feature
Design - High level Design - Detailed Implementation Evaluation
Architectural Design Algorithms, d. structures Implementation Testing flow and function
Identify user characteristics. Design of interaction Architectural design to support interact Design individual interaction Algorithms, d. structures Implementation Evaluation by experts or user testing Software testing
25
Savings from good UE
s
Nielsen (1993) describes a number of examples of projects that benefited from good UE
26
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)
27
Other SE issues
s
The Design Team s Participatory Design
28
The Design Team
s
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. s The job of building a good interface has to be taken on by the team that designs the product as a whole.
29
Design Team Composition
s
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. 30
Design Team Composition - 2
s
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
31
Responsibility
s
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. s All of these activities need to be coordinated
32
Command/Team Structure
s
Distribution of activities and communications
Chief programmer team Egoless programming
s
Choice depends on group dynamic and type of problem
Exploratory problems may work better with egoless programming where familiar wellstructured problems may be better with a chief programmer structure.
33
Participatory Design
s
s
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.
34
Specifics/Participatory Design
s
In participatory design, systems are designed by designers and customers/users working together: a slogan is DESIGNING WITH rather than DESIGNING FOR.
35
Defining Characteristics
s
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. 353-359). : 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 n...