Design by suchenfz

VIEWS: 18 PAGES: 45

									Managing Design Processes

            Shneiderman and Plaisant
                   Chapter 3
 (from slides at http://wps.aw.com/aw_shneider_dtui_4/, Preece publisher, Ch. 6, 12)
                                        Overview
•   Organizational design to support usability
     –   Shneiderman talks about both ―design‖ and the organizational context in which it occurs

•   Carroll and Rosson‘s characterization of design
     –   ―radically transformational‖

•   Shneiderman‘s ―three pillars of design‖
     –   Guidelines documents and processes
     –   User interface software tools
     –   Expert reviews and usability

•   Development methodologies
     –   IBM: Ease of Use, Lucid

•   ―Ethnographic‖ user observation
•   Participatory design
•   Scenario development
•   Social impact statement for early design review
•   Legal Issues
                      Introduction
• Note and recall that early on programmers designed for
  programmers
   – That was fine then, and has its place now

• However, usability engineering has become the norm
   – E.g., low fidelity prototypes, revisions based on feedback from
     users, incremental refinement, testing, observation, etc.
   – Usability engineering as a part of the design process
       • Interspersed with implementation


• Usability Professionals Association
Usability Professionals Association


 • http://www.upassoc.org/
Organizational Design to Support Usability, 1

  • Human factors laboratories
          • Organizationally, usability engineering included here
     – Business case has been often made:
          • Software projects do fail
          • E.g., correction of 20 easiest to correct faults increase success rates from 19% to as
            much as 80%
     – Projects have ―user interface architect‖ and ―usability engineer‖
          • ―Usability group in a human factors laboratory‖

  • Big idea about why hard to design good user interfaces:
     – Part of the challenge of interface design, implementation, testing, etc., is that it is
       embedded in a design process of the (application) software itself, as well as
       entailing its own design process

  • And for that matter, in all cases design is complex
     – Design is inherently creative and unpredictable.
          • ―Interactive system designers must blend knowledge of technical feasibility with a
            mystical esthetic sense of what attracts users‖, Shneiderman
               – As does all design
Organizational Design to Support Usability, 2

  • Variety of design situations precludes comprehensive design
    strategy
     – Depends on time, budget, organization, personell, …
     – Will see different variations, e.g., IBM‘s: Ease of Use works for that
       (large) organization

  • Shneiderman says “each of project should have its own user
    interface architect”
     – That would be nice … and why not a usability engineer or two …

  • All should understand a bit about design
     – Carroll and Rosson‘s account well known in user interface community
                 Carroll and Rosson‘s
                Design Characterization
• What is design? – a thoughtful, realistic, well-know characterization

• Design is a process, not a state
     –   This precludes a static characterization

• The design process is nonhierarchical
     –   Neither strictly top down or bottom up
     –   Simple understanding of design as ―top down‖ is in part pedagogic and with experience is
         abandoned

• The process is radically transformational
     –   Partial and interim solutions may play no role in final design
     –   You throw designs away

• Design intrinsically involves (even) the discovery of new goals
     –   I.e., reconceptualizing the problem, and its goals
     –   Hence, can’t be top down

•   Nonetheless, as in any creative domain, can be discipline, refined techniques, right
    and wrong methods, and measures of success
    So, What is Interaction Design?
                                            (supplementary)

•   Quick overview … Preece‘s take … the basic ideas…rather more general than Shneiderman‘s two
    methodologies … ―a rose by any color …‖

•   What?
     –   Four basic activities
     –   Three key characteristics

•   Some practical issues
     –   Who are the users?
     –   What are ‗needs‘?
     –   Where do alternatives come from?
     –   How do you choose among alternatives?

•   Will see:
     –   Lifecycle models from software engineering
     –   Lifecycle models from HCI

•    It is a process:
     –    a goal-directed problem solving activity informed by intended use, target domain, materials, cost, and
         feasibility
     –    a creative activity
     –    a decision-making activity to balance trade-offs

•    It is a representation:
     –    a plan for development
     –    a set of alternatives and successive elaborations
        What is interaction design?
                                          (supplementary)

•       Four basic activities in Interaction Design:
    –          1. Identifying needs and establishing requirements
    –          2. Developing alternative designs
    –          3. Building interactive versions of the designs
    –          4. Evaluating designs

•       Three key characteristics permeate these four activities:
    –          1. Focus on users early in design and evaluation of artefact
    –          2. Identify, document and agree specific usability and user experience goals
    –          3. Iteration is inevitable.
           •       Designers never get it right first time

•       Some practical issues
    –          Who are the users?
    –          What are ‗needs‘?
    –          Where do alternatives come from?
    –          How do you choose among alternatives?
Who are users and ―stakeholders‖?
                                      (supplementary)

 •   I.e., for whom is the product designed?

 •   Picture next

 •   Not as obvious as might seem:
      –   those who interact directly with the product
      –   those who manage direct users
      –   those who receive output from the product
      –   those who make the purchasing decision
      –   those who use competitor‘s products

 •   Three categories of user (Eason, 1987):
      –   primary: frequent hands-on
      –   secondary: occasional or via someone else
      –   tertiary: affected by its introduction, or will influence its purchase
  Who are users and stakeholders?
                                                      (supplementary)

- interact directly with the product
         - manage direct users
         - receive output from the product                              Check-out operators
         - make the purchasing decision
         - use competitor‘s products

-primary: frequent hands-on
-secondary: occasional or via someone else
-tertiary: affected by its introduction, or will
influence its purchase




             • Suppliers
             • Local shop
               owners

                                               • Managers
                                               • Owners
                                                                              Customers
Design Consideration: Users & Needs
  (as in ―know thy user‖ and what they need)
 • Who are the users?
    –   E.g., physical:
          •   size of hands may affect the size and positioning of input buttons
          •   motor abilities may affect the suitability of certain input and output devices
          •   height if designing a physical kiosk
          •   strength - a child‘s toy requires little strength to operate, but greater strength to change batteries
          •   disabilities(e.g. sight, hearing, dexterity)


 • What are „needs‟?
    –   Users rarely know what is possible
    –   Users can‘t tell you what they ‗need‘ to help them achieve their goals
    –   Instead, look at existing tasks:
          •   their context
          •   what information do they require?
          •   who collaborates to achieve the task?
          •   why is the task achieved the way it is?
    –   Envisioned tasks:
          • can be rooted in existing behaviour
          • can be described as future scenarios
Where do alternatives come from?
• “Humans stick to what they know works”
   – Past designs, best practice, …
   – But recall, ―if all you have is a hammer, everything looks like a nail‖

• Considering alternatives is important to „break out of the
  box‟

• To oversimplify:
   – Designers are specifically trained to consider alternatives
   – Software people generally are not
   – Like, divergent and convergent

• How do you generate alternatives?
   — ‗Flair and creativity‘
        — research and synthesis
   — Seek inspiration (next slide):
        — look at similar products or look at very different products
IDEO TechBox – Fostering Design
                                    (supplementary)
     •   Library, database, website - gizmos for inspiration




From: www.ideo.com/
How to choose among Design alternatives?
                           (supplementary)


 • Evaluation with users or with peers, e.g. prototypes

 • Technical feasibility: some not possible

 • Quality thresholds: Usability goals lead to usability
   criteria set early on and check regularly
        —safety: how safe?
        —utility: which functions are superfluous?
        —effectiveness: appropriate support? task coverage,
         information available
        —efficiency: performance measurements
Testing prototypes to choose
 among alternatives (supplementary)
       Software Lifecycle Models
• Real quickly …

• Briefly relate design to software engineering ideas
   – Familiar to most

• Show how activities are related to each other

• Lifecycle models are:
    — management tools
    — simplified versions of reality


• Many lifecycle models exist, for example:
    — from software engineering:
        — waterfall, spiral, JAD/RAD, Microsoft
    — from HCI:
        — Star, usability engineering
A Simple Interaction Design Model

                         Identify needs/
                            establish
                          requirements




          (Re)Design
                                               Evaluate


                              Build an
                              interactive
                              version


•Note (Re)Design, cf Carroll and Rosson                   Final product


•Exemplifies a user-centered design approach
Software Engineering: ‗Waterfall‘ Lifecycle

      Requirements
      analysis



                     Design




                              Code



                                     Test




                                            Maintenance
Software Engineering: Lifecycle, RAD
 (Rapid Applications Development)
     Project set-up



                 JAD workshops



                                 Iterative design
                                 and build


                                               Engineer and
                                               test final prototype


                                                                 Implementation
                                                                 review
                 Shneiderman‘s
             ―Three Pillars of Design‖




• Structuring projects in this way leads to efficiencies

• Means to go from ideas to systems:
         •   Guidelines documents and processes
         •   User interface software tools
         •   Expert reviews and usability testing


• First, guidelines documents and processes
   –   Each project has different needs, but guidelines should be considered for:
   –   Way to create shared language and common techniques
   –   Etc., as on next slide
Guidelines Documents and Processes
 •   Words, icons, and graphics
      –   Terminology (objects and actions), abbreviations, and capitalization
      –   Character set, fonts, font sizes, and styles (bold, italic, underline)
      –   Icons, graphics, line thickness, and
      –   Use of color, backgrounds, highlighting, and blinking
 •   Screen-layout issues
      –   Menu selection, form fill-in, and dialog-box formats
      –   Wording of prompts, feedback, and error messages
      –   Justification, white space, and margins
      –   Data entry and display formats for items and lists
      –   Use and contents of headers and footers
 •   Input and output devices
      –   Keyboard, display, cursor control, and pointing devices
      –   Audible sounds, voice feedback, touch input, and other special devices
      –   Response time for a variety of tasks
 •   Action sequences
      –   Direct-manipulation clicking, dragging, dropping, and gestures
      –   Command syntax, semantics, and sequences
      –   Programmed function keys
      –   Error handling and recovery procedures
 •   Training
      –   Online help and tutorials
      –   Training and reference materials
      –   Command syntax, semantics, and sequences
Guidelines Documents and Processes
                                     (supplementary)


 • Guidelines for                     •   Words, icons, and graphics
    –   Words, icons, and graphics         –   Terminology (objects and actions), abbreviations, and
                                               capitalization
    –   Screen-layout issues               –   Character set, fonts, font sizes, and styles (bold, italic,
    –   Input and output devices               underline)
    –   Action sequences                   –   Icons, graphics, line thickness, and
    –   Training                           –   Use of color, backgrounds, highlighting, and blinking
                                      •   Screen-layout issues
                                           –   Menu selection, form fill-in, and dialog-box formats
                                           –   Wording of prompts, feedback, and error messages
                                           –   Justification, white space, and margins
                                           –   Data entry and display formats for items and lists
                                           –   Use and contents of headers and footers
                                      •   Input and output devices
                                           –   Keyboard, display, cursor control, and pointing devices
                                           –   Audible sounds, voice feedback, touch input, and other
                                               special devices
                                           –   Response time for a variety of tasks
                                      •   Action sequences
                                           –   Direct-manipulation clicking, dragging, dropping, and gestures
                                           –   Command syntax, semantics, and sequences
                                           –   Programmed function keys
                                           –   Error handling and recovery procedures
                                      •   Training
                                           –   Online help and tutorials
                                           –   Training and reference materials
                                           –   Command syntax, semantics, and sequences
Guidelines Documents and Processes
 •   To summarize utility of guidelines, again:




 •   ―Four E‘s‖ ….of guideline creation and
     utilization

      –   Education
           •   User‘s of guidelines need training and
               chance to discuss guidelines
      –   Enforcement
           •   Timely and clear process necessary to verify
               that an interface adheres to guidelines
      –   Exemption
           •   When creative ideas or new technologies
               are used, rapid process for gaining
               exemption is needed
      –   Enhancement
           •   Predictable process for review to keep
               guidelines up to date
UI Tools and Reviews and Testing




• UI tools
   – As we‘ll see in programming, tools are available …
   – Recall, windowing system essentially enforces guidelines and standards

• Expert reviews and usability testing
   – Again, part of design process

• Next chapters
  Developmental Methodologies
• Not a pleasant fact, but software projects fail
   – Often due to poor communication between developers and 1) clients or 2) users

• UI development intertwined with general software development
  methodologies
   – But, recall role of iteration in interface design
   – I.e., user testing (perhaps only relatively late) may suggest/require
     ―transformational‖ redisign
        • Which is not what managers, and others concerned with budgets/costs, like to hear


• Dozens of development methodology

• Will briefly look at two representative project management
  plans
   – IBM‘s ―Ease of Use Methodology‖
   – The Logical User-Centered Interactive Design Methodology (LUCID)
   IBM‘s Ease of Use Methodology:
               Business oriented, Deliverables

• Imagine a really big organization … with lots of departments …
         Developmental Methodologies
           LUCID: Stages (supplementary)
•        The Logical User-Centered Interactive Design Methodology
     –     (Kreitzberg, 1996)

Stage 1: Envision
     –     Align agendas of all stakeholders with organizational strategy and the need for ―extreme usability‖
     –     Develop a clear, shared product vision embodied in a concept sketch

Stage 2: Discovery
     •     Study users to determine high-level requirements, terminology and mental models

Stage 3: Design Foundation
     •     Develop a conceptual design and create a key screen prototype to convey the visual style
     •     Usability test the design, revise, and repeat

Stage 4: Design Detail
     •     Flesh out the high-level design into complete specifications

Stage 5: Build
     •     Support the production process through review and late-stage change management

Stage 6: Release
     •     Develop a roll-out plan to support the users‘ transition to the new product
     •     Conduct a final usability test
     •     Document the lessons learned
     Developmental Methodologies
     LUCID Components (supplementary)
The Twelve Components of the LUCID
     Management Strategy

1.     Product Definition                         7.     Functionality
                                                        Service provided to users
      High Concept for managers and marketers

2.     Business Case                              8.     Prototype
      Pricing, expected revenue, ...                    Early paper prototypes, key screens,
                                                               running prototypes

–      Resources                                  9.     Usability
      Duration effort, team members, …                  Set measurable goals, conduct tests

–      Physical Environment
                                                  10.    Design Guidelines
      Ergonomic design, communcations, …
                                                        Modify existing guidelines, implement
                                                              review process
–      Technical Environment
      Hardware and software for development
           and deployment                         11.    Content Materials
                                                        Identify and acquire copyrighted text, audio
–      Users
      Multiple communities for interviewing and   12.    Documentation, Training, and Help
             testing                                    Specify develop and test, paper video and
                                                              online versions
       User Observation in Design:
    Ethnographic Observation of Users
• Ethnography:
      – Branch of anthropology that deals with scientific description of specific human
        cultures
      – The study and systematic recording of human cultures

•    Preparation
      –   Understand organization policies and work culture.
      –   Familiarize yourself with the system and its history.
      –   Set initial goals and prepare questions.
      –   Gain access and permission to observe/interview.

•    Field Study
      –   Establish rapport with managers and users.
      –   Observe/interview users in their workplace and collect subjective/objective quantitative/qualitative data.
      –   Follow any leads that emerge from the visits.

•    Analysis
      –   Compile the collected data in numerical, textual, and multimedia databases.
      –   Quantify data and compile statistics.
      –   Reduce and interpret the data.
      –   Refine the goals and the process used.

•    Reporting
      –   Consider multiple audiences and goals.
      –   Prepare a report and present the findings.
 Observing Users: The aims
                      (supplementary)


 Benefits & challenges of different types of observation

 How to observe as an on-looker, a participant, & an
  ethnographer

 How to collect, analyze & present observational data

 Examine think-aloud, diary studies & logging
        Observing Users:
What and When to Observe (supplementary)
• Goals & questions determine the paradigms and techniques used

• Observation is valuable any time during design

• Quick & dirty observations early in design

• Observation can be done in the field (i.e., field studies) and in controlled
  environments (i.e., usability studies)

• Observers can be:
  - outsiders looking on
  - participants, i.e., participant observers
  - ethnographers
      Observing Users:
Frameworks to Guide Observation
                          (supplementary)
• - The person. Who?
  - The place. Where?
  - The thing. What?

• Goetz and LeCompte (1984)        • Robinson (1993) framework
   –   Who is present?                – Space. What is physical space like?
   –   What is their role?            – Actors. Who is involved?
   –   What is happening?             – Activities. What are they doing?
   –   When does activity occur?      – Objects. What objects are present?
   –   Where is it happening?
                                      – Acts. What are individuals doing?
   –   Why is it happening?
                                      – Events. What kind of event is it?
   –   How is the activity
       organized?                     – Goals. What do they to
                                        accomplish?
                                      – Feelings. What is the mood of the
                                        group and of individuals?
Observing Users: Need to Consider
                                (supplementary)

  •   Goals & questions

  •   Which framework & techniques

  •   How to collect data

  •   Which equipment to use

  •   How to gain acceptance

  •   How to handle sensitive issues

  •   Whether and how to involve informants

  •   How to analyze the data
           Observing Users:
        Observing as an Outsider
                            (supplementary)

• As in usability testing

• More objective than participant observation

• In usability lab equipment is in place

• Recording is continuous

• Analysis & observation almost simultaneous

• Care needed to avoid drowning in data

• Analysis can be coarse or fine grained

• Video clips can be powerful for telling story
           Observing Users:
Participant observation & ethnography
                              (supplementary)

 • Debate about differences

 • Participant observation is key component of ethnography

 • Must get co-operation of people observed

 • Informants are useful

 • Data analysis is continuous

 • Interpretivist technique

 • Questions get refined as understanding grows

 • Reports usually contain examples
          Observing Users:
      Data Collection & Analysis
                         (supplementary)
 Data Collection Techniques
   – Notes & still camera
   – Audio & still camera
   – Video

• Data Analysis
   – Tracking users:
     - diaries
     - interaction logging Qualitative data - interpreted & used to tell
     the ‗story‘ about what was observed.

    Qualitative data - categorized using techniques such as content
     analysis.

    Quantitative data - collected from interaction & video logs.
     Presented as values, tables, charts, graphs and treated
     statistically.
    Observing Users: Data analysis
                                      (supplementary)

   Look for key events that drive the group‘s activity

   Look for patterns of behavior

   Test data sources against each other - triangulate

   Report findings in a convincing and honest way

   Produce ‗rich‘ or ‗thick descriptions‘

   Include quotes, pictures, and anecdotes

   Software tools can be useful e.g., NUDIST, Ethnograph (see URL resource list for
    examples)

   Observing Users: Looking for patterns
     –   Critical incident analysis
     –   Content analysis
     –   Discourse analysis
     –   Quantitative analysis - i.e., statistics
Observing Users: Summary Points
 Observe from outside or as a participant

 Analyzing video and data logs can be time-consuming

 In participant observation collections of comments,
  incidents, and artifacts are made.
    Ethnography is a philosophy with a set of techniques that
     include participant observation and interviews


 Ethnographers immerse themselves in the culture that
  they study.
            Participatory Design, 1
Controversial – cases for and against

•       More user involvement brings:

    –     more accurate information about tasks
    –     more opportunity for users to influence
          design decisions
    –     a sense of participation that builds users'
          ego investment in successful
          implementation
    –     potential for increased user acceptance of
          final system
             Participatory Design, 2

•       Negative side, extensive user
        involvement may

    –      be more costly
    –      lengthen the implementation period
    –      build antagonism with people not involved or
           whose suggestions rejected
    –      force designers to compromise their design to
           satisfy incompetent participants
    –      build opposition to implementation
    –      exacerbate personality conflicts between design-
           team members and users
    –      show that organizational politics and preferences
           of certain individuals are more important than
           technical issues
Design by Scenario Development
Day-in-the-life scenarios:

•       Characterize what happens when users perform typical tasks
•
•       Can be acted out as a form of walkthrough

•       May be used as basis for videotape

•       Useful tools
    –      table of user communities across top, tasks listed down the side
    –      table of task sequences
    –      flowchart or transition diagram
    Social Impact Statement for Early
             Design Review
                                                   (supplementary)
•   New systems can (and do) have large impact on individuals and organizations
•   Seek to facilitate change:

•   Describe the new system and its benefits
     –   Convey the high level goals of the new system.
     –   Identify the stakeholders.
     –   Identify specific benefits


•   Address concerns and potential barriers
     –   Anticipate changes in job functions and potential layoffs.
     –   Address security and privacy issues.
     –   Discuss accountability and responsibility for system misuse and failure.
     –   Avoid potential biases.
     –   Weigh individual rights vs. societal benefits.
     –   Assess trade-offs between centralization and decentralization.
     –   Preserve democratic principles.
     –   Ensure diverse access.
     –   promote simplicity and preserve what works.

•   Outline the development process
     –   Present and estimated project schedule.
     –   Propose process for making decisions.
     –   Discuss expectations of how stakeholders will be involved.
     –   Recognize needs for more staff, training, and hardware.
     –   Propose plan for backups of data and equipment.
     –   Outline plan for migrating to the new system.
          Legal Issues of Design
•   Potential Controversies
    –   What material is eligible for copyright?
    –   Are copyrights or patents more appropriate for user interfaces?
    –   What constitutes copyright infringement?
    –   Should user interfaces be copyrighted?
      End
• .

								
To top