1. Chapter 3: Managing Design Processes
3.1 Introduction
3.2 Organizational Design to Support Usability
3.3 The Three Pillars of Design
3.4 Development Methodologies
3.5 Ethnographic Observation
3.6 Participatory Design
3.7 Scenario Development
3.8 Social Impact Statement
3.9 Legal Issues

2. Introduction In the beginning, users were geeks too
Today, most systems are not for geeks
Designs are improved through
Observation of users
Careful analysis of user tasks
Validation of design/ prototype
Continued user involvement
Goal should be to accommodate to the user
Managers must adapt textbook methods to their organization
… Users tolerated, or even preferred complex interfaces
… Good user interface may make the difference between competing products with similar functionality. --- And programmer’s intuitions may not be the best judge of a good interface.
… with their current system and later with prototypes
… what are steps in the task? What sequences of tasks are carried out? How often are different tasks carried out?
… by usability experts and by users. Earlier the better. Later, acceptance tests should include usability as part of the criteria of acceptance. Many organizations have created usability labs – to provide testing with users and to provide experts to analyze
… during requirements, design, development, test …
… user’s skills, goals, preferences …
… skills in organization, schedule and budget for project, kinds/ number of customers

3. 3.2 Organizational Design and Support Usability
High Level Commitment
Convince Developers/ Managers
Usability Group/Lab
Role in Project
Tools for Rapid Prototyping
… this chapter focuses on design portion of project
3.2 Organizational Design and Support Usability
… without high managers committed, spreading word, making appropriate appointments, usability will not be considered important by those who have to meet schedules, short term budgets etc.
… commitment must spread through the organization. Pitch quality – shorter learning times, fewer errors, faster performance by users of well-designed interfaces. Pitch competition – competitive advantage of good interface. Pitch $ - IBM studies show ROI of $100 for every $1 spent on usability – a) reduced maintenance (during development or during maintenance phases) by doing things right the first time and b) increased revenue due to higher user satisfaction and productivity
… providing expertise and testing (shows commitment as well)
… a project user interface architect a) shows commitment, b) keeps developers abreast of field of usability c) serves as expert advice, d) coordinates usability concerns – messages and help, testing, bringing outside expertise … including any particular specialists needed (such as psychologists). Usability roles may expand in future – voice recognition specialists, …
… makes it more feasible to try out different designs and/or revise designs with usability problems
… chapter 4 focuses on testing

4. 3.3 The Three Pillars of Design
Guidelines Documents and Process
User Interface Software Tools
Expert Reviews and Usability Testing
… (guidelines purpose is consistency – and quality. Ensure consistency throughout system, and that all developers follow quality guidelines) – to be discussed in detail in upcoming slides
… as discussed … makes it more feasible to try out different designs and/or revise designs with usability problems
… to be discussed in Chapt 4

5. Guidelines Documents and Process
Guidelines not decided in a vacuum
Living Text
Levels of Guidelines
Each project has different needs, but guidelines should be considered for:
Words and icons
Screen-layout issues
Input and output devices
Action sequences
Training
Guidelines should be distributed and discussed as they are being created … to ensure good guidelines, allow discussion of potentially controversial guidelines, and encourage buy-in by developers who will be using them
… should make a difference in a project – be distributed, enforced ; change when needed
… e.g. rigid standards, accepted practices, flexible guidelines. With process for allowing requested exemptions when appropriate
… each of these will be discussed in turn

6. Words and icons Terminology
Character set, fonts, font sizes, and styles
Icons, graphics, …
Use of color, emphasis
Terminology (words used for task objects and actions), abbreviations to use, and capitalization to use
Character set, fonts, font sizes, and styles (bold, italic, underline) - want no more than a few to be used so to be consistent and not busy
Icon standards and standard icons to use, graphics, line thickness, etc
Use of color, backgrounds, highlighting, and blinking. Don’t use too much color, and keep consistent. Don’t overuse emphasis or it won’t emphasize.

7. Screen-layout Menus, form fill-in, and dialog-boxes
Wording of messages
White space
Lists
Headers and footers
Use of menus and Menu approach (pop-up, pull down) (may be influenced by external standards such as MS Windows / Apple guidelines), form fill-in styles and formats, and dialog-box formats. Consistency across system is important.
Standards and guidelines for wording of prompts, feedback, and error messages. (e.g. how familiar, reading level, verbosity … Consistency across system is important.
Justification, amount of white space, and margins. Consistency across system is important. White space aids usability.
Data entry and display formats for lists and items within lists. Consistency across system is important. Combo boxes / list boxes / drop-down lists aid accuracy and limits taxing users short term memory. Guidelines should probably endorse them for all appropriate situations – and indicate formatting for consistency
Use and contents of headers and footers – e.g. what should be in header – date – what format date … where do page numbers go when relevant …

8. Input and output devices
Major devices
Sounds, touch, …
Response time
Keyboard, display (if internal and have control), cursor control (e.g. event driven vs enter fields in order system desires), and pointing devices to use
Audible sounds – for what occasions, what kinds, user control of volume -- voice feedback (when to use, what voice); touch input – what pointing devices to use (such as touch screen), and other special devices
Response time for a variety of tasks (what user should be able to expect)

9. Action sequences Direct-manipulation Commands Function keys
Error handling
Direct-manipulation – Should direct manipulation be used? what metaphor to use? clicking, dragging, dropping, and gestures
Command syntax, semantics, and sequences – some commands may be allowable in multiple parts of system, ensure that they are consistent
Programmed function keys – what key does what?
Error handling and recovery procedures - again want consistency for users

10. Training Help Training and reference materials
Online help and tutorials – again – want quality and consistency
Training and reference materials – specify what is to be developed

11. 3.4 Developmental Methodologies
Six Stages of Logical User-Centered Design Methodology (Kreitzberg):
Stage 1: Develop Product Concept
Stage 2: Research and Needs Analysis
Stage 3: Design Concepts and Key Screen Prototype
Stage 4: Iterative Design and Refinement
Stage 5: Implement Software
Stage 6: Provide Roll-Out Support
(LUCID) At this high level, not drastically different than an iterative development via prototyping methodology from Software Engineering. But there are important differences. It would have been helpful if the model didn’t only focus on usability, it is a very small step or two to combine this with SE iterative development methodologies, and we could then avoid the statement “Any user-centered design methodology must also mesh with the software-engineering methodology used”. I think they probably kept it separate to be useful regardless of SE methodology used
Steps to be discussed in detail …

12. Stage 1: Develop Product Concept
Create high concept
Business objectives
Identify team
Identify User population
Prepare project plan
Identify constraints
Develop mockups to show non technical people
… brief statement that identifies the goals, functionality and benefits of the software.
E.g from book “The new home banking system will provide customers with unified access to their accounts. It will support balance inquiry, management of credit accounts and loans, transfer among accounts, electronic bill payment and investment in the bank’s family of mutual funds. The system will provide the customer with year end accounting for tax purposes.
… including budget and schedule (seems a bit premature to me)
… legal, technical, environmental
… (paper or on-screen) (seems way premature to me)

13. Stage 2: Research and Needs Analysis
Partition the User Population
Break Job Activities into Tasks
Conduct Needs Analysis
Sketch Process Flow
Identify Major Objects
Research and Resolve Technical Issues
Kind-of parallels traditional preliminary requirements analysis
Partition the User Population into homogeneous segments (as normal SE)
Break Job Activities into Tasks (somewhat different direction in formalizing than sometimes taken in SE – towards user job task orientation)
Conduct Needs Analysis through construction of scenarios (step by step handling of user tasks - used in OO SE, but not focus of some other SE) and participatory design (not too different from SE – somewhat heavier user involvement)
Sketch Process Flow for sequence of tasks (again normal in OO)
Identify Major Objects and structures which will be used in the software interface
Research and Resolve Technical Issues and other constraints
Really in this stage you need to be looking into other kinds of requirements besides interface – e.g. processing that must be done

14. Stage 3: Design Concepts and Key Screen Prototype
Create Specific Usability Objectives
Initiate Guidelines
Select Navigational Model and Design Metaphor
Identify Key Screens
Develop Prototype of Key Screens
Initial Reviews and Usability Tests
Create Specific Usability Objectives based on user needs
Initiate Guidelines and style guide
Select Navigational Model and Design Metaphor
Identify Key Screens
Develop Prototype of Key Screens using a rapid prototyping tool (hardly distinctive of LUCID). I believe that part of the assumption here is that the prototype is a “throw-away” prototype – it is not necessarily going to be used at all in the developed product.
Initial Reviews and Usability Tests (regular SE, users certainly consider usability, and here we certainly have to consider whether all of the users’ desired functionality has been identified. Any major difference would be in any formal usability tests and/or usability experts consulted)

15. Stage 4: Iterative Design and Refinement
Expand Key screen prototype
Conduct Heuristic and Expert Reviews
Conduct Full Scale Usability Tests
Deliver Prototype and Specification
Expand Key screen prototype into full system
Conduct Heuristic and Expert Reviews
Conduct Full Scale Usability Tests
Deliver Prototype and Specification – prototyping done as part of developing the spec

16. Stage 5: Implement Software
Develop Standard Practices
Manage late stage change
Develop online help, documentation, tutorials
Develop Standard Practices (seems late – really these are developing with the prototype)
Manage late stage change
Develop online help, documentation, tutorials

17. Stage 6: Provide Roll-Out Support
Training
Logging, Evaluation, Maintenance
Provide Training and assistance
Perform Logging, Evaluation, and Maintenance

18. The Twelve areas of the Lucid Management Strategy
Product Definition
Business Case
Resources
Physical Environment
Technical Environment
Users
Functionality
Prototype
Usability
Design Guidelines
Content Materials
Documentation, Training, and Help
The Twelve areas of the Lucid Management Strategy (each reviewed regularly as project progresses to make sure it is in line)
Product Definition – high concept for managers and marketers
Business Case – pricing, expected revenues, return on investment (ROI), competition
Resources – duration, team members, effort level, back up plans
Physical Environment - ergonomic design, physical installation, communication lines
Technical Environment – hardware and software for development and integration
Users – multiple communities for interviews, user testing, marketing
Functionality – services provided by users
Prototype – early paper prototypes, key screens, running prototypes
Usability - set measurable goals, conduct tests, refine interface and goals
Design Guidelines – modification of existing guidelines, implementation of review process
Content Materials – identification and acquisition of copyrighted text, audio, and video
Documentation, Training, and Help – specification, development, and testing paper, video and online versions
<SKIP>

19. 3.5 Ethnographic Observation
Potential Dangers
Process:
Preparation
Field Study
Analysis
Reporting
Observing people in their environment – in this case, working in their work environment, working with a system. Probably we’re looking to replace or redesign the system that they’re working with. Or in a later stage, they’re working with a prototype and we’re looking to improve the prototype.
… By observing, you change what you are observing – maybe making what you observe less valid. Plus, it is easy to overlook things or misinterpret what is observed
… each to be discussed in turn …

20. Preparation Understand organization culture.
Familiarize yourself with the system
Set goals and prepare questions.
Gain access
Understand organization policies and work culture. (book e.g. don’t wear jeans where users are prohibited from doing so).
Familiarize yourself with the system and its history. Learn task language of users. Know what attitudes to expect. Who is likely to be against change from the start?
Set initial goals and prepare questions. Prepare questions so as to make the best use of any interview time. Keep focused on goals you have for that particular kind of user. Planning for what to observe can be very important as well – things happen fast, and you may miss things that you are not looking for – may have checklists to look for (e.g. #errors, #times used help ….)
Gain access and permission to observe/interview.

21. Field Study Establish rapport.
Observe/interview users in their workplace and collect data.
Follow any leads.
Establish rapport with managers and users. Useful for getting quality results – and to aid in enlisting future help
Observe/interview users in their workplace and collect subjective/objective quantitative/qualitative data. Subjective views can be quantified with ratings scales. Objective results could be qualitative narratives (e.g. accounts of frustrating episodes) as well as numbers
Follow any leads that emerge from the visits. Ask about things observed. Ask follow up questions to answers. If people say that so and so would be helpful, contact them …

22. Analysis Compile the data Quantify data and compile statistics.
Interpret the data.
Refine the goals and the process used.
Bring together and organize observations, responses to questions, etc. Compile the collected data in numerical, textual, and multimedia databases.
Quantify data and compile statistics.
Reduce and interpret the data. Summarize. Implications …
Refine the goals and the process used – prepare for further study …

23. Reporting Consider multiple audiences and goals.
Prepare report with the findings
Consider multiple audiences and goals. Don’t alienate. Consider politics. Consider terminology. Remember confidentiality.
Prepare a report and present the findings. Brief – people don’t have time to read volumes.

24. 3.6 Participatory Design More than just requirements and feedback
Plusses
Minuses
Must be managed
Appropriate level of user involvement could vary
… users might create paper prototypes, walk through scenarios, communicate to groups of users they represent
… more user involvement brings … higher quality (first two) plus (last two)
more accurate information about tasks
more opportunity for users to influence design decisions
a sense of participation that builds users' ego investment in successful implementation
potential for increased user acceptance of final system
… on negative side, extensive user involvement may
be more costly
lengthen the implementation period
build antagonism with people not involved or whose suggestions rejected
force designers to compromise their design to satisfy incompetent participants
build opposition to implementation – if interaction doesn’t go well
exacerbate personality conflicts between design-team members and users
show that organizational politics and preferences of certain individuals are more important than technical issues
… careful selection of users (maybe even based on competition), users should be well briefed on their roles and expectations on them (and commit to carrying them out) (and roles will include extra work – including many meetings, and learning about plans of organization – business and technical) …

25. 3.7 Scenario Development Day-in-the-life scenarios
Well established systems – can have data about frequencies of different scenarios
Day-in-the-life scenarios:
characterize what happens when users perform typical tasks
May deal with common or emergency situations
Overview and Step by step how user interacts with system (book e.g.s p , 7th grade teacher searching digital library for material to use in class (mostly goals and constraints); Grandmother and grandkids searching www site for a museum for history of ancestral homeland (more step by step what happens))
can be acted out as a form of walkthrough
may be used as basis for videotape
Helps visualize user needs
Well established systems:
useful tools:
table of user communities across top, tasks listed down the side
table of task sequences
flowchart or transition diagram

26. 3.8 Social Impact Statement
potential impact on society
Produced early
Reviewed by panel and interested parties
Once approved, should be followed
At this point, merely a proposal
Analogous to environmental impact statement – potential impact on society of a proposed system. – Shneiderman - Recommended requirement for government systems – desirable but optional for commercial systems as well
… while there is time for interested parties to have influence
… including government agencies, professional societies and unions …
… (and likely to be a controversial one)

27. Social Impact Statement
Describe the new system and its benefits.
Address concerns and potential barriers
Outline the development process.
<This seems reasonable for far reaching government systems – e.g if we’re going to have a bunch of facial recognition systems around for security. But is a lot of overhead for less significant systems – and is a lot to ask of anybody developing commercial systems (Discussion EZPass) >
Describe the new system and its benefits.
Convey the high level goals of the new system.
Identify the stakeholders.
Identify specific benefits
Address concerns and potential barriers.
Anticipate changes in job functions and potential layoffs.
Address security and privacy issues.
Discuss accountability and responsibility for system misuse and failure.
Avoid potential biases.
Weigh individual rights vs. societal benefits.
Assess trade-offs between centralization and decentralization.
Preserve democratic principles.
Ensure diverse access.
promote simplicity and preserve what works.
Outline the development process.
Present and estimated project schedule.
Propose process for making decisions.
Discuss expectations of how stakeholders will be involved.
Recognize needs for more staff, training, and hardware.
Propose plan for backups of data and equipment.

28. 3.9 Legal Issues Privacy Safety and Reliability Copyright Patents
Freedom of Speech
Access for Disabled
… besides internal uses of data (e.g. should data collected for one purpose be allowed to be used for other purposes (e.g. data mining - supermarket purchase info)), this also involves protection of sensitive data collected
… (e.g. Iranian Airbus) – if interface confuses operator into making an error that causes harm – what is the legal responsibility? (hasn’t been tested in court)
… (a lot of issues discussed in the book (most not that focused on interfaces). A big case was Apple-Microsoft look and feel suit. (Apple lost) Now with all of the desktop world having much the same look and feel, probably not much to such a claim – but for a more unique software …. A substantially similar interface might be considered a copyright infringement. But hard to prove. Also, there is a debate over whether copyright protection is good or bad – protect innovation, therefore encouraging it – or preventing standards and familiar interfaces, causing unnecessary user confusion and increased costs and red tape
… harder to get, but more rigorously enforced than copyrights. Have been awarded to software algorithms
… (not too focused on interfaces)
… (very important for interfaces, as discussed in previous chapters)

29. End Chapter 3