Made by: Leo Moran, Ezra Barber, Julian Tanguma, Josh Meier
Through my focus group, along with Julian's interview, I learned about the various functions that our users (Carleton College students within the dormitories) would want from the app. Some examples of what the user wants would consist of using their Carleton email as a means of logging on, using maps as an easier way of selecting dorms, and viewing the availability of all machines within a dormitory. The listed features are just a few features that were added to the prototype design of the app, all of which can be seen in Figure 1.
When the user initially opens the app, they will be presented with a login screen that will require their Carleton email which is then checked with the Carleton accounts to make sure that the user is a student. While the email was initially meant as a means of not needing to remember another username, I believe that it can also be used as a form of authentication to prevent third parties from viewing the user’s laundry habits.
For selecting their default building, I offer the user the option to either type the name of the building, pick from a list of buildings, or select the building on the map as designated by a star. The subjects in my focus group mentioned how requiring the user to select from a list or to type the building name can prove difficult for freshmen who don’t know the names of the buildings yet. The reason why I use three different means of selecting a building is to allow users to go through with whichever method they are comfortable with. When a user selects a building through whatever means, not only with the star light up, but the name of the building will appear within the search bar, allowing the user to know if they picked the right building.
Something that was mentioned between both my focus group and Julian’s interview is the importance of seeing the availability of all machines within a dormitory and if a machine is broken. To handle both needs, I have color-coordinated the machines according to their availability, if they are blue or red then they are in use (blue for washing machines, whereas red is for drying machines), if they are gray then they are free, if they are orange then they are broken. Furthermore, the times on each machine signify when they will be next available and can allow the user to plan when they head down to the laundry room.
For the final feature of setting a dorm as the default, it was mentioned in Julian’s interview as a way of being able to immediately check the availability of your dorm without having to select it every time. The feature of setting of choosing your dorm is then part of the process when making your account, and can be changed when you view other buildings. By allowing the user to change their default building, it accounts for when they may need to move at the start of each school year.
When producing the second prototype, my team devised what we called the 3 final requirements, which consist of the most important parts that would be needed within the next prototypes. The 3 requirements are as followed along with their justification for being requirements, and how I addressed them in my prototype:
To form the 3 final requirements, my team and I underwent a UX research process which included interviewing other students, coding the interview transcripts, and forming a consensus. For the interviews, each of my teammates as well as myself ran interviews with our classmates to better understand their perspectives on the laundry situation and what they would like from our app. Some of these interviews were run as typical one-on-one interviews, or we would make use of focus groups and interview multiple people at once.
Quotes from Josh's second intervew:
"um, the worst case scenario is either actually a medium scenario in between worst and best is that there's nothing open because it kind of sucks, but I can just do it another day, but I think, like the worst case scenario, is that I have to move someone else's clothes, and it's a man's and there's underwear"
"So I actually usually, like, set a timer for like, a minute before their laundry ends, and then I go downstairs, and then I wait by the laundry machine with my laundry bag, but I give it like, five minutes after their laundry ends, and then if they're still not down, then I start moving it out."
"I mean, like, Duh. I feel like, I feel like, it would be cool if, like,if, like, you were able to see, like, if something was reserved. "
With the participants' approval, we recorded the interviews before using some tools such as Otter.ai to transcribe the interviews into a document that we could later edit and mark up. After fixing any mistakes made by the auto transcribers and censoring the names to maintain anonymity, we exchanged transcripts and started marking key points that the interviewees said. The way we marked up the transcripts is through a process called axial coding where we would organize quotes from the interviewees as being Phenomenas/User Goals, Causal Conditions, Contextual Conditions, Intervening Conditions, Action or Interactional Strategies, and Consequences. Then we made use of an affinity diagram using the quotes we marked and tried to find common themes between the quotes. With the diagram, we made a Google Spreadsheet that contained smaller codes that fit within the initial axial coding and worked on coding two of each other transcripts using the smaller codes. Following this, we made new pages in the spreadsheet for each team member to enter the quotes they found in the transcriptions they worked on and organized the quotes based on the codes they followed. These pages then allowed us to compare each other’s codings and to form a consensus of which quote follows which code, so that we can form our final requirements that our app needs to follow.
The three demos I provided consist of the three interaction flows that I designed bassed on the user and the use case. Each interaction flow is as follows:
For the final prototype, I treated the three requirements my teammates and I agreed on as tasks for when I next interviewed someone over my prototypes. For the new interview, I made use of a Think Aloud process, where the subject would vocalize their thoughts while interacting with my prototypes. During the process, I not only recorded the subjects voice and screen, with their permission, but I also kept track of the amount of time and mistakes it took to accomplish it, and whether or not they were able to complete the task without my help.
New User
For finding the availability of the laundry machines, it took the user 2 minutes and 10 seconds after the user made 2 mistakes and they succeeded at the task. Then for selecting the dorm preference, it took the user 1 minute and 56 seconds after the user made 15 mistakes, but they failed at the task without my help.
When I pointed out the enter button, which was an arrow to the left of the search bar, pointing left, they said "I thought that would be the back button for some reason"
Normal Use
For finding the availability of the laundry machines, it took the user 16 seconds with no mistakes and they succeeded at the task. Then for selecting the dorm preference, it took the user 31 seconds after the user made 1 mistake and they succeeded at the task.
Reserving Machine
For finding the availability of the laundry machines, it took the user 56 seconds after the user made 2 mistakes and they succeeded at the task, which is the same results for reserving a machine.
After going through the tasks, they said "I wonder if you could favorite certain washer machines?"
Due to the amount of time and mistakes spent initially making the account, and the fact that the user initially believed that the enter button was the back button, I had adjusted the placement of the enter button as well as flipped it to point right instead of left.
To make the buttons more obvious, I made all buttons uniformed by giving them a dark outline, and turned the links into buttons as well, so as to stop users from tapping on non-interactive objects such as unreserved machines.
I then made sure to label each machine with a name and a number as per the request of the person I did the Think Aloud with. However, once the user reserves a machine, not only will a star appear like normal, but a button will appear underneath the reserved machine in place of their label.
I also added a notification bell when viewing the availability of a building to allow users to opt-out of being notified when their laundry is done, as per my classmates suggestion.
As a part of this notification bell, I also designed how the app would look when changing the settings for both notifications or the language to where the rest of the screen will dim down until the settings is closed.
Finally, as a part of reserving a machine, I also made use of the subjects request in allowing the user to favorite the machine, which doesn't do much aside from acting as a form of rating system for the backenda and giving the machine a little crown when viewing avaiability. Only one machine may have a crown in every building for each user.
As for future features that I was unable to implement within my third prototype would be to allow for reservations on a few of the machines in each building, add functionality to the magnifying glass, as establish an error screen for when the user does not enter their username and password, and an eye icon that allows the user to see what they are typing as their password.