Docstoc

lecture 6

Document Sample
lecture 6 Powered By Docstoc
					IEOR 170: Task Analysis and
Contextual Inquiry
  Jingtao Wang
  2/05/2007




                 Slides based on those of John Canny, Maneesh Agrawala and Marti Hearst
Administrivia

    Guest Lecture this Wednesday
        Reflective Physical Prototyping




    Attendance to classes on next Monday and
     Wednesday is required
        Need finding and Fast prototyping
        Include both individual assignment and in-class
         practicing
Administrivia

    HW2 – Individual Project Proposal released
     today
        Due next Wednesday before class
        Persuasive Design for Campus, City and Community
        Please drop by Jingtao’s office hours if you have
         clarification questions



    Voluntary and anonymous in-class survey
Previously on IEOR 170

    The Action Cycle



    Metaphor



    Common Design Wisdoms
Topics

  Task Analysis
  Contextual Inquiry
  Personas
 Task   Analysis
• BART Ticket Machine
  – Buy or add fare
  – ATM, Credit or Cash
• BART Ticket Machine
   – Buy or add fare
   – ATM, Credit or Cash
Problems
   One “path” of operation
       Ticket type -> payment type -> payment -> ticket




   Order of payment / card insertion non-standard

   Large dismiss transaction button does nothing

   BART Plus has minimum of $28, no indication of this
    until after inserting >= $1
       Can’t switch to regular BART ticket
How To Improve Design
    Understand users’ tasks

    Designers must think about
        Who are the users?
        What tasks they would want to carry out?
        …

  Observe existing practices
  Create scenarios of actual usage
  Try out ideas before building final products
Task Analysis Questions
 1.  Who is going to use system?
 2.  What tasks do they now perform?
 3.  What tasks are desired?
 4.  How are the tasks learned?
 5.  Where are the tasks performed?
 6.  What’s the relationship between user & data?
 7.  What other tools does the customer have?
 8.  How do customers communicate with each other?
 9.  How often are the tasks performed?
 10. What are the time constraints on the tasks?
 11. What happens when things go wrong?
Task Analysis Questions
 1.  Who is going to use system?
 2.  What tasks do they now perform?
 3.  What tasks are desired?
 4.  How are the tasks learned?
 5.  Where are the tasks performed?
 6.  What’s the relationship between user & data?
 7.  What other tools does the customer have?
 8.  How do customers communicate with each other?
 9.  How often are the tasks performed?
 10. What are the time constraints on the tasks?
 11. What happens when things go wrong?
Who ?
  Identity?
     need several typical customers for broad product
  Background/Skills
        Knowledge users already have and rely on to perform task
  Values, Likes/Dislikes
  Personal characteristics:
     Education
     Literacy
     Physical abilities/disabilities
             Some physical traits may be relevant: height, weight, …
        Age
Who (BART)?

    Identity
       People who ride BART
             Business people, students, disabled, elderly, etc.


    Background/Skills
        Have an ATM or credit card
        Know how to use ATM
Who (BART)?

    Values, Likes/Dislikes
        (i.e. May not like driving)
Who (BART)?

    Values, Likes/Dislikes
        May not like driving
        Want minimum fuss
        Sometimes in a hurry
        Maybe frugal (like saving money)
        Maybe environmentalists
        Hate having money eaten
        Want to feel safe and maintain privacy
        Hate feeling stupid
Who (BART)?

    Personal characteristics
        Education, Physical abilities, Age, etc
Who (BART)?
   Personal characteristics
       Mostly educated, fluent in English
       Varying heights -> don’t make it too high or too low!
       Mixture of ages, a few disabled users (e.g. wheelchairs).
       Some bike users (make interface one-handed?)
Talk to Them
    Find some real users


    Talk to them
       Find out what they do
       How would your system fit in




    Are they too busy?
       Buy their time
            T-shirts, coffee mugs, etc.
Task Analysis Questions
 1.  Who is going to use system?
 2.  What tasks do they now perform?
 3.  What tasks are desired?
 4.  How are the tasks learned?
 5.  Where are the tasks performed?
 6.  What’s the relationship between user & data?
 7.  What other tools does the customer have?
 8.  How do customers communicate with each other?
 9.  How often are the tasks performed?
 10. What are the time constraints on the tasks?
 11. What happens when things go wrong?
Old and New Tasks

    Old
        The way people do things now
    New
        The way you anticipate them doing things in future
    Observe!
        Pick the most important tasks
        Remember you’re guessing about future tasks
        Return to this when you test your prototypes
On-Line Billing Example
    Dental office had billing automated

    Assistants unhappy with new system

    Old forms had hand-written notes
         E.g. patient A’s insurance takes longer
          than most, etc
What Tasks (BART) ?
    Old
        Cash to buy new ticket
        Cash to add fare to existing ticket
        Cash or credit to buy a BART Plus a window

    New
        Cash, credit, or ATM card to
              Buy new ticket
              Add fare to existing ticket
              Buy a BART Plus ticket


    Task level of detail can vary based on goals of analysis
Task Analysis Questions
 1.  Who is going to use system?
 2.  What tasks do they now perform?
 3.  What tasks are desired?
 4.  How are the tasks learned?
 5.  Where are the tasks performed?
 6.  What’s the relationship between user & data?
 7.  What other tools does the customer have?
 8.  How do customers communicate with each other?
 9.  How often are the tasks performed?
 10. What are the time constraints on the tasks?
 11. What happens when things go wrong?
How are Tasks Learned?
   What does the customer need to know?

   Do they need training?
      Book/manual information
      General knowledge / skills
      Special instruction / training



   Be careful about level of education and literacy
      8th grade is often reasonable in broad design
       contexts
How are Tasks Learned (BART)?
    Walk up & use system
      Can’t assume much background/training


    Training?
       Too time consuming


    Must be simple & similar to existing systems
        BART machines
        ATM machines
Where is the Task Performed?
    Office, laboratory, point of sale, home?

    Effects of environment on customers?
        Lighting, sound, comfort, interruptions, water


    Social influence of environment
        Rituals, sacred places


    Effects of other people (bystanders)?
        Rushing, safety, privacy


    Users under stress?
Where (BART)? Train Station
Where (BART)? Train Station
    Loud
        Voice I/O not a good idea
    Privacy
        Others may look over shoulder
        PIN input must be confidential
             Don’t confirm with sound
    Lighting is dim
        Make sure messages are readable
    Rituals:
        Panhandlers, musicians, reading
         the paper, cell phones
Task Analysis Questions
 1.  Who is going to use system?
 2.  What tasks do they now perform?
 3.  What tasks are desired?
 4.  How are the tasks learned?
 5.  Where are the tasks performed?
 6.  What’s the relationship between user & data?
 7.  What other tools does the customer have?
 8.  How do customers communicate with each other?
 9.  How often are the tasks performed?
 10. What are the time constraints on the tasks?
 11. What happens when things go wrong?
Data Relationships?
    Personal data
        Privacy
             Always accessed at same machine?
             Do customers move between machines?
    Common data
       Handling and processing
             Used concurrently?
             Passed sequentially between customers?
  Remote access required?
  Access to data restricted?
Data Relationships (BART)
    Personal data
        Users may use any machine
        Store info on BART card

    Common data
        Fare rules (e.g., how much for BART Plus)
        Used concurrently

    Access to data restricted?
        Only you can use your ATM or credit card

    No need for remote access
Other Tools

    Users work with collection of tools
        Cell phone
        Home PC
        PDA
        Timetable booklet
        Maps

    Can we use other tools to facilitate interaction?
Other Tools (BART)

  Credit card, ATM card (today)
  E-wallet in cell phone or organizer (someday)
  Real-time train info on the web
  User has PC at home
        Could provide auditing for them?
    Text on phone, use for BART delay alerts?
Task Analysis Questions
 1.  Who is going to use system?
 2.  What tasks do they now perform?
 3.  What tasks are desired?
 4.  How are the tasks learned?
 5.  Where are the tasks performed?
 6.  What’s the relationship between user & data?
 7.  What other tools does the customer have?
 8.  How do customers communicate with each other?
 9.  How often are the tasks performed?
 10. What are the time constraints on the tasks?
 11. What happens when things go wrong?
How do Customers Communicate With Each Other?

    Who communicates with whom?
    About what ?


      Follow lines of the organization? Against it?
          Example: assistant to manager
             Installation of computers changes communication between
              them
             People would rather change their computer usage than their
              relationship


      Not so relevant in context of BART
Frequency of Task Performance
   Frequent customers remember more details

   Infrequent customers may need more help
      But don’t make it tedious


   Which function is performed
     Most frequently?
     By which customers?
     Optimize system for these tasks will improve
      perception of good performance
Frequency (BART)?
    Varying frequency of customers
        Some take BART every day (most)
        Some take it only occasionally
    Varying frequency of tasks
        Can only do BART Plus every 2 weeks
        Might do add fare or buy new ticket every day
        Novices: Just one set of detailed instructions
        Experienced Users: Provide overview of process
    How to find out for sure?
        Observe and interview your users!
Task Analysis Questions
 1.  Who is going to use system?
 2.  What tasks do they now perform?
 3.  What tasks are desired?
 4.  How are the tasks learned?
 5.  Where are the tasks performed?
 6.  What’s the relationship between user & data?
 7.  What other tools does the customer have?
 8.  How do customers communicate with each other?
 9.  How often are the tasks performed?
 10. What are the time constraints on the tasks?
 11. What happens when things go wrong?
Time Constraints

    What functions will customers be in a hurry for?



    Which can wait?



    Is there a timing relationship between tasks?
Time Constraints (BART)?

    Customers will almost always be in a hurry

    Lines form

    Take less than 1 minute/transaction

    Be able to do any task in any order
When Things Go Wrong?

    How do people deal with
      task-related errors?

      practical difficulties?

      catastrophes?



    Is there a backup strategy?
Things Go Wrong (BART)?
    Confusion on task
        “Dismiss transaction” button (that works!)
    Practical difficulty
        Generated ticket with too much money
        Cash-in policy?
    Catastrophe
        Machine eats card -> swipe instead of insert
    Backup strategy
        Use cash in regular machines (and provide ATM)
Selecting Tasks

  Real tasks customers have faced
    Collect any necessary materials

  Should provide reasonable coverage
    Compare check list of functions to tasks

  Mixture of simple & complex tasks
    Easy task (common or introductory)

    Moderate task

    Difficult task (infrequent or for power users)
Current State of Affairs
Current State of Affairs
A Better Subway Machine: Hong Kong
Selecting Tasks

    Real tasks users have faced
        Collect any necessary materials


    Should provide reasonable coverage
        Compare check list of functions to tasks

    Mixture of simple & complex tasks
        Easy task (common or introductory)
        Moderate task
        Difficult task (infrequent or for power users)
What Should Tasks Look Like?
    Say what user wants to do, not how user would do it
        Allows comparing different design alternatives

    Should be very specific
        Forces us to fill out description w/ relevant details
             Example: file browser story
        Say who the users are (use personas or profiles)
             Design can really differ depending on who
             Name names (allows getting more info as necessary)
             Characteristics of the users (job, expertise, etc)


    Some should describe a complete job
        Forces us to consider how features work together
Using Tasks in Design

    Write up a description of tasks
        Formally or informally
        Run by users and rest of the design team
        Get more information where needed


     Manny is in the city at a club and would like to call his girlfriend,
     Sherry, to see when she will be arriving at the club. She called
     from a friends house while he was on BART, so he couldn’t
     answer the phone. He would like to check his missed calls and
     find the numbers so that he can call her back.
Using Tasks in Design
    Write up a description of tasks
        Formally or informally
        Run by users and rest of the design team
        Get more information where needed
    Rough out an interface design
        Discard features that don’t support your tasks
             Or add a real task that exercises that feature
        Major screens & functions (not too detailed)
        Hand sketched
    Produce scenarios for each task
        What user has to do & what they would see
        Step-by-step performance of task
Scenarios
    Scenarios explain how, tasks explain what

    Scenarios force us to
        Show how features will work together
        Settle design arguments by seeing examples
        Only examples -> sometimes need to look
         beyond


    Show users storyboards
        Sequences of sketches showing screens
        Actions users can take
   Contextual Inquiry
Goals

  Get inside the user’s head
  See their tasks they way they do
  Neither pure observation nor pure interview
Master-Apprentice model

    Allows customer to teach us what they do
        Master (user) works & talks
        We interrupt to ask questions as they go
        Each step reminds the user of the next
             Better than asking user to summarize work habits
Master-Apprentice Model

    Allows customer to teach us what they do
        Skill knowledge is usually tacit (cant put it in books)
        Sometimes literal apprenticeship is best
Master-Apprentice Model

    Allows customer to teach us what they do
        Skill knowledge is usually tacit (cant put it in books)
        Sometimes literal apprenticeship is best




         Matsushita Home Bakery – First automatic bread maker to have
         Twist/stretch motion [Nonaka 95]
Principles: Context
  Conduct inquiry in a normal work environment
  People summarize, but we want details
  Keep it concrete when people start to abstract
        “We usually get reports by email”, ask “Can I see one?”
    Look for skipped steps, ask user to fill them in.
Show and Tell

    Encourage story-telling
Principles: Partnership
    Stick with master-apprentice; avoid other models, i.e.
        Avoid interviewer/interviewee
        Above all, don’t “teach”!
    Partnership allows more apprentice interaction:
        OK to be a designer and interrupt!
        … but go back “in role”
    Alternate between watching & probing (withdrawal & return)
Principles: Interpretation
    Good facts are only the starting point
        Designs based on interpretations
    Validate & rephrase
        Check interpretations with user
             Users uncomfortable until the phrasing is right – theirs is right by
              definition
        Be committed to hearing what the user is really saying
Principles: Focus
    You need data about specific tasks
        Steer conversation to stay on useful topics
    Respect triggers (flags to change focus –
     changing understanding)
        Shift of attention (some one walks in)
        Treat every user utterance as a potential clue to
         something important
Users: Unique or One of Many?
    “.. nothing any person does is done for no reason; if
     you think it’s for no reason, you don’t yet understand
     the point of view from which it makes sense.”



    “Take the attitude that nothing any person does is
     unique to them, it always represents an important
     class of customers whose needs will not be met if you
     don’t figure out what’s going on.”
Structure of Contextual Inquiry

     Conventional interview (15 minutes)
         Introduce focus & deal with ethical issues
         Get used to each other by collecting standard user profile
          information

     Transition (30 seconds)
         State new rules – they work while you watch & interrupt

     Contextual interview (1-2 hours)
         Take notes, draw, be nosy! (“who was on the phone?”)

     Wrap-up (15 minutes)
         Summarize your notes & confirm what is important
Thoughts on Contextual Inquiries

    Use recording technologies
        Notebooks, tape recorders, still & video cameras

    Master/apprentice can be hard
        Staying in role – it’s a lot like acting
        Don’t correct! Its not a lesson!
        Its hard not designing on the fly
        Sometimes you need to put down your product
What Users Might Say

  “This system is too difficult”
  “You don’t have the steps in the order we do
   them”
  Do not take comments personally
     You shouldn’t have a personal stake

  Goal is to make the system easy to use for
   your intended users
Caveats of UCD Techniques

    Users are not always right
      Cannot anticipate new technology accurately
      Your job is to build system users will want
         Not system users say they want
         Be very careful about this (you are outsider)
               If you can’t get users interested in your hot idea, you’re
                probably missing something
Caveats of UCD Techniques

     Politics
         “Agents of change” can cause controversy
         Get a sense of the organization & bond w/
          interviewee
         Important to get buy-in from all those involved


     Design forever without prototyping
         Rapid prototyping, evaluation, & iteration is key
   Personas
Personas (from Cooper)

    “Hypothetical Archetypes”
        Archetype: (American Heritage)
           An original model or type after which other
            similar things are patterned; a prototype
           An ideal example of a type; quintessence




    A precise description of user in terms
      Capabilities, inclinations, background
      Goals (not tasks)


      * Persona literally means "mask ", although it does not usually refer to
      a literal mask but to the "social masks" all humans supposedly wear.
Why Personas ?
    Easier to generalize about specific fictional people
        We can easily discuss what Harry Potter or Scarlett O’Hara
         will think or do
    General users have too many conflicting goals




    Specific personas have clear well articulated goals
Why Personas ?
     A compromise design pleases no-one
          The broader you aim, the more likely you miss the bulls-eye
          50% of the people 50% happy doesn’t work
               Car example – soccer mom, carpenter, dot-com exec
         “Every time you extend functionality to include another
          constituency, you put another speed bump of features and
          controls across every other user’s road.”
     A targeted design can achieve
          10% people 100% ecstatic
          Examples:
               Ram pickup truck
               Sony aibo
     There is no such thing as an average user
        Makes it difficult for designers to distort the users’ goals and
         needs
Why Personas ?

    Avoid the “elastic user”
        Designers bend, stretch and adapt the products
         for the user, not user bending and adapting to
         products
        Makes it difficult for designers to distort the users’
         goals and needs

    Helps prevent designer / programmer from
     imagining they are the user
Defining and Using Personas
    Defining them
        Identify major clusters from multiple user interviews/inquiries
        Synthesize their goals
        Check for completeness and specificity
             Specificity prevents “elastic user”
        Try them out by developing narrative



    Design each interface for a single primary persona
        “Someone who must be satisfied, but who cannot be satisfied
         with an product designed for any other persona.”
Persona Targeted Designs
    Dodge Ram Pickup


    Roller suitcases


    SONY Aibo
        Isn’t useful for anything
        Not fuzzy and warm
        Too delicate to let children use it, but
             Passionate fan clubs
             Brisk sales despite steep price – and prices
              now coming down
What Goes Into a Good Persona?
    Skill levels
    Capabilities, inclinations and background (or lack of)
    Other pertinent economic, social, values, etc.
     characteristics
    Precision to extent that persona can stand for
     member of development team
    Goals (most important)
Persona Example             (from Marti Hearst)



    Problem Statement

        Design a new shared calendar system for
         UC Berkeley
     – Persona #1 - Megan Richardson
     –   Technology level: Med-low
     –   Interest in sharing events: Medium
     –   Unique situation: Currently has no calendar, would like to send events to other
         calendars and receive events from other calendars
•   Megan Richardson is the 22-year-old UC student and member of CalPirg, the California
    branch of a student organization whose mission is “to deliver persistent, result-oriented
    public interest activism that encourages a fair, sustainable economy, and fosters responsive,
    democratic government.” She is from Boston and has been maintaining the CalPirg
    website in her spare time. Megan created her first website as a high-school senior using
    Dreamweaver. She understands basic HTML, but is not very familiar with data-driven
    websites or cascading style sheets. As she has not yet worked in the business world, she
    has also never used a personal calendaring system such as Outlook.
•   CalPirg sponsors 8-10 campus events each semester, such as rallies against hunger and
    homelessness or for clean and affordable power. The organization attempts to publicize
    these events to its members and the general public by posting them on their website and
    sending emails out to their mailing list in order to increase attendance and catch the
    attention of legislators. However, because Megan is very busy with schoolwork and activism
    during her senior year and not many of the other CalPirg members have website design
    expertise, they have not had time to redesign their website in order to present their events in
    a coherent, easy to use, calendar-oriented format. Megan would love to have a tool that
    would automate the creation of a functional, well-designed calendar for the CalPirg
    website. CalPirg might also be interested in publicizing other campus and community
    events that support their mission in their calendar, as well as publicize their events in
    other calendars to increase attendance at their events. Megan would not want to spend
    more than an hour setting such a system up, and could spend only about a half hour per
    week maintaining information on CalPirg events. CalPirg has about 4-5 major events a
    semester, and 2-3 events that occur on a weekly basis. If a nicely formatted calendar could
    even increase attendance at their events by 10%, it would be well worth her time.
•   Megan’s Goals:
     –   Create a simple calendar or list of events as well as send out emails on events that her
         organization sponsors on their website in order to encourage the participation of members and the
         public in these events without having to hire a programmer
     –   To ensure that their website supports the organization’s mission, which is to deliver persistent,
         result-oriented public interest activism that encourages a fair, sustainable economy, and fosters
         responsive, democratic government
     –   To spend most of her time on schoolwork and activism, and less time on the technical details of
         managing a website
     – Persona #2 - Harold Jackson
     –   Technology level: Med-high
     –   Interest in sharing events: High
     –   Unique situation: Campus Event Aggregator, they don’t “own” any events

•   Harold Jackson is a 40-year-old Program Manager in the Public Relations office of the
    UC. He is a Los Angeles native who enjoys walking his dog and playing tennis with his wife,
    who is a programmer. He is responsible for overseeing the maintenance of the UC
    website and Calendar of Events. It is essential that the website project a professional
    image, as it is an important means of advertising the university to the general public, alumni
    and potential donors. Harold’s background is primarily in public relations, but he has also
    acquired technical skills along the way, and is the primary maintainer of the UC website.
    Although he is familiar with the concept of building a data-driven website, the back-end of
    the university website was built by an outside contractor, and most of the staff in Harold’s
    department are not as technically savvy as he is. Harold and most of his group are familiar
    with calendaring systems such as Outlook or ICal, and use the CalAgenda calendaring
    system to schedule meetings.
•   Harold’s ultimate goal in relation to the campus calendar is to publicize as many events
    occurring on the UC campus as possible, and to highlight especially important events
    on the website. Currently events are submitted to the university calendar via a web form,
    and not many departments currently enter their events in this fashion. As a result, Harold’s
    staff has to spend time contacting various departments to find interesting events to post to
    their calendar. Harold thinks that if he could somehow find a way make it easier for
    campus departments and organizations to send him events, he could greatly increase
    the number of events he would receive and be able to publicize. In evaluating a new
    system, however, he would want to ensure that it is at a minimum an improvement over the
    current system in terms of functionality, and offers a design that integrates with the
    overall UC website.
•   Harold's Goals:
     –   Create a web-based calendar that will be the ultimate aggregator of all events at his university,
         which will be used by the public as well as people at the university
     –   “Market” the university to potential contributors and the general public by highlighting the diverse
         and exciting events that occur there
     –   Ensure that the calendar looks professional and eye-catching, and integrates with the overall
         “look and feel” of the university website
     –   Make the process for entering and approving events as easy as possible so that even “low-tech”
         users in his department can do this
     –   Encourage other calendar owners to send him events
     – Persona #3 - Sally McNeil
     –   Interest in sharing events: High
     –   Technology level: High
     –   Unique situation: Model must handle parent-child event relationships & allow the
         use of cascading style sheets

•   Sally McNeil is the 35-year-old webmaster for the university’s science
    museum. She is from Michigan, loves to travel, and often takes exotic vacations
    with her husband and two children during school breaks. Her manager has
    tasked her with revamping the organization’s website in order to draw more
    visitors to the museum. As families and schools usually only visit the museum
    once a year or so, they would like to encourage new people who may be
    traveling from farther distances to visit. She feels that giving visitors to her
    website information on related events and activities occurring on campus
    might be a good way to bolster attendance. Sally has extensive web
    programming experience, and her website is currently dynamically generated.
    She works with a java programmer on the website, and both of them are familiar
    with XML. She and her programmer have thought a lot about the best way to
    format a calendar-oriented website, and have even prototyped their best ideas.
    She wants to find an easy way to include events from other departments,
    without having to cut and paste them into her calendar. She also would like
    to be able to maintain the appearance of her website using cascading style
    sheets.
•   Sally's Goals:
     –   Use the website to increase attendance at the museum
     –   Create an eye-catching, dynamically-generated calendar that will allow parents and
         teachers to easily plan trips to their museum
     –   Include events occurring at the university that may be of interest to their patrons,
         so families and groups traveling great distances to reach the museum can “make a day
         of it” and attend other events during their time in town
     –   Clearly list events that have a “parent-child” relationship on the website so that it
         is easy for visitors to find what they are looking for (e.g. “Forces that Shape the Bay”
         event during which many different daily presentations occur)
     –   Use cascading style sheets to maintain website look and feel
     –   Persona #4 - Nina Sanchez
     –   Technology level: Low
     –   Interest in sharing events: Low
     –   Unique situation: Political constraints on event listings & need to send
         email when new events are added
•   Nina Sanchez is a 27-year-old Program Coordinator of the Center for Middle Eastern Studies.
    She is single and has a very active social life. She lives in the Mission in San Francisco where she
    often attends art openings, musical events, and goes dancing whenever she gets the chance. She
    manages the office of her small department, including scheduling seminars and classes,
    fundraising, and maintaining their website. As their department often deals with political figures
    that may hold strongly opposing viewpoints, the members of her department must always be
    careful to avoid potential clashes between their visitors. This includes ensuring that people who
    would not want to be associated with each other are not featured prominently on their
    website at the same time.
•   Nina works with the Program Director to recruit potential speakers and secure funding, and
    uses the website to advertise their many events. They would not want to include events
    other than their own, as they see the website as a marketing tool for their organization only.
    Making sure the website presents a professional image is an important consideration for Nina’s
    team. She would also like to keep events posted even after they have passed, as new visitors
    to their site are often people searching for terms used in their descriptions of past events. Nina has
    no experience with programming, and her webmaster maintains the Center’s website. The
    calendar is very basic, consisting only of a list of events.
•   Nina would be interested in a new calendaring system if it would be easy for their members and
    visitors to use and would enhance their reputation by presenting an even more professional
    image. She would also like to maintain the current system of sending out an email to their
    mailing list whenever a new event is added, and ensure that she is able to modify events on
    their website at a moment’s notice, as locations are sometimes changed right before their
    events. Nina would love to be able to include links for their users to create maps to their events, as
    they often hold events off-campus. She favors the current list format of their calendar, and does
    not currently use a personal calendaring system, although she has used a PDA in the past.
•   Nina's Goals:
     –   Create a web-based calendar which will showcase only the events that occur in her department
     –   Present a professional image that will encourage potential speakers and contributors to work with their organization
     –   Manage the sometimes heated political climate that surrounds their speakers, including making sure two speakers
         who have opposing political views are not featured together on their website
     –   Drive traffic to their website by keeping past events listed there
     –   Send email to mailing list when a new event is added
     –   Modify events on a moment’s notice
     –   Allow users to easily create maps to their events
Summary

  Task Analysis
  Contextual Inquiry
  Personas
Next Time

    Guest Lecture on “Reflective Physical
     Prototyping”
        Reflective Physical Prototyping through Integrated Design,
         Test, and Analysis
        Authoring Sensor Based Interactions Through Direct
         Manipulation and Pattern Matching



    Please spend enough time on your project
     proposal!

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:1/9/2012
language:English
pages:83