• "designing for usability" (focus on design of UI)
• "usability engineering"
• old "techno-centric" model will no longer suffice
• must involve users at all stages of iterative development.
• Not easy to achieve: "Interactive system designers must blend a thorough knowledge of technical feasibility with a mystical esthetic sense of what attracts users." p 99.

• Traditional waterfall model involves user only in first phase
  Why? Early systems were batch, not interactive.
• Transition to interactive systems has led to. . .
  . . . greater user involvement in other phases, which has led to . . .
  . . . greater importance on iteration in lifecycle*, which has led to . . .
  . . . new iterative lifecycle models such as spiral or evolutionary.
  * (facilitated by development of specification and prototyping tools)
• LUCID: Logical User-Centered Interactive Design Methodology (Kreitzberg).
• Six LUCID development stages are:

1. develop product concept (goals, functionality). Project Plan.
2. needs analysis. requirements phase.
3. design concepts and key-screen prototype
4. iterative design and refinement
5. implement software
6. provide rollout support (training, maintenance, etc)

• Use of guidelines documents and processes
• Guidelines for organization and for each project.
• Promotes consistency.
• Guidelines for: words, icons, screen layout, action sequences, etc
• Can include: standards, practices, flexible guidelines.
• UI software tools
• Especially for UI prototyping purposes.
• Facilitates iterative process.
• Expert reviews and usability testing
• To evaluate UI before system released.

• Evolution of "user centered design"
  Donald Norman book of same name (1983?).
• Product undergoes "maturation" process.
• Human-centered development requires three different skill sets:
  - technology
  - marketing
  - user experience
• Not all are equally important throughout product maturity lifetime:
  First things first: first technology and proper functions, then reliability and cost, then ease of use."
• It is not enough to be first, best, or right:
  You must "understand why customers buy products, what they are looking for, and how their needs and perceptions drive sales."

___________________________

Norman's latest is: The Invisible Computer : Why Good Products Can Fail, the Personal Computer Is So Complex and Information Appliances Are the Solution (now available)

He focuses on three themes:

1. A successful product must be balanced among:

• marketing,
• technology,
• user experience

2. Different factors important at different stages in the development of a technology.

• In the early days, technology dominates. Who cares if it is easy to use? All that matters is better, faster, cheaper.
• In the middle stages, marketing dominates.
• In the mature stages, the technology is a commodity. User experience and marketing can dominate.
  ("Swatch sells its watches for their emotional appeal, not their accuracy: accuracy is taken for granted.")

3. We must differentiate:

• traditional products ("substitutable", or individual)
• infrastructure products ("non-substitutable", interchangeability required)

• Traditional include most consumables: soda, cereal, soap. Many companies can coexist.
• Infrastructure include many technologies, "there can be just one". Examples are VHS/Beta, MS-DOS / MacOS. Lack of standards results in chaos (e.g. AM stereo).
• "Most infrastructures are dictated by the government, which assures agreement to a single standard. When there is no standard, as in AM stereo or digital cellular options in the US, there is chaos."

• Should see usability as a desirable and measurable quality item.
• Organization can have chief usability officer and/or usability lab.
• At project level, should have UI/usability/human-factors specialist.
  May also include psychologists, graphic designers, sociologists.
• There are financial benefits of designing for usability
  user productivity, development and maintenance costs.

• Benefits:
• better and more complete information
• make user feel respected and important
• increased chance of acceptance
• possible reduced development time and cost
  (change made at acceptance-test time is more costly than same change at design time)
• Pitfalls:
• possible lengthened development time (!)
• user may not be willing to spend time and effort
• conflicts between users
• user opposition to system (may replace their job duties!)
• get caught in client organization political crossfire

• Observing UI users for purposes of changing and improving UI.
• Should be explicit, planned, and organized.
• Process includes:

1. Preparation (become familiar with organization/system/task domain, determine GQM)
2. Field study (observations and interviews)
3. Analysis (compile, reduce, interpret data -- can be qualitative as well as quantitative)
4. Reporting

Usage scenarios (use-case scenarios)

• if proposed system represents a new way or significantly different way of doing things.
• Good way to identify objects and actions, and can be understood by user. Scenarios can be play-acted out.

Collaborative Style Guides (details below)

What is a style guide? A set of guidelines for UID which:

• Promote visual and functional consistency within and between different applications
• Promote good design practice
• Reinforce company branding or an organizations's public image

Benefits :

• The user will :
• require less training,
• make less errors,
• be more satisfied and confident with system and job,
• be more productive.
• The developer can :
• reduce development times,
• reuse components,
• reduce arbitrary design decisions,
• maintain control over look and feel.

 Some Style Guide quality characteristics:

• Style Guides should be built on "good practice". Thus style guides evolve as more projects are implemented and as UID knowledge grows.
• Style Guides themselves should not be too cumbersome or lengthy.
• Use of Style Guides should be integrated into development process. Not simply used as a checklist at end of project.
• Developer should feel sense of Style Guide "ownership". Achieved through collaborative development of Style Guide. (Thus the title).
• Collaborative approach involves developers and end users. Necessary steps are:

1. Raising awareness among all concerned
2. Building consensus among all concerned
3. Documenting the style decisions resulting from the consensus
4. Providing training and support material to developer organization
5. Establishing environment that allows style guide to evolve

Sample Style Guide Contents:

• Who, When and How to use Style Guide
• Definition of principles
  (usability, consistency, flexibility, clarity, undo, etc)
• Application guidelines
  (navigation, interaction style, feedback, presentation styles, help)
• Application components (message boxes, toolbars, forms, etc)
• UI components (buttons, text boxes, scroll bars, etc)
• Internationalization considerations
• Compatibility with other style guides

• Privacy. To protect from unauthorized access to or disclosure of information.
• Safety and reliability. Poorly designed UI can kill (case of killer robot, x-ray)
• Copyright protection. Includes unauthorized copies.
  Who owns information in web pages and digital libraries, how may it be disseminated or electronically copied? Publishers are very concerned with this.
  For UI, major issues are copyright of widgets, "look and feel", copyright vs patent, etc.
• Ideas cannot be copyrighted, but expressions can.
• Many UI components not copyrightable (such as box or lines) but their composition may be. (can copyright song but not note)
• Patent provides shorter term of protection than copyright and is more difficult to obtain, but is more strongly enforceable.
• Patents can be applied only to "functional devices"'; copyrights to expressions.
• Equal access to disabled users. Very much a UI issue.

Last reviewed: 25 September 1998