alarm clocks jake graham | leighton makoto ige | sarah leavitt human factors and interface design...
Post on 21-Dec-2015
222 views
TRANSCRIPT
Alarm ClocksJake Graham | Leighton Makoto Ige | Sarah Leavitt
Human Factors and Interface DesignFranklin W. Olin College of Engineering
May 2, 2005
Design Process to Date
• Project Selection-Primary User Groups
• Conducted Interviews
• Developed Personas, Scenarios, and Lexicon
• Formulated Initial Design Ideas
• Created Low-Fidelity Prototype
• Conducted Interactive Interviews
• Created First Interactive Prototype
• Heuristic Evaluation
• Created Second Interactive Prototype
• Conducted Pilot Usability Study
• Making Revisions to Second Interactive Prototype
Project Selection
• Hardware-Software Integration
• Manageable Sized Project
• Meaningful Design
• Ability to Implement our Results
• Alarm Clock!
• Insufficient & Inefficient Design
• Brainstorming Session
• Personal Experience with Alarm Clocks
Interview Highlights
• Analog vs. Digital Users
• Multiple Alarms / Alarm Clocks
• Irregular Sleeping Patterns
• Outrageous Ideas about Waking Up
• Seriousness of Problem
Personas
• Jackie Lee
• College Student
• Melvin Jefferson
• CPA
• Doris Jefferson
• Librarian Archivist
• Richard Sterling
• .com Millionaire
• Set and Arm Alarm
• Wake Up and Turn Off Alarm
• Use Radio
Scenarios
• Learning applies to all modes
• Simple visual feedback
• Color
• Flashing
• Display
Modality
• Analog Analogue
• Reduces number of buttons
• Allows one-handed control
• Forward/backward scrolling
• CW/CCW motion parallels analog clock
Scroll Wheel
• Verifies user’s consciousness
• Unpredictable
• Deactivation process takes time
• Does not allow for incomplete deactivation
Random Chase
• Snooze Time Decreases
• Set Starting Snooze Time
• Finite Amount of Snooze
Reduction Snooze
Low-Fidelity Prototype
Interaction Flows
• Menu System
• Menu Options vs. Multiple Presses
• Hardware to Software
• Limitations due to time
• Radio Functionality
• Color / Lights
Changes from Low-Fito First Interactive
Heuristic Evaluation
• Problem Highlights:
• Functionality
• Prevent Errors
• Speak the Users’ Language
• Majority of problems already known
• Majority of problems mitigated by physical prototype
Interactive Prototype-Take Two
• All Severity 3+ Fixed
• Fixed Implementation Errors
• Functional (radio)
• Preventive (radio)
• Few minor problems postponed
Pilot Usability Study
• Gave users no background information
• Went through tasks one at a time
• Most took <25 seconds
• Hints given when users got stuck
• Error-prone tasks
• Setting alarm
• Using radio
• Overall, very positive
• Good Feedback
Interactive Prototype
Live Demo
• http://fsweb.olin.edu/courses/engr3220/sa2004/engr3220-violet/phase5/violet_phase5.html
To-Do List
• More 3D looking Flash Prototype
• Iron out few remaining bugs
• Radio preset functionality
• Colors/schemes of buttons
• Discuss toggle interface
• Users want controlled defeat-ability.
• Good design is not necessarily innovative.
• Paper prototyping works well.
• Say what you mean.
• Formal Usability Study we designed would have been very beneficial.
Lessons Learned
Thank You!
Questions?