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?