Project
8
myBalsamiq Prototype
Christopher Carrassi, Tony Huynh, Jared Storts, and Amanda Tait
Department of Electrical Engineering and Computer Science, Oregon State University
Corvallis, Oregon, United States
carrassc@oregonstate.edu, huynhton@oregonstate.edu, stortsj@oregonstate.edu, taita@oregonstate.edu
Abstract -- This paper presents a myBalsamiq prototype of
our interface solution for the Electronic Application
Transformation (EAT) School Lunch UX Hackathon. We
discuss the most salient design decisions and the research,
analytical, and test data behind them.
Keywords -- prototype; myBalsamiq; heuristics; Nielsen;
users; analytical; empirical; usability; user experience;
I. INTRODUCTION
Our prototype interface was designed to solve the
usability problem presented by the US Department of
Agriculture's Electronic Application Transformation (EAT)
School Lunch UX Hackathon. The hackathon asked for
submissions of a model electronic program application form
that offered usability and user experience improvements over
the existing paper-based application form. Towards that end
we have designed our prototype to offer the following
improvements: that it reduce the error rate in applications,
that it use branching logic to customize the data gathered to
the specific user, that it be clear, easily understood, and
welcoming, and that users feel comfortable sharing the data
that is being asked of them.
II. MATERIALS
A storyboard summary of our prototype is presented in
Appendix A. The myBalsamiq prototype itself is presented
in Appendix B.
III. DESIGN DISCUSSION
As mentioned in the introduction, our prototype tries to
reduce the error rate in user applications, in accordance with
the requirements for hackathon submission laid out by the
USDA. Further, one of the salient points that came out of our
user research was the fact that users tend to feel profound
anxiety around filling out these sorts of applications, anxiety
centered around fear of making a mistake that will lead to the
rejection of their application. Accordingly, per the general
design principle of constraints and the Nielsen heuristic of
error prevention, we have designed user interaction with the
application to be constrained to only the input and output that
is necessary to each immediate task. For example, form
fields are limited to no more than 3 per screen, and the user
cannot advance the application until input has been entered.
In a live implementation, we would incorporate client-side
input validation, along with helpful, clear, error messages, to
only allow application progress if the user is entering correct
data, and to provide help if the user is entering incorrect data.
One of the problems that cropped up during empirical
evaluation was that not all of our UI elements were
consistently implemented. For example, our help button was
sometimes visually disabled when no help was available for
that screen, but other times it was still visually enabled
despite there not being help. This understandably caused user
confusion because they couldn't count on visual indicators
having the same meaning throughout the application.
Accordingly, we have revised the interface to better adhere
to the Nielsen heuristic of consistency, and the design
principle of affordance: if it looks like a UI element should
do something, it does.
Another issue that manifested in empirical evaluation
was that not all of our prompts were equally clear,
welcoming, and helpful. Users were sometimes confused as
to why certain information was being asked of them, and
why it was being asked of them at that particular moment. As
a result, we've rewritten much of the prompt copy, and
provided additional help text, with a particular focus on the
areas where users felt most uncomfortable or uncertain.
One screen in particular caused users a lot of
consternation: the signature and date screen. In the prototype
we tested, we located that screen relatively early in the
application. We did so because the hackathon project
requirements recommended that the signature and date be
located early in the application, a recommendation which
seemed to have been supported by our research: program
administrators mentioned that one of the most common
application errors was users forgetting to sign the form.
Accordingly, it seemed logical to move the signature and
date up to an earlier point in the application, so as to get an
important data point gathered early. In practice however, it
turned out that users are too habituated to a signature and
date appearing at the end of an application to realize they
weren't at the end of the application. Many users, upon
reaching the signature and date screen, thought the
application was already over, and either thought that they
had made a mistake or that the application was broken. As a
result, we decided to relocate the signature and date to the
end of the form, in its normal and natural position, reasoning
that because of the heavy emphasis on interface constraints,
and because users proceed sequentially through each item of
the application, there wasn't really a way for a user to forget
to sign the application. Accordingly, there was no reason to
risk user confusion by having the signature and date in an
unusual position.
Tying in with some of the aforementioned design issues,
we discovered that the branching and fast tracking logic
sometimes confused users. While an electronic application
allows for much safer omission of unnecessary form
elements in comparison to a paper application, users need to
understand that elements of the form are being omitted
safely, otherwise they may worry that they had done
something wrong. Our user testing made clear this concern
was not idle: users were confused by fast tracking, as
opposed to feeling rewarded. Accordingly, on pages which
can trigger fast tracking, our instructional text makes clear
that a fast tracked application is a potential outcome if, for
example, they're able to provide a SNAP or TANF case
number. Likewise, we have reworked the application
progress bar to more accurately reflect where the user is in
the application, and to give an accurate visual queue for
when they trigger fast tracking. In other words, when a user
triggers fast tracking, they see that they've skipped over
much of the application in the progress bar. The end result is
an application with a more readily visible and intelligible
system status.