LUCID Stage 3: User Interaction Design - Metaphors, Participatory & Conceptual Design, Study notes of Computer Science

The lucid stage 3 of user interaction design, focusing on creating a design metaphor, participatory design, and conceptual interaction design. It covers the importance of a conceptual model, the role of participatory design in developing a mental map of ui design, and the process of creating a conceptual interaction design model.

Typology: Study notes

Pre 2010

Uploaded on 02/13/2009

koofers-user-f0n
koofers-user-f0n 🇺🇸

9 documents

1 / 27

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Copyright © H. Rex Hartson and Deborah Hix. All rights reserved.
LUCID Stage 3 - 1
LUCID STAGE 3: DESIGN
Create a design metaphor, more detailed design
Begin a (minimal) user interaction style guide
Produce low fidelity prototype for early evaluation
Initially define basic design metaphor, including
navigation, screen layout, and visual design
Transition (finally!) from investigation/information
gathering to design
* Use information from requirements/task/user
analysis
Goals and corresponding LUCID activities (LUCID
tasks)
* Develop conceptual model/metaphor
* Develop low fidelity prototype and perform initial
usability evaluations
* Perform usability inspection of initial design
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b

Partial preview of the text

Download LUCID Stage 3: User Interaction Design - Metaphors, Participatory & Conceptual Design and more Study notes Computer Science in PDF only on Docsity!

LUCID STAGE 3: DESIGN

  • Create a design metaphor, more detailed design
  • Begin a (minimal) user interaction style guide
  • Produce low fidelity prototype for early evaluation
  • Initially define basic design metaphor, including navigation, screen layout, and visual design
  • Transition (finally!) from investigation/information gathering to design
    • Use information from requirements/task/user analysis
  • Goals and corresponding LUCID activities (LUCID tasks)
    • Develop conceptual model/metaphor
    • Develop low fidelity prototype and perform initial usability evaluations
    • Perform usability inspection of initial design

CONCEPTUAL MODEL/METAPHOR

  • Conceptual model/metaphor is basis for specific UI design
    • Metaphor is optional, model required
      • Conceptual model, intuitively, is what product system is and does.
      • Metaphor is analogy with something existing in real world with similarities that can be leveraged for learning new system
    • Helps designers and therefore users develop mental map of UI design
  • Conceptual model vs. technical model
    • Technical model — implementation of software architecture (widgets, data structures, files, etc.)
    • User interaction design vs. user interface software design, revisited

PARTICIPATORY DESIGN

  • PICTIVE (Plastic interface for collaborative technology initiatives through video exploration) — example of participatory design technique
    • Users actually sketch UI design
    • Then use paper, plastic, tape, sticky notes, etc. to create low-fidelity prototype
    • Users then perform scenario walkthrough, which is recorded using video camera
    • Video can be shown to other users and designers, managers

WHAT CAN WE GET FROM TALKING WITH

USERS?

  • Outside of participatory design:
    • You don't get design
    • It's not about whether users know what's best for them – you're not asking that
    • You are asking what they do
      • Most of what users talk about is often not quite the right stuff
      • You have to build the picture of what they need via task analysis and scenarios
      • Then test to see if it works

CONCEPTUAL INTERACTION DESIGN

  • Example of conceptual model/metaphor for Y2K Calendar: A paper calendar, but extend it to include views of day, week, month, and year (which a single paper calendar cannot do) plus direct searching
  • Can have more than one design concept
  • Design concept(s) can iterate and change, sometimes dramatically
  • Design concept(s) may be controversial
  • Concept description accompanied by screen sketches to show key aspects of proposed design
    • As these are initial design, want them to encourage comment and iteration
  • Evaluate design concept(s) by discussion with team and key users (including different user classes)
  • Choose design concept from evaluation results
    • Could mean merging parts of two or more concepts

CONCEPTUAL INTERACTION DESIGN

- Goal: * To create a high-level (independent of appearance) design model with a metaphor - Activities: * Identify application objects, their properties, and relationships among them * Decide how objects will be viewed conceptually (not details of appearance) in interaction design * Decide how user will access those objects * Determine operations to be performed on the objects as a result of user tasks * Decide how to invoke and carry out those operations

CONCEPTUAL INTERACTION DESIGN

  • Conceptual design model continued
    • Access methods : How users get at the objects
    • Accessing an existing appointment
      • By viewing, possibly preceded by search or navigation through views
    • Invoking and carrying out operations on objects
      • Menu? Pull-down?
      • Small, fixed number of commands
      • Implication for interaction style: Buttons or icons?

INITIAL SCREEN DESIGN

- Goal: * To develop together an initial design/layout for the screen(s) and other interaction objects - Assumption: * Generic desktop platform (not specific to Windows, Mac, etc.) - Activities: * Draw pictures of screens, including menus, buttons, icons, application objects * Label objects with behavior as appropriate

EXERCISE:

ITERATE CONCEPTUAL DESIGN MODEL

  • Conceptual design model revisited
    • Access methods to appointment objects by:
      • Selection and navigation on desk top
      • Search on content (user types string to match)
    • Decisions about container objects
      • Default display: Several months overlapped, with current month on top
      • In higher level objects user can select lower level objects (view control)
      • Try to show as much appointment information at each level as possible (page preview idea)
    • Appointment editing
      • Keep it simple (it’s not a word processor)
      • Do only at appointment slot (hour) level
      • For add, modify, delete

ITERATE INITIAL SCREEN DESIGN

  • Month level (current month is default)

3DVW0RQWK

6HDUFK +HOS )XWXUH0RQWK 0D\ 'HOHWH$SSRLQWPHQW 0DUFK$SULO 681 021 78( :(' 7+8 )5, 6$       (^)      (^)    (^)  681 021 78( :(' 7+8 )5, 6$7

     6$785'$<0$5&+   

6HOHFW:HHN 6HOHFW:HHN 6HOHFW:HHN

ITERATE INITIAL SCREEN DESIGN

  • Week level :HHNRI^ :HHNRI :HHNRI (^681021) 78(6:(' 0RQWKYLVLEOH IRUVHOHFWLRQ $SSRLQWPHQWVIRUZHHN DUHIRUPDWWHGWRILWVTXHH]HG LQ
  • Format of week can use improvement
  • Day level 1RFORVHER[NHHS RQGHVNWRS

6FUROOXSRUGRZQWRPLGQLJKW

^ 021'$<2&72%(5 

+(/3 (^)  '(/(7($33 7

&OLFNKHUHWRHGLW W\SH

  • Appointments saved when deselect

USER INTERACTION STYLE GUIDE

  • Style guide documents visual design decisions and other general design decisions, to help ensure consistency
  • Used by interaction designers and developers
  • If long, should contain an "overview" sheet up front that includes the most important design decisions for most frequently-used interaction design elements
  • Style guide should include details of:
    • Font and text usage
    • Color usage, background graphics, other common design elements
    • Icon usage, position, and design
    • "Widget" usage, position, and design – dialogue boxes, menus, message windows, toolbar, etc.

SCENARIO-BASED DESIGN

  • Design situations are fluid; written specifications are rigid
  • Scenario-based design is bottom-up design; needs to be mixed with some top-down structuring
  • Where do scenarios come from?
    • Brainstorming
    • Ethnographic field studies
    • Participatory design
    • Reuse of similar designs
    • Don't forget to include error and recovery scenarios
  • Scenarios reveal requirements
    • Scenarios can reveal how tasks will be carried out and how system will enable functionality for tasks

SCENARIO-BASED DESIGN

  • Scenarios should capture and make obvious in your design:
    • Tasks
    • Task threads
    • User interface objects/artifacts
    • User actions on objects
    • User planning, thoughts, and reactions to system
  • It works well to sketch screen designs to go with the scenarios as you go along