This was a group project for the Introduction to HCI class. I contributed to the project during the ideation, wireframing, prototyping and usability testing stages.
This project was about exploring how we can make the lives of parents with kids aged 5 to 10 better. Our premise was that getting the kids ready in the morning each weekday to catch the school bus on time can be hectic, and picking them up in the afternoon can involve waiting for an uncertain amount of time at the bus stop. We wanted to explore this "daily chore", learn more about the experiences of parents with kids in elementary school, and design an app that could be of help to this set of parents. We called it Bus Buddy.
Understanding Our Users
We interviewed a 5 parents with kids going to elementary school to understand what their primary needs and concerns were. The interviews were semi-structured, and we talked to the parents about what it was like each day in the morning and evening when their kids got ready or got back from school. We gently steered the conversation where needed to learn about what their chief concerns were.
We learned a few notable things:
- Uncertainty: Not knowing when the school bus arrives (both in morning and afternoon) with certainty wasted both time and mental energy. Accounting for the variability caused schedules to be more constricted, and caused the parents to exprience a reduced sense of personal freedom.
- Information at a glance: When prodded about using an app, we learned that parents would prefer to use something that would provide them information at a glance, without having to any significant amount of time using an app.
- Safety: A large concern that surrounded the drop-off and pick-up of their children was safety. Knowing whether their child had reached school, or had made it into the bus was a big part of their perception of the child's safety.
- Bus drivers' role: We learned that most parents recognized their child's bus drivers, and the drivers recognized the children by face. The drivers were also concerned about the children's safety, and experience similar anxieties if a child did not show up on time.
Ideation and Design Directions
We collected our inputs and all came up with several different design directions. We discussed the priority of various aspects of the system, various media to deliver the service over, and several visual representations of the information, like a map, a tube-stop, a Weasley clock, etc.
We initially considered the participation of children, parents and drivers into the system and envisioned what the system should feel like for each of them. Particularly for children, we explored making interfaces geared towards them to help not only alleviate some responsibility from the parents, but also teach children about being responsible.
We also considered other kinds of physical interfaces which both children as well as parents could use together.
While we explored all these design directions, we realized that in order to prototype and test the system, we will need to exercise restraint and narrow down the scope of the system to most important facets. We settled on designing a system with the following aspects:
- Parents use an app that allows them to track the ETA of the bus that their child/children are on/will be on.
- The bus driver would check off each child on a tablet-based app in the bus as they boarded/deboarded the bus.
- The children would carry easily scannable RFID cards in their bags to facilitate the bus driver in checking them off on the driver's tablet
- Parents can be notified of when their child boards their bus on their way back to school. They can also cancel their child's pickup in the morning if plans changed.
Wireframing and Prototyping
Due to a limitation on how much we could design, prototype and test within our time frame, we decided to focus solely on the parent's end of this ecosystem. We first nailed down what the overall architecture and screen flow of the parent app would feel like...
... and then started with wireframing. We drew up a few iterations of wireframes, and proceeded to convert the wireframes into a clickthrough prototype. We mainly focused on ensuring that the most relevant and important information was most easily accessible.
Most-relevant information up-front.
The most frequently occurring departure from routine was when plans changed. Sometimes kids can't make the bus in the morning. Other times, parents need to pick them up from school for a doctor's appointment. We made that operation easy to perform as well.
Changing plans should be easy.
We used the wireframes to build a web-based prototype that could run on a phone. The app had an admin console where we could set up the prototype to simulate various situations like the current time of the day, the names of their children, whether their children are already on the bus, etc.
The prototype can be accessed online by following the link below.Web-based prototype
Test and Evaluate
To test our designs for usability, we recruited 9 participants (6 of who were parents of elementary school children) and asked them to perform several benchmark tasks on the prototype, while we observed their actions and timed them as they performed them. We then asked them to complete a short survey where they rated the prototype, and then proceded to collect qualitative feedback from all participants while the experience was still fresh in their minds.
The whole process taught us many things:
- Learnable: The prototype was very easy to learn. None of the participants required any guidance during the test session. Some particpants had a little trouble/hesitation in the beginning, but their response times improved rapidly for subsequent tasks.
- Fast response times: The design allowed for very quick task completion. Most short information retrieval tasks were completed under about 8 seconds (median time), and longer tasks like plan changes were done under 15 seconds.
- Iconography helps: The iconography worked very well. In the post-test surveys, test users reported that the icon helped them along in their tasks.
- Broken signifiers: The testing revealed that some elements on the interface suggested that they were interactive or clickable, while they were not. In some cases, the reverse was reported due to a mismatch of font styles and colours with the mobile OS' native style. These helped us identify easy fixes to the design. We also realized that when building a mobile-web prototype, the prototype's fonts and colours should conform with mobile standards. It helped the participants to infer interactive elements better.
- Reveal confusing task flow: We learned from the testing that the user flows for changing plans for the future (not today's plans) was confusing and needed to be fixed.
In summary, the project was a good practical exercise in user-centered design, testing and iteration.