MGMT Tech

  • Human-Centered Design (HCD)

    • HCD is a philosophy and set of procedures that add human (user) needs to the design process regardless of the areas of focus

    • Definition: An approach to system design that focuses on users' needs,

    • requirements, and social context

    • Goal: Create products and systems that are useful, usable, and meaningful to the intended users

    • Key Principle: Involve users throughout the design process

  • Affordances

    • The relationship between a physical object and a user's capabilities determines how the object could be possibly used (what actions are possible)

    • Definition: Affordances are the perceived possibilities for action in an environment or with an object

    • In Design: What users perceive they can do with an object or interface

    • Key Principle: Affordances should be clear and intuitive to users

    • Example: A door handle affords pulling; a flat plate affords pushing

  • Signifiers

    • Communicate where the action should take place, communicate to the user the device's purpose and how to use the device properly

    • Definition: Signifiers are perceivable indicators that communicate how to use something; Introduced by Don Norman to clarify the concept of affordances

    • Purpose: To make affordances more obvious and understandable

    • Key Principle: Good signifiers reduce cognitive load and increase usability

    • Examples: Labels, symbols, colors, shapes, or any perceivable indicator of functionality

  • Feedback

    • A continuous loop of input from users to designers

    • Informing the user that the system is working on the user’s request

    • Poor feedback and too much feedback is worse than no feedback

    • distracting & irritating (run the dishwasher at night beeps when done)

    • too much feedback results in users ignoring or disabling it

    • Prioritized – most important feedback structured to capture attention


  • Conceptual models

    • User forms mental models to understand and interact with a system or product

    • a simplified mental representation that a user forms to understand and interact with a system or product

    • Mental models exist in user’s minds of how things work (perceived structure)

    • Bridges user's understanding with the system's functionality

    • Shapes user expectations and interactions

    • Influenced by prior experiences, cultural background, and system design

    • Crucial for effective and intuitive user interface design

  • Abstraction

    • Create a simplified system representation without needing full system complexity

    • 1. Identifying Key Elements: Users focus on main features and functions

    • 2. Categorization: Grouping similar elements or actions

    • 3. Hierarchical Organization: Structuring information in levels of importance

    • 4. Analogy Formation: Relating new concepts to familiar ones

    • 5. Pattern Recognition: Detecting recurring elements or behaviors

      • Example:

      • Complex system: Smartphone

      • Abstracted model: Communication device with apps to accomplish various tasks

  • Minimize Simon chapter 1


Week 2 Finding the Design Problem Space

  • Double-Diamond Model of Design

    • Discover – First Diamond – Divergent Thinking

      • Research and gather insights

      • Explore user needs and context

    • Define - First Diamond - Convergent Thinking

      • Synthesize findings

      • Identify core problems

    • Develop - Second Diamond - Divergent Thinking

      • Generate ideas and potential solutions

      • Create prototypes

    • Deliver - Second Diamond - Convergent Thinking

      • Test and refine solutions

      • Select the final concept and implement

  • Human-Centered Design (HCD)

    • Observation – The designer defines a design problem and a design space.

      • What is the problem you are trying to solve?

      • Why is it important?

      • What’s the motivation to solve it?

    •  Idea generation: starting to think about ways to solve the problem.

      • Designers have to set out the range of viable solutions to a design problem

    • Prototyping: allows the designer to try out the chosen design solution without having to build it out completely [details to follow]

    • Testing the solution to make sure that it actually solves the problem identified

  • Iteration

    • The process encourages moving back and forth between phases as needed

  • Differences between tasks and activities

    • Activity

      • a high-level structure, such as “go shopping” a collection of tasks performed together

    • Task

      • a lower-level component, such as driving to the store, finding a shopping basket, following a shopping list an organized, cohesive set of operations directed toward a single, low-level goal

  • Standards and technology

    • Standardization provides a major breakthrough in usability because once you have learned something, you can apply that to a device of the same type (like with cars and driving)

    • Technology 

  • Design optimal solutions

    • Maximize the user's experience (economic utility) with the device or app based on the existing system constraints and environmental factor

    • Type of logic needed for design - satisfactory solution

    •  


Week 3 Symbolic Representation Systems: Introducing Unified Modeling Language

  • Unified Modeling Language (UML)


  • A class diagram is a blueprint that shows the structure of a system or subsystem by visualizing the classes that make up the system and the relationships between them

  • Deployment diagrams show the relationships between the software and hardware components in the system and the physical distribution of the processing

  • A component diagram is similar to a class diagram in that it illustrates how items in a given system relate to each other, but component diagrams show more complex and varied connections than most class diagrams can.

  • Use-case diagrams describe the high-level functions and scope of a system. These diagrams also identify the interactions between the system and its actors.

  • State Diagrams: states are represented as rounded rectangles labeled with state names. The transitions, represented as arrows, are labeled with the triggering events followed optionally by the list of executed actions.

  • Activity Diagrams: used to display the sequence of activities. Activity diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity.

  • Sequence Diagram: describes how—and in what order—a group of objects works together. These diagrams are used by software developers and business professionals to understand requirements for a new system or to document an existing process.

  • Symbolic systems in human-centered design


Week 4 Stakeholders, Process, and Design

  • Computer Supported Cooperative Work (CSCW)

    • These three problem areas escape adequate notice due to two natural but ultimately misleading analogies:

      • multi-user application programs and multi-user computer systems

      • multi-user applications and single-user applications.

    • These analogies influence the way we think about cooperative work applications and designers and decision-makers fail to recognize their limits

  • Why do CSCW applications fail

    • The application fails because it requires some people (who do not benefit from the app) to do additional work

    • The design process fails because of poor Hunan-centered design intuitions for multi-user applications

      • decision-makers only see benefits for people similar to themselves

      • they don’t see the implications of extra work required by others that don’t benefit

    • Failure to learn from the experience with the applications decision process

      • not identifying where the decision process breaks down

    • Computer-Supported Cooperative Work (CSCW)



  • Social design planning versus business planning


Week 5 Social Requirements and Technical Feasibility

  • Computer Supported Cooperative Work (CSCW)

    • Human activity in the social world is highly flexible, nuanced, and contextualized

      • Computer systems such as information transfer, roles, and policies need to process similar to this human activity

      • But, current computer systems cannot fully support the social world

  • People's nuanced behaviors

    • “Nuanced“ is people’s behavior of how and with whom they share info

      • whether to release information to someone due to the situation and impact

      • people may lack shared history, knowledge, meanings, and goals, so info may lose context

    • Social activity is fluid and nuanced, making systems technically difficult to construct properly and often awkward to use

    • Making their work visible may open them to criticism

    • People will not use a CSCW if enough users don’t exist (e-mail, synchronous communication, and calendars)


  • Social-technical gap

    • There is an inherent gap between the social requirements of CSCW and its technical mechanisms

      • The social-technical gap is the divide between what we know we must support socially and what we can support technically

      • CSCW needs to reduce this social-technical gap and one of the central problems for Human-Computer Interaction (HCI)


Week 6 Unified Modeling Language I: Structural Diagrams

  • Conceptual model

  • Three building blocks - things | relationships | diagrams

    • Things - abstractions that are first-class citizens in a model

    • Relationships – tie these things together

    • Diagrams - group interesting collections of things

  • Things - structural | behavioral | grouping | annotation

    • Structural

      • First - a class

      • Second - an interface

      • Third - a collaboration

      • Fourth - a use case

      • Fifth - an active class

      • Sixth - a component

      • Seventh - a node

    • Behavioral things are dynamic parts of UML models

      • First - an interaction

      • Second - a state machine

    • Grouping things are organized parts of UML models

      • A package

    • Annotation things are explanatory parts of UML models

  • Relationships - dependency | association | generalization | realization

    • Relationships are the basic relational building blocks of the UML

      • First - a dependency

        • a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing

      • Second - an association

        • a structural relationship that describes a set of links

      • Third - a generalization

        • a specialization/generalization relationship objects of the specialized element (child) are substitutable for objects of the generalized element (parent)

      • Fourth - a realization

        • a semantic relationship between classifiers

          • one classifier specifies a contract that

          • another classifier guarantees to carry out

  • Rules & mechanisms - specification | adornment | common division | extensibility mechanism

    • Specifications

      • Specifications provide the syntax textual statement and that building block’s semantics

        • Example - behind a class icon is a specification that provides the full set of attributes, operations and behaviors that the class embodies

      • Designers use UML graphical notation to visualize the system

      • Designers use UML specifications to state the system’s details

    • Adornments

      • UML elements have a unique and direct graphical notation that provides a visual representation of the most important aspects of the element

        • For example – the class notation design is easy to draw because classes are the most common element in modeling object-oriented systems

    • Common Divisions

      • First - a division of class and object - UML models both

        • a class is an abstraction and an object is one concrete manifestation of that abstraction

      • Second - separation of interface and implementation – UML models both

        • an interface declares a contract

        • an implementation represents one concrete realization of that contract

    • UML has three extensibility mechanisms:

      • Stereotypes

        • Extends the UML vocabulary to create new kinds of building blocks

          • derived from existing building blocks but

          • are specific to the design problem

      • Tagged values

        • Extends UML building block properties

          • to create new information in that element’s specification

      • Constraints

        • Extends UML building block semantics

          • designers can add new rules or modify existing rules

  • UML structural diagrams - class | deployment | component

    • A class diagram is a blueprint that shows the structure of a system or subsystem by visualizing the classes that make up the system and the relationships between them

    • Deployment diagrams show the relationships between the software and hardware components in the system and the physical distribution of the processing

    • A component diagram is similar to a class diagram in that it illustrates how items in a given system relate to each other, but component diagrams show more complex and varied connections than most class diagrams can.


Week 7 Unified Modeling Language II: Dynamic Diagrams

  • UML dynamic diagrams - use case | state | activity | sequence

    • Use-case diagrams describe the high-level functions and scope of a system. These diagrams also identify the interactions between the system and its actors.

    • State Diagrams: states are represented as rounded rectangles labeled with state names. The transitions, represented as arrows, are labeled with the triggering events followed optionally by the list of executed actions.

    • Activity Diagrams: used to display the sequence of activities. Activity diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity.

    • Sequence Diagram: describes how—and in what order—a group of objects works together. These diagrams are used by software developers and business professionals to understand requirements for a new system or to document an existing process.