- asiya atcha
ClassroomFinder App: A Crash Course in HCI and My First Experience with UX Design
Updated: Jan 30
This project is an old one, but a good one. It's important to me because it was my initiation into HCI and UX design.
The University of Toronto Mississauga campus used paper schedules posted outside classroom doors to direct students. We found them unclear, difficult to locate and understand, and often outdated. We wondered if there was a digital solution to the problem.
Our Observations
We started by observing users outside classrooms in the Instructional Building to learn about current behaviors and solutions employed by the UTM population. In total, we observed 10 students in great detail. We found that most relied on some combination between checking their phones and consulting fellow students. Our suspicion that the schedules posted outside classrooms were useless was confirmed by how infrequently they were used.
A sample Observation:
Users #4 and #5: The two users, male between the ages of 17 and 27 walk down the hall towards the classroom, they glance up at the wall at the numbers outside the classroom doors. User #4 says, “Is this it?” and he swivels his head as though looking for something. He sees the schedule posted on the wall and he shifts his backpack as he strides towards it. “I can’t tell,” he says as he backs away from the sign towards User #5 who says, “Hang on.” He looks down at his phone, which he was holding, and scrolls. We presume that he is checking his schedule on Rosi. “Yeah, this is it,” he says as he lifts his head and strides towards the classroom. He walks in and his friend turns and heads back down the hall towards the stairs.
The Interviews
Our observations were further confirmed by our interviews, where our users reported that they relied on a combination of some previously downloaded schedule on their phone and their previous knowledge of the building layout to find classrooms.
The Participatory Design Workshop
We intended to go in the direction of a mobile phone app, as per the assignment requirements and based on our own understanding of the interviews and user observations. In doing so, we created a series of participatory design workshops aimed at eliciting ideas from our users on how they would use an app and what information they might want to see.
The approach was low-fi, with only paper, pens, markers and post-it notes as our prototype materials. We worked in the area where we did all our interviews and most of our observations, in the south side of the Instructional Building. Although it wasn’t planned, we ended up working on the floor. We would have preferred a table, however, it did contribute to our process. Users were more interactive, fluid in their movement and worked collaboratively, reaching across the design space to look at and comment on each other’s ideas and suggestions. We started by describing our problem/idea, and gave the participants a quick rundown of some of the solutions we derived from our user interviews.
We approached our workshop with the notion that users often don’t know what they want from a design. To help our users generate ideas, we tried a simple brainstorming technique. We asked them to think about the current signage outside classrooms and tell us what they didn’t like about it. The result was a long list of grievances. They were fairly clear and direct, so we were able to translate them into requirements.
Along with various iterations of a mobile app, our users suggested that a kiosk may be a good interface for a product like ours. We decided to test that assumption in a pilot study.
The Pilot Study
We ran a pilot study to test the possibility of using a kiosk system as a classroom schedule after several users in our participatory design workshop suggested the design. While the experiment wasn’t a complete success because of some confounding variables. The other challenge was that with each progressive test, we honed our experimental methods, so that the results outlined in the later sections of this paper are not representative or statistically sound.
The pilot study was also the first time in our process that an actual mock-up of our final interface started to crystallize. We incorporated some elements of our final vision, including a map, an input box, and a submit button in our prototypes. We got some feedback on these elements and decided to build on at least one element in our experiment design.
The Experimental Procedure
The purpose of our experiment was to test whether our users would prefer kiosks or mobile platforms when given the choice. We loaded an image of a map of a UTM building onto a television screen positioned outside the classroom in an open corridor and we loaded an medium fidelity prototype of a mobile application onto two tablets, one iPad and one Samsung Tablet. We then invited participants to step out into the hall with us one by one. We went through the testing procedure using the following script:
We tried to follow the script to the letter, allowing for some variations depending on where the user led the experiment, with the answers to the questions at the beginning and end of the session. After the sessions were over, we transcribed and coded our results.
Our experiment participants seemed to approach the input box of our mobile application prototype with some confusion. We wondered if it would help to be prompted by a drop-down menu style input instead. We tested it against a predictive-text input box, another standard input form. Our control was a free-form input box. Again, because of various confounding variables, our experiment did not go as planned, and it was difficult to make any final conclusions from our results.
In the creation of our final prototype, we’ve decided to go ahead and use a predictive text input box. This option narrowly won out in a quick poll of our experiment participants, so it became our final choice.
The Final Prototype
To view our first draft of the final prototype, click here: https://invis.io/AV6TYPNYT
To view our second draft of the final prototype optimized for Android, click here: https://invis.io/GV6VMBJJF
To view our second draft of the final prototype optimized for iOs, click here: https://invis.io/5J6VMDCCN
To operate the prototype for this demonstration, follow these steps:
Tap “current student”
Tap “sign in”
Tap the “CCT Building”
Tap inside the “find classroom schedules bar”
Tap “C-C-T”
Tap “CCT4080”
You will arrive at the final screen.
To view other screens in the app:
Tap the calendar icon to see a personalized schedule for the user.
Tap the star icon to see a list of favourite classrooms.
Tap “CC4080” to see the schedule for that bookmarked classroom.
The final prototype was a simple application that users can login into with their utorid. Our initial design included several extra screens at each step which were confusing to click through. Our personalized features were all stored under a single icon. Based on the inspiration for this design, the UTMSU app, we included a messaging application and an inbox.
In our final design, we narrowed it down to the absolute essentials for a schedule application. We got rid of the messaging and inbox options. They aren’t necessary to understand our product, and just cluttered the interface. We split the personalized section into two options to make them easier to navigate and read. We removed some extra images that crowded the interface.
Users could browse by building, and view their location within a given building on the map. They could store specific rooms in their favourites and reference their schedule in the “my schedule” section. We felt this was necessary to include, as almost all of our users mentioned referring to their personal schedule at some point in the process. We included the section for favourite rooms, because our users often told us they frequented specific rooms regularly but they had no way of knowing exactly what was happening in those rooms without going there. The schedule is a simplified version of the existing paper schedule, limited in focus to one day, with the current timeslot highlighted.
While there is never a perfect final version of any mobile app, we felt confident that we’d built an excellent starting point for further iterations. Our prototype follows conventions of existing applications in the UTM digital ecosystem and contains elements that are drawn from our best attempts at experimental design. Most importantly, many elements included were built as a direct response to our user’s needs and their specific usage habits, both those they expressed and those we observed.
Comments