Today: AF Chapter 1 – Goal-Directed Design AF Chapter 2 - Implementation Models and Mental Models

Initiate The Evolution of the Software Development Process Design begins to precede the programming process… Formally defining the user and the user’s goals drives the entire development effort Testing and design became separate steps… Testing in case the code needed fixing; GUI design after coding was done Code/TestShip Originally, programmers did it all… Design, code, test, and ship PROGRAMMERS Code/Test Managers brought order… Understanding the market and the competition PROGRAMMERSMANAGERS CodeShip PROGRAMMERS Initiate MANAGERS Test GUI Design QUALITY ASSURANCEDESIGNERS DesignShip DESIGNERS Initiate MANAGERS Code Bug Test PROGRAMMERSQUALITY ASSURANCE User Test USABILITY PRACTITIONERS Ship

What do people desire? Of the things people desire, what will sustain a business? Of the things people desire that will sustain a business, what can we build? Building Successful Software Balancing Desirability, Viability, and Technology OBJECTIVE: A PRODUCT THAT IS DESIRABLE, VIABLE, AND BUILDABLE Common Error #1 Emphasize Technology & Ignore Desirability (e.g., Silicon Graphics) Common Error #2 Emphasize Desirability & Ignore Viability (e.g., Napster) Common Error #3 Emphasize Viability & Ignore Desirability (e.g., Microsoft)

Bridging The Research/Design Gap The Traditional Model RESEARCH Performed by market analysts and ethnographers (immersive cultural observers) DESIGN Performed by graphical interface and industrial designers The Goal-Directed Design Model RESEARCH Interview the user and observe the domain MODELING Analyze the field research, looking for patterns REQUIREMENTS Define and prioritize the needs of the user and the business FRAMEWORK Use design patterns and principles to conceptualize design REFINEMENT Clarify, revisit, validate, and, finally, document the design

Overview: Goal-Directed Design Process Research & Modeling Who will use the product? What problem will it solve for them? Requirements & Design What is the product and what does it contain? What does it look like and how does it behave? Scope Define the project’s intent and constraints Audit Review existing work and product Interviews Discuss values, issues, and expectations Observations Apply ethnographic research techniques Personas Define typical users Goals Deduce what users want Requirements Imagine a system to help users reach goals Scenarios Tell stories about ideal user experiences Elements Derive components based on users Framework Organize the components Specifications Refine details and describe models

There is frequently a marked contrast between the user’s mental model of how software works and the developer’s implementation model of how it actually works. Chapter 2: Implementation Models and Mental Models

User’s Mental Models Example: A scientist’s mental model of a technical paper Title Authors Abstract Body Body (end) References Body (cont.) The user’s mental model of the process of searching for and purchasing an article from an on-line system Key Assumptions: Articles are peer-reviewed and published in journals Articles are first published in print & later on-line Articles are available in publisher’s on-line database Article and meta-data are stored in the same place Paying for articles is a reasonable business expense

Developer’s Implementation Models An implementation model of a technical paper Key Assumptions: Articles are peer-reviewed and published in journals Articles are simultaneously published in print & on- line Article data and meta-data are stored on separate databases (technical constraint) Paying for articles is a reasonable business expense Article: Collection of Related Information Meta-Data: Authors Title Abstract References Publication Date Journal Volume/Issue Etc. Data: Article Text Figures Tables The implementation model of the process of searching for and purchasing an article from an on-line system

Designer’s Represented Models Should the designer represent the software to the user in a manner closer to the developer’s implementation model...? … or closer to the user’s mental model? Happy Developer Unhappy User Unhappy Developer Happy User The designer must develop a third model that combines the simplicity of the user’s mental model with the technical veracity of the developer’s implementation model.

Design Methods Supporting Mental Models 1. Simplicity Mental models simplify reality, so interface design should simplify actual software functionality. Include only needed functions Make frequently used functions immediately apparent Avoid cluttering the interface with advanced functions Organize the interface to fade into the background, allowing users to focus

Threshold of Indignation At what point does the performance of a software product fail to compensate for its complexity of use? Threshold of Indignation Willingness/ Ability to Pay

Consumer Trends As time progresses, the attitudes of consumers change… Threshold of Indignation Willingness/ Ability to Pay Individual Consumers Can’t pay more, but willing to endure greater complexity as they become more accustomed to old complexity and as features expand Industrial/Military Consumers Willing to continue high payments as long as technology improves in performance and becomes easier to use

Software Industry Trends As time progresses, the technological and business sides of the software industry evolve… Threshold of Indignation Willingness/ Ability to Pay Business Expansion Customer base tends to lose regard for business if prices decrease, but will not accept increases without being convinced of technological advances High-Tech Products Mass production and technological progress improve performance (lessening resistance to complexity) while lowering costs

Design Methods Supporting Mental Models 2. Familiarity An interface should build on users’ prior knowledge and experience. Allow users to start quickly and make immediate progress Consistency in an interface reduces a user’s learning curve

Design Methods Supporting Mental Models 3. Availability An interface should provide visual cues, reminders, lists of choices, etc., automatically or on request. People are better at recognition than at recall Avoid relying on the user for file names, previous settings, etc.

Design Methods Supporting Mental Models 4. Flexibility An interface should support alternate interaction techniques. Allow users to choose the interaction method most appropriate to their situation Allow users to use any object in any sequence at any time Accommodate a wide range of user skills, physical abilities, interactions, and usage environments

Design Methods Supporting Mental Models 5. Feedback An interface should provide complete, continuous feedback regarding the actions taken. Feedback supporting the current mental model reinforces it Feedback contradicting the current mental model forces it to be modified

Design Methods Supporting Mental Models 6. Safety Users should feel confident in exploring, knowing that they can try an action, view the results, and then undo the action if the result is unacceptable. Users feel more comfortable with interfaces in which their actions do not cause irreversible consequences.

Design Methods Supporting Mental Models 7. Perceived Affordances Users often conclude what can and cannot be done with an interface just by examining its appearance. By using real-world representations of objects within its interface, a software system can provide users with an intuitive sense of the system’s affordances. WHERE”S THE “ZOOM” ICON? PRINTPREVIEW DOCUMENTMAP ZOOM