woot woot lets go

2.7 Task analysis

  • PROCESSOR: GOMS model
    • strengths
      • formalizing user interaction
    • weakness:
      • doesnt address complexity like alternatives and parallels
      • assumes user is expert
  • 5 tips:
    • focus on small goals - eg navigate to end of doc
    • nest goals instead of operators - smaller goals. operators are smallest atoms
    • differentiate descriptive and prescriptive
    • assign costs to operators (usually time)
    • use goms to trim waste
  • PREDICTOR: Cognitive Task Analysis
    • emphasis on memory and cog load
    • specifically what you can’t see
    • collecting preliminary knowledge
    • identifying knowledge representations
    • apply focused knowledge elicitation methods
    • analyze and verify data acquired
    • format results for intended application
  • PARTICIPANT?: Hierarchical Task analysis
    • large tasks are very composed of smaller tasks
    • break out checkout process from purchasing process
    • strenght: emphasize mental processes
    • strength:
    • weakness: de emphasizing context
    • weakness: time intensive
    • weakness: ill suited for novices

2.8 Distributed Cognition

  • how a cockpit remembers its speed
  • four models of context! :)
    • distrib cognition: models of cognition outside the mind
    • social cognition: friend driving with you. jira. but be careful of letting them knwo everything
    • situated action: filming with daughter. task is what we do, not what we design. task grows out of the interface, not independently. memory is very context dependent as well.
    • activity theory: predates HCI.
      • why is user doing the task in the first place. not just -what- they are doing.
      • users can move up and down the hierarchy of activity -> action -> operator. the more competent you are - driving a car - the more of a subconscious operator it is
    • nardi - comparing activity theory and other thingies. incl permanent persistent structues

2.9 Interfaces and politics

2.10 Conclusion to principles

  • Processor: External
  • Predictor: Internal. Disappearing ui. gulf of execution/eval. understanding mapping, expert blindspot, learned helplessness.
  • Participant: Context.
  • 5 tips: on screen ui design
    • use a grid
    • use whitespace
    • know gestalt principles: proximity, continuation, movement, similarity
    • reduce clutter
    • design in grayscale

3.5: prototyping

  • verbal prototypes
  • paper prototypes
  • wiz of oz
  • wireframing
  • physical prototypes

5 tips:

  • keep prototypes easy to change
  • make clear that its a prototype
  • be creative
  • evaluate risks
  • prototype for feedback

3.6: evaluation

  • three types of eval: qual, empirical, predictive
  • eval terminology:
    • reliability - whether assessment is consistent over time
    • validity - whether it actually affects reality
    • generalizability - whether results can be extended
    • precision - level of detail
  • what to eval
    • efficiency - how long to accomplish?
    • accuracy - how many errors user commits?
    • learnability - how long does it take user to hit level of expertise?
    • memorability - does user rememberthe ui?
    • satisfaction - careful of social desirability bias
  • 5 tips: qual eval
    • run pilot studies to iron out the kinks
    • focus on feedback - dont spend too much time teaching one user
    • use questions when users get stuck
    • tell users what to do not how to do it
    • capture satisfaction - just ask if they even like it
  • 5 tips: empirical eval - categorical, interval, nominal, etc. see table.
    • control what you can, document what you cant
    • limit your variables
    • work backwards - decide what qtn you want to answer, then decide what you need to find out
    • script your analysis in advance, dont torture data
    • pay attn to power - size of effect inversely related to size of survey
  • predictive eval
    • heuristic eval (take the 15 things)
    • model based eval eg goms
    • siulation based evaluation

3.7 - agile and HCI

  • you want agile when:
    • low criticality
    • frequent requirements change
    • small teams
    • team embraces change
  • framework for agile and user centered design: http://www.ime.usp.br/~marivb/ihc3.pdf
    • the differences are:
      • imptnce of documentation
      • amount of research before getting it out to user
    • high user involvement
    • close team collab
  • live prototyping: oxymoron? optimizely. esp useful for ecom where costs are temporary but benefits can be permanent
  • a/b testing with real users
  • 5 tips:
    • start more traditional, then shift to agile once up and running
    • focus on small changes
    • adopt a parallel track method. have hci one sprint ahead of dev.
    • be careful with consistency. dont mess with expectations of frequent users
    • nest your design cycles - keep learnings from small cycles to big cycles

3.8 - conclusion to methods

http://omscs6750.gatech.edu/fall-2018/required-reading-list/

  • reading 7
  • reading 8
  • reading 9
  • reading 10
  • reading 11
  • reading 12
  • reading 13