Transcript Presentation Slides

MessageWiz
IS 213
4 April 2006
Project Goals

Develop a system that improves patient
medication compliance through increased
patient-health care worker communication

Develop a user interface that allows health
care workers to create and edit voice/text
messages, schedule them for sending, and
monitor their status
Personas
Our personas are primarily developed
based on health care professionals in
Kenya.
 These individuals are highly educated but
generally have little to no computer
experience.
 We also took into account the frequent
presence of Western volunteers in health
care settings.

Personas along two axes
Health/TB
Experience
BEATRICE
AGNES
HI
LOW
HI
NOAH
LOW
KARI
Computer
Experience
Meet Agnes….
32 y.o. nurse, been at
current job for 3
years
 Frustrated because
never knows how
many patients to
expect; planning
difficult
 Has mobile phone,
SMS user, minimal
computer skills

Meet Beatrice…
48 y.o. nurse with over
20 yrs experience
 Frustrated when out of
medications and no way
to communicate with
outpatients; troubled that
some patients not
finishing medication
regimen
 No computer experience
but would like to learn

Meet Kari….
25 y.o. Swedish
graduate student on 6
week volunteer
program
 No experience with
health care, but
expert computer user

Meet Noah…

25 yo pharmacy tech,
finishing degree in
pharmacology

Responsible for
dispensing prescriptions;
cannot check other
prescriptions for a patient
due to lack of persistent
records

Basic computer skills
(email, internet), has
mobile phone and uses
SMS
Scenario One:

The government has not provided the
clinic with the appropriate drugs for
patients in the continuation phase of
treatment. The nurses wish to contact
these patients to let them know not to
come to the clinic on their scheduled pickup date and come one week later instead.
Scenario Two:

A nurse at the clinic wants to record a
medication reminder for patients taking
RHZE in the intensive phase of treatment.
The reminder should be sent weekly.
Scenario Three:

The administrator would like to check and
see which messages failed to send and
why. She wants to see if any new
languages need to be added to existing
messages and cancel messages that failed
to send because the patient’s phone is not
in service.
Current Design VS. Lo-Fi Prototype
The recurring and single send message
functionalities were combined into one section
instead of two.
 Our low-fi prototype relied heavily on the use of
tabs for navigation. The current design
completely eliminates tabs and instead provides
sidebar and bottom-screen navigation.
 The change in navigation required a
repositioning of the “back” and “next” buttons to
eliminate confusion about which part of the
page they are controlling.

Current Design VS. Lo-Fi Prototype

Patient Section: In spite of presenting
testers with directions that they should
choose only relevant criteria from list
presented, testers felt the need to make a
choice from each type of criteria.
To address this, the types are available on
a sidebar and the user can select from the
relevant ones.
Patient Screen Shots
Lo-Fi Patients Page
 Hi-Fi Patients Page

Current Design VS. Lo-Fi Prototype

Lo-Fi Message Listing
Hi-Fi Compose Message
Listing

Lo-Fi Message Add New Hi-Fi Message Library
Listing

Lo-Fi Message Edit
Hi-Fi Message Edit
Hi-Fi Text Add
Current Design VS. Lo-Fi Prototype

The Low-Fi prototype featured an
“Outbox” which contained information
about sending and sent messages and
associated errors.

The use of tabs proved confusing.
Though it was hard to tell whether or not
this was due to how well we “played
computer,” we decided to eliminate tabs.
Outbox  Reports & History
Low-fi: Outbox with physical tabs
 Hi-fi: Reports & History with style
matching the rest of the site

Lessons Learned
 Users don’t read directions.
If they think they know how they should
behave they act accordingly even if it
seems illogical to us as designers.
We are left with the choice of either
changing the design to fit their mental
model, or better communicating our
different one.
Key Challenges Ahead

Vocabulary: We struggle with the
appropriate words to use.
Our users, while English speakers, speak a
different brand of English unique to Kenya,
at varying levels of fluency.

Kenyan input: We’re working on
establishing remote user interface testing
with participants in Kenya.
Prototype

Live Prototype