Usability and Human Factors Approaches to Design Welcome to Usability and Human Factors, Approaches to Design. This is lecture a, which provides an overview of the process of design. We will introduce a couple of approaches known as Interaction and User-Centered Design. Then we will discuss Lifecycle Models, which provide an overview of the software engineering process. We will pay special attention to the Usability Engineering Lifecycle Model. Subsequently, we will explore the ways in which prototypes shape the design process. The process of Participatory Design which, engages users as designers, is illustrated in the context of an interesting case study about software for children with cancer. Lecture a This material (Comp 15 Unit 8) was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003. This material was updated by The University of Texas Health Science Center at Houston under Award Number 90WT0006. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/. Health IT Workforce Curriculum Version 4.0

Approaches to Design Lecture a – Learning Objectives Explain a user-centered design approach (Lecture a) Define conceptual models (Lecture a) Explain the iterative design process Describe how requirements analysis influences design The objectives of this lecture are for the student to be able to demonstrate an ability to explain a user-centered design and define conceptual models of design. Specifically, they should be able to explain an iterative design process and describe the ways in which requirements analysis shapes the design process. Therefore, by the end of this unit students will be able to:   1. Explain a user-centered design approach 2. Explain the iterative design process 3. Describe how requirements analysis influences design 4. Characterize the role of prototypes in design 5. Describe the principles of participatory design 6. Describe principles of sound design to support usability 7. Describe how Nielsen’s heuristics and design principles apply to user interface design 8. Explain the difference between low fidelity and high fidelity prototypes and when it would be appropriate to use one versus the other

Design A plan or scheme conceived in mind and intended for subsequent execution Tradeoffs balancing conflicting requirements Generating alternatives Use representations Diagrams, prototypes What do we mean by design? It refers to both a process of producing artifacts and a discipline devoted to the study of that process. The focus in this lecture is on software design; however, much of it would be relevant to other spheres of design as well. Whether we are talking about architectural or automotive design, they all engender a creative process in which something is produced to satisfy a population of users. They all must balance tradeoffs and sometimes, conflicting requirements. Design concepts are communicated via representations such as diagrams and prototype sketches.

Interaction Design Focus on Users Specific Targets Iteration Usability Experience Iteration Key Question: How to optimize the users’ interactions with a system so they support and extend users’ activities in effective, useful and usable ways Interaction Design is a broad-based approach that places a premium on the role of the user in design. The focus is on enhanced usability and on the user experience. The approach is committed to an iterative approach leading to refinements. The key question is how to optimize the users’ interactions with a system so as to support and extend users’ activities in effective, useful and usable ways.

Why All the Fuss About Design? Documented usability problems in healthcare and their consequences Clinical information systems present problems in implementation & beyond Many systems do not adequately address customer specifications Fixing a problem in development phase costs 10 times more than in design phase Really, why all the fuss about design? Why is it a process we need to worry about? We would all agree that design choices are consequential in the arena of health. Many of you have learned about the numerous usability problems and the ways in which they can compromise patient safety. We also understand the immense challenges involved in implementing clinical information systems. In addition, there is evidence to suggest that fixing a problem in the development phase may cost 10 times more than it does in design phases.

Costs to Fix Software Defects This graphic, by IBM, dramatically illustrates this point. They show that the cost of fixing software defects, once the product has gone into the use/maintenance phase, is 100 times the cost of fixing defects up front in the design phase. No one truly disputes that sound design can make a significant difference. Let’s now look at design and engineering. Edwards, D. (n.d.)

People in Software Engineering Fundamentally a human and labor intensive activity User (or customer) Product manager Software engineers and programmers Quality Assurance / Testers: Alpha testing Beta Technical writers Implementers and trainers Software engineering is fundamentally a human and labor intensive activity. The user or customer: Has a need. How well can the customer express/articulate the requirements? Are the requirements ambiguous, unclear, and conflicting? The product manager: is responsible for collecting requirements and writing specifications Software development: understands the needs of the customer to develop, implement, and deliver the software Programmers: follow the instructions in the functional specifications and write the code Quality assurance or software testers: these are not the same (or should not be the same!) as any of the above groups of people. QA staff develop and follow scripts that define how the software should perform and check whether or not it performs correctly. There are different levels of quality assurance testing: “alpha” testing often performed by programmers, and “beta” testing by external groups, sometimes in return for early access or discounted software Technical writers: writes the software manuals describing what the software does and how to use it Implementers and Trainers: Guide the hospital through the configuration and implementation of the software and training of end users

Usability Engineering Requirements Analysis Conceptual Mockup Screen Design Standards Prototype Detailed UI Design Install Feedback Enhancement Now that we understand who is involved in software engineering, let’s look specifically at the user and usability engineering. Usability engineering is a field or an approach oriented towards accentuating the user experience in the design process. How can we make the system more intuitive and easy to use? The following are the steps involved in the process from a usability engineering perspective. We will particularly devote some time to discussing requirements analysis and conceptual mockups.

A User-Centered Approach Early focus on users and task Cognitive, behavioral & attitudinal characteristics Nature of tasks performed Empirical measurement Study of users Iterative Design Design and development are responsive to user problems Cyclical process One of the central themes of interaction design and usability engineering is the importance of a User-Centered Approach. Indeed, it is a central focus of this unit on design. There are three core commitments to this approach, which includes a focus on users and tasks very early in the design and conceptualization process. The approach is also predicated on empirical measurement of users both prior to having used the system and while using the system. The measures and observations of performance feed into an iterative design process.

TURF Model (Zhang & Walji 2011) The concept of the user and the task that the user is trying to do has been incorporated into Zhang and Walji’s TURF model, which states that there are four aspects of usability – the task that the user is trying to do, the characteristics of the user, how information is represented, and functionality of the system. Let’s talk about each of these. Different users have different types of knowledge; for example, physicians, nurses, laboratory technicians, ward clerks, and each patient have different knowledge, experience, education, computer experience, cultural background, personality, work experience, time available for learning, and so on. Likewise, the task each user is trying to do at the computer is different. One may be trying to set up an appointment, admit a patient, or write a note or prescription. For functionality, think about a paper record. Paper cannot interpret what is being written on it and then display a message in response to that input. It simply doesn’t have that functionality. Finally, the R in the TURF model is Representation, or how something such as a number is presented. (Zhang & Walji 2011)

Focus on Users and Tasks Users’ tasks and goals drive development Focus on user behavior and context of use System designed to support them Capture characteristics of users (capabilities & constraints) Users are involved from the inception through cycles of iterative development All design decisions taken within context of users, their work and environment Let’s expand on the idea of focusing on users and tasks. In a User-Centered Approach, they drive the development process. The system in question is designed to support humans in facilitating performance on a task like determining a patient’s prior health status, for example, by retrieving electronic documents in a clinical information system. The system needs to be shaped by an understanding of the capabilities as well as the limitations of the user (e.g., attention and memory constraints). The User-Centered Approach emphasizes that users are involved from the inception through cycles of iterative development. Furthermore, all design decisions are influenced by user considerations.

Design Process This diagram illustrates an iterative design process. First, we begin with a needs/requirements analysis leading to the development of design alternatives. Then, we create prototypes, which take shape as actual products. These are implemented in practice and subject to rounds of evaluation.

Design Thought Exercise Imagine you organize your books, CDs and DVDs into a system/database that provides easy access to all information that you need Imagine doing it for a friend or your father who is just learning to use a computer Here’s a little design thought experiment. The goal is to wrap your head around some of the issues connected to the design process. Imagine you were going to organize all of your books, CDs and DVDs into a system or database that provides easy access to all the information you need. This is a task that seems daunting for some of us. Now, imagine you were going to put together a system for someone else and perhaps that person was less computer savvy than you. Kaufman, D. (2012).

Think About the Space Problem What are we trying to accomplish? Organizing content Supporting tasks Ease of access, support queries Users with different skill levels Support different displays (desktop, laptop, iPhone, tablet) Define conceptual model Think through the process of how you would provide functions for organizing the content, retrieving information and responding to queries such as how many Woody Allen movies do you have in your DVD collection? How might you design a display for your iPhone or tablet, such as an iPad? The goal is not to think about software development or even what an interface would look like; rather, it is the conceptual model or abstract structure that would support such a task.

Conceptual Model Abstraction outlines what people can do with a product and concepts needed to understand how to interact with it Structure outlining the concepts and relations that form the product—not the user interface Metaphors used to convey a product Concepts including the task domain objects, their attributes and operations that can be performed Mappings between concepts and user experience What do we mean by a conceptual model? It refers to an abstraction that outlines what people can do with a product and concepts needed to understand how to interact with it. It provides a structure outlining the concepts and relations that form the product—not the user interface. These concepts include the task domain objects, their attributes and operations that can be performed. For example, the task domain may be personal health, the objects are the data that inform you about your health and these particular findings or personal data have attributes. For example, you may have last had a checkup 13 months ago. The conceptual model also defines mappings between concepts and user experience.

Visicalc Wikimedia Commons GNU General Public License Why are we showing you a display of a program that was used many years ago? VisiCalc was the first spreadsheet program available for personal computers. It was something of a revolutionary product and according to some insiders, it turned the personal computer, initially a toy for electronic hobbyists and other geeks, into a serious business machine. What makes this of interest to us is that it was predicated on a robust conceptual model. Incidentally, the program was not a great commercial success, but it laid the groundwork for other spreadsheet programs, most notably, Microsoft Excel. Wikimedia Commons GNU General Public License

Visicalc Conceptual Model First spreadsheet-a robust conceptual model (CM) that endures Key goals of CM: Create a piece of software analogous to a ledger sheet — already familiar to users Make it interactive allowing user to input and change data in any of the cells Perform a range of calculations in response to user input Target a range of users The core elements of the conceptual model (CM) were to produce an intuitive, easy to use and familiar product that everyone can relate to. The spreadsheet was modeled on a ledger sheet, which is an artifact that is familiar to most people running a business as well as accountants and so forth. It was designed as an interactive tool allowing users to input and change data in any of the cells. The program performed a range of calculations in response to user input. It was designed to be used by anyone needing to do calculations and therefore targeted a range of users. Thus far, we have said nothing about the program’s architecture or even its interface. The CM is used to derive a set of abstract goals and these goals may be achieved many different ways.

Represents activities involved in the design process Lifecycle Models Represents activities involved in the design process Prototypical Models Waterfall Spiral RAD Star Usability Engineering Lifecycle Models impose a structure on the software development process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Lifecycle Models are important topics in software engineering. We will be selective in our presentation, given that our focus is on human computer interaction. Specifically, we will talk about the Waterfall, Star and Usability Engineering models. We will explore the usability engineering lifecycle in greater detail than the others.

Waterfall Lifecycle Model This diagram illustrates the 5-step process in the Waterfall Lifecycle Model, beginning with a requirements analysis, onward to the different phases of the development process including design, code, test and maintain.

Waterfall Model The original model for software engineering Linear model with clearly delineated tasks Problems No central role for users/no iteration and limited feedback Too rigid—not responsive to requirement changes Inconsistent with designers inherently nonlinear work practices The Waterfall Model is the original model for software engineering and was immensely influential. It is a linear model with tasks that follow each other in a clearly defined sequence. There are known problems with the model, including the fact that: users don’t play a central role 2) it doesn't really allow for iterative design and 3) it isn’t responsive to changes in requirements that ensue during the development process. The model was also found to be inconsistent with designers’ inherently nonlinear work practices.

Star Lifecycle Model (Preece, J., Rogers, Y., & Sharp, H. 2007) One can visually see the ways in which the star model differs from the waterfall model. It is a model designed to afford considerable flexibility and support creativity in the design process. (Preece, J., Rogers, Y., & Sharp, H. 2007)

Star Lifecycle Model (Cont’d – 1) Inherently nonlinear—does not specify ordering of activities Accentuates bottom-up, free thinking and creative practices of designer Evaluation is viewed as integral to all stages and continuous Problem: Too much flexibility, lack of systematic coordination and process is underspecified It does not specify any ordering of activities. The model accentuates freethinking that is believed to be more typical of the practices of designers. Evaluation is viewed as integral to all stages and continuous. The problem with the Star Model is that it does not specify a structured process. Therefore, it affords TOO MUCH flexibility and makes systematic coordination among developers to be rather difficult.

The Usability Engineering Life Cycle This model was developed by Deborah Mayhew in 1999, though others such as Jakob Nielsen also played a role in its gestation. The Usability Engineering Lifecycle Model is one of much greater complexity and detail. As the title suggests, usability goals are central to all phases of the design process. The details of the model are beyond the scope of this class. However, the diagram nicely illustrates the importance of requirements analysis and the multistep approach which is cyclical or iterative in nature. (Mayhew, J.D. 1999) Health IT Workforce Curriculum Version 4.0

Usability Engineering Lifecycle (UEL) Developed by Mayhew (1999) with the goal of thoroughly integrating usability considerations into all phases of design Core aspects/superordinate phases: Requirements analysis Design/testing/development Decomposed into levels & detailed sub-processes The model consists of 2 phases: 1) a requirements analysis phase and 2) a design/testing and development phase. In addition, each of these can be decomposed into sub processes and the second phase can also be broken down into levels of design from early stages to the latter stages of development.

UEL Requirements Analysis User(s) Profile Specific user/population characteristics related to interface design Contextual task analysis Users’ current tasks, workflows and conceptual frameworks Usability goal setting Qualitative and quantitative goals reflecting minimal acceptable performance Platform capabilities and constraints General design guidelines We have previously discussed requirements analysis earlier in this lecture and in prior units. For the present purposes, it is important to understand the emphasis on profiling the user characteristics and accentuating the contextual elements of task analysis. This refers to the need to understand tasks in the context of workflow, for example, in a particular setting situated or in a given organization. Usability goal setting is a novel aspect of Lifecycle Models. The design process is oriented towards meeting specific qualitative goals such as user satisfaction and quantitative ones such as speed and accuracy.

UEL Design Phase: Level 1 Design Work Re-engineering Based on requirements analysis Abstract organization and workflow Conceptual Model (CM) Design/Mockups Navigational pathways and major displays are identified Expressed as paper and pencil or prototype Iterative CM Evaluation Mockup is evaluated as if it were a real interface This phase is largely devoted to translating requirements into conceptual models. Navigational pathways and major displays are identified and expressed as prototypes. The models are then subjected to evaluation and there is an iterative process.

UEL Design Phase: Levels 2 and 3 Screen Design Standards/ Prototyping & Evaluation Standards, conventions and themes applied to all screens Formal usability testing evaluation Standardized and validated as a style guide Detailed User Interface Design Based on refined conceptual model and screen design standards Iterative Detailed User Interface Design Evaluation Expanded usability evaluation to unassessed subsets of functionality and categories of users Each upward level reflects a progression in the crystallization of standards, conventions and themes leading to the development of a style guide that is applied to all screens. Level 3 moves towards a more concrete level of detail in the development of software. In addition, user interface design evaluation takes on an increasing prominent role. The model also specifies a need to ask whether usability goals gave been met.

Approaches to Design Summary – Lecture a Focus on design as a plan or scheme conceived in mind and intended for subsequent execution Tradeoffs Conceptual model outlines what people can do with a product and ways to understand how to interact with it Design Lifecycles Up next: focus on requirements, prototypes and participatory design This concludes lecture a of Usability and Human Factors, Approaches to Design. In summary, our focus has been on the process of design as a scheme leading to a product designed for particular users and tasks. We discussed the role of conceptual models in articulating the shape of design and considered three design lifecycle models. In the next lecture, we will discuss the role of requirements in influencing the design process, examine the development of prototypes and introduce the participatory design process.

Approaches to Design References – Lecture a Kaufman, D.R., Pevzner, J, Hilliman, C., Weinstock, R.S., Teresi, J. Shea, S. & Starren, J. (2006). Re-designing a telehealth diabetes management program for a digital divide seniors population. Home, Healthcare, Management & Practice. 18: 223-234. Hilliman, C.A., Cimino, J.J., Lai, A.M., Kaufman, D.R., Starren, J.B., Shea, S. (2009). The effects of redesigning the IDEATel architecture on glucose uploads. Telemed J E Health. Apr;15(3):248-54. Zhang, J., & Walji, M. F. (2011). TURF: Toward a unified framework of EHR usability. Journal of Biomedical Informatics, 44(6), 1056-1067. Images Slide 6: Edwards, D. (n.d.) DevOps: Shift left with continuous testing by using automation and virtualization. Retrieved from https://www.ibm.com/devops/method/images/experiences/relative-cost-to-fix-defects-chart.png Slide 10: Zhang, J., & Walji, M. F. (2011). TURF: Toward a unified framework of EHR usability. Journal of Biomedical Informatics, 44(6), 1056-1067. Slide 13: Kaufman, D. (2012). Design through exercise. Personal picture- Department of Biomedical Informatics, Columbia University Medical Center. Slide 16: Retrieved August 20th, 2010 from Wikimedia Commons GNU General Public License http://upload.wikimedia.org/wikipedia/commons/7/7a/Visicalc.png. Slide 21: Preece, J., Rogers, Y., & Sharp, H. (2007). Interaction Design: Beyond Human-Computer Interaction (2nd ed.). West Sussex, England: Wiley. Slide 23: Mayhew, J.D. (1999). The Usability Engineering Lifecycle: A Practitioner’s Guide to User Interface Design. Morgan Kaufmann Publishers Inc., California. No Audio.

Usability and Human Factors Approaches to Design Lecture a This material was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003. This material was updated by The University of Texas Health Science Center at Houston under Award Number 90WT0006. No Audio. Health IT Workforce Curriculum Version 4.0