Part 3

Greyson Burnett, Kevin Byrne, Sophia Handel, Zeke Day

Usability Specifications:

How much does the user have to move to use the interface?
How long does the user take to notice that the interface has vibrated?
How many times does the user miss the vibrations?
How many times does the user err in voting?
How intrusive is the device for the user?
How easy is it for the user to take and return the device?
How stylish is the device?
How long does the user take to vote completely?
How responsive is the swipe interface to the user’s finger?
How easily can the user recognize the songs?
How much fun is the user having while voting?

The first and foremost usability specification we used for our device was that the voting
process needed to take less than 1 minute to fully complete. This is imperative because the
device is intended to be non-intrusive yet constructive to the user’s club experience. A minute
block of time to vote lets the user have a say in the music and makes voting a fun activity, but is
not tedious enough to detract from the fun.
The second usability specification we focused on was the user must be able to recognize
the song added to the screen both quickly and accurately. We realize that there will be a lot of
flashing lights in the club and it will be dark. It should take the user no longer than 10 seconds to
be able to comprehend the screen, factoring in intoxication and other factors such as being
jostled. This leaves the user 10 seconds to vote per song, which is plenty to do for a swipe.
Other usability specifications we need to take into account is the vibration of the
wristband to alert the user to the voting in progress. The user should be able to notice the
vibration the first time it goes off. Worst case, the wristband has to vibrate a second time to alert
the user. The vibration must be strong and unique enough to alert the user. We can expect an
error of no more than one from a properly implemented wristband for it to function effectively.
Another specification to note is that the user should be able to notice how they are voting
each time they swipe on a song, as to minimize errors in voting. This is why we implemented an
animation as the user was swiping, to help them recognize the direction they were swiping. We
also tried to keep the swiping style similar to Tinder, so it should be like second nature to the
user. We should expect a maximum of two errors for the first voting session, and no more than
one for each subsequent voting session after that. The use of the emojis is also reinforcement
to help the user know if they voted correctly based on their preference.
The intrusiveness of the wristband to the user is another usability specification to
consider. We (and Professor Walker) took this into account both while the user is voting and not
voting. A fun way to allow the wristband to dissolve into the ambiance when the user is dancing
is to have an accelerometer inside the wristband that tracks the movements of the user. We can
take this data, along with data about the current color and pattern of the lights in the club and let
the screen of the wristband transform into part of the light show when the user is not voting. The
more the user moves, the more the lights will change or participate with the club’s atmosphere.
This is an iteration off of the initial prototype, which just had a black screen.
A more logistical usability specification for the user and the clubs relates to the speed of
receiving and returning a wristband. The wristband handout shouldn’t take more than 5 seconds
if everyone is to get a wristband. The return should be equally as efficient as everyone has to
return one before they are allowed to leave. We can consider taking collateral for the wristbands
in the case that they aren’t returned, or handing wristbands out just to VIPs, but that would slow
down the receive/return process. A layer of exclusivity might add to reflective affect, promoting a
symbol of status for the user, but it could also take away from the community feel of voting.
Another usability specification is how the user feels while wearing the wristband. It
should be aesthetically pleasing, and able to be worn with a variety of different clubbing outfits.
This would be evaluated subjectively from users based on visceral affect. We can also measure
behavioral affect in the user too. The voting process must be a fun and enjoyable part of the
user’s night.
Lastly, the swipe interface must be compliant to the user’s wishes. The response time of
swiping should be instantaneous, so the user can swipe without waiting for any processing. It
should also swipe at the same rate as the user’s finger is moving, so if a user swipes quickly,
the screen disappears quickly and brings up another song, but if the user wants to peak either
way while swiping, the screen will only move as deliberately as the user’s finger is going.

Evaluation Plan

As with any evaluation of a system, one must consider the proficiency in terms of
performance and preference. Since we are evaluating at the end of the development of the
system, it will necessarily be a summative evaluation. The system does not lend itself to being
evaluated in an empirical setting in order to measure the performance of our JukeBand. We will
instead rely on a more naturalistic setting in which we observe our users and measure the
performance against specific benchmarks we have predefined. The goal of our benchmarks will
be to collect as much objective data as possible so it can be analyzed. The gathering of
subjective data will play a larger role when we evaluate preference.
The most likely scenario of a benchmark test would be to simulate the environment of a
club. It would need to be crowded, dimly lit, loud, and mimic the effects of inebriation. This will
give the most valid data upon which to evaluate our system. If we did not exactly simulate the
actual environment, the user wouldn’t run into the same problems that are present in the real
world. In order to measure how easily the user can interact with our device, we would tell them
specifically what to do. An example would be to indicate a positive preference for the first and
third song, and then indicate a negative preference for the rest of the songs. By explicitly stating
what we want out of them, but not explaining how they would accomplish it, we can measure
certain metrics like number of errors, speed of use, and comprehension of the on screen help.
 This type of instruction removes the possibility that the user will want to take a long time
to decide on each song. This isolates exactly how a user will interact with it rather than allowing
their personal biases and behaviors to ruin our data.
The goal of the performance is to reduce the time necessary to interact with it and to
reduce the total number of errors. Although it may seem obvious to us, the designers, how to
interact with our interface, without this type of data from a diverse set of users--and not
necessarily our targeted user group--we can vastly improve the system by identifying the most
common error-causing parts of our system.
Because we are running this evaluation in a naturalistic setting, it could ruin the
experience if we are in the same room as the participant or if they notice they are being
observed. We will try to be as removed as possible. Recording the participant on video, taking
notes during the experiment, and a screen recording software installed on the device would be
our three main methods of data collection for this section of the evaluation. All of this data would
be used to measure the benchmarks. Since the measuring of performance is purely an objective
endeavor for us, we would likely not use any type of verbal or post-event protocol such as a
think aloud in this part of our evaluation.
Although we do not have much of an independent variable to manipulate, it is possible
that we could vary how many people are trying to use the system at once. By utilizing
co-discovery learning, we could have pairs of people all trying to accomplish the same
benchmark tasks all on their own device, but they could figure it out together. A between
subjects design would lend itself the best for something like this. By having some people do it
independently and have others do it in pairs, we could discover if having others with you--a
likely scenario in a club--could help the users understand the system much better. There would
be too many order effects since once they successfully understand the system, it wouldn’t be
possible to expose them to the system for the first time again as is necessary for a within
subjects design.
For the preference part of our evaluation, the likely best way to accomplish this would be
through a questionnaire administered directly after they go through our performance evaluation.
This eliminates the issue of how to disseminate the questionnaire and most of the issues with
getting users to fill out the survey. It would obviously be optional, but heavily encouraged.
The survey would use a combination of open and closed questions in order to gain
easily analyzable data, but not restrict all of the potential feedback. The section containing
closed questions would be targeted at evaluating Norman’s three level of emotional processing.
There would be questions about the visceral, behavioral, and reflective levels utilizing the Likert
scale with an even number of responses so that the responder has to choose a positive or
negative reaction.
By aiming them at all three levels, we can evaluate exactly where our design succeeds
and fails. Rather than gathering broad statements about how much a user liked the device or
not, we can be very deliberate about the questions we ask. An example of the visceral level
would be to rate the system’s initial attractiveness to the user when they first saw it. In this way
we can eliminate answers to our questions that aren’t necessarily useful. Only the responses
that we specifically want will be able to be given.
 Since there are still disadvantages to using closed questions, we would supplement
these with open questions in order to get a wide range or responses, including those interesting
ones that we never predicted. Since these types of questions are much harder to analyze on a
large scale, we would not have as many, but they would still be present in order to get creative
feedback on our design. One example of a question might be “What did you like the most about
the system?” or “What was the most lacking feature of the design?” By avoiding leading
questions and not being too specific, we can attempt to reduce the issues that using
questionnaires produce.

Prototype Description

The objective of our design is to allow club-goers to have input in song selection. In this
system, the users and customers differ. To focus on the needs of the users, or club-goers, we
need to first consider several situational factors. Clubs typically have high noise levels, poor
visibility (due to darkness as well as bright, flashing lights), and little space for movement. The
atmosphere of the club is distracting in every way, which is why we do not
want our system to demand the same level of attention as the surroundings.
Our goal is to maximize users’ enjoyment of the club while minimizing the
amount of time and effort it takes to accomplish this task.

Considering these factors and our goal, we created a wristband, or as

we like to call it, a JukeBand. The JukeBand is a touchscreen wristband, light
in weight and with a durable, silicon/rubber band. The product is easy to clean
and the band is customizable. A customizable band allows clubs, the
customers, to choose a look that matches their aesthetic, as well as choose
different over-21 and under-21 designs. Here is how our system works: the
DJ sends out five songs at certain times (up to their discretion). As soon as
the watch registers the vote (timing is staggered so that not all the users will
vote at the same time), the wristband vibrates.

The screen displays the name of a song, artist and album cover. Emojis on
either side indicate which direction to swipe. To vote YES (“I would like to hear
this song”), swipe right, or move your finger towards the hearts. To vote NO (“I
would not like to hear this song”), swipe left, or move your finger towards the
skulls.

As you swipe, a large version of the corresponding emoji

will begin to appear behind the page that is being swiped
away. If you realize you are making the wrong choice, you
simply need to change directions.
Swiping right. Swiping left.
Once your vote for that song is complete, a large version of the emoji will be completely
uncovered before the next song screen appears. When voting is complete (all 5 songs have
been voted upon), a large check mark appears.

The following series of photos will take you through a session of voting for 2 songs. We voted
YES for the first, NO for the second. After the check mark is displayed for a few seconds, the
screen goes back to black and the user knows that the voting session is over.

Something that we initially struggled with was the amount of power that we wanted to
give users. Could club-goers request songs through our system? Could they vote for songs
through our system? Could they both vote on and request songs through our system? We
ended up deciding to give users the power to vote through our system, and to not build in a
song request feature. We felt that a system with both features would greatly distract users from
experiencing the club and would also limit the DJ’s creative power. Again, we want to maximize
enjoyment and input while simultaneously minimizing effort and interaction time with the
interface.
Something really exciting about this design, that Professor Walker brought up, is the
potential for different types of voting. Maybe users can only choose one option out of two or
three; maybe users can vote on artists or theme nights. All of the variations could have different
appearances so that users could immediately differentiate the type of action required of them.
Having so many options available gives our design ample room for system updates and
customization.
In terms of design justifications, the wristband as a whole is very durable and flexible.
Since users are often times in a bar setting or near drinks, the design is waterproof. The product
is also compact so that it will not get caught on clothes or accessories. We realize that
sometimes broken wristbands would be unavoidable despite their durability, which is why the
product would not be made out of costly materials. Club-goers do not want to be responsible for
an expensive piece of technology throughout the night.
The JukeBand vibrates to notify users of voting in order to counteract the high noise
levels of the club. The song screen is also designed to ease users’ interaction with our system.
The song title is a textual cue accompanied by artist and album cover, a visual cue, to aid
recognition. The placement of emojis on either side of the screen builds off of users’ preexisting
knowledge of emojis used in texting; likewise with swiping and the millennial culture surrounding
Tinder. These characteristics increase the learnability and predictability of the JukeBand and
help to make it an efficient, effective and enjoyable design.