220 likes | 361 Views
Alarm Clocks. Jake Graham | Leighton Makoto Ige | Sarah Leavitt Human Factors and Interface Design Franklin W. Olin College of Engineering May 2, 2005. Design Process to Date. Project Selection-Primary User Groups Conducted Interviews Developed Personas, Scenarios, and Lexicon
E N D
Alarm Clocks • Jake Graham | Leighton Makoto Ige | Sarah Leavitt • Human Factors and Interface Design • Franklin 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
Scenarios • Set and Arm Alarm • Wake Up and Turn Off Alarm • Use Radio
Modality • Learning applies to all modes • Simple visual feedback • Color • Flashing • Display
Scroll Wheel • Analog Analogue • Reduces number of buttons • Allows one-handed control • Forward/backward scrolling • CW/CCW motion parallels analog clock
Random Chase • Verifies user’s consciousness • Unpredictable • Deactivation process takes time • Does not allow for incomplete deactivation
Reduction Snooze • Snooze Time Decreases • Set Starting Snooze Time • Finite Amount of Snooze
Changes from Low-Fito First Interactive • Menu System • Menu Options vs. Multiple Presses • Hardware to Software • Limitations due to time • Radio Functionality • Color / Lights
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
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
Lessons Learned • 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.