VERIFY / 2017
DATE Late 2016 - Mid 2017
ROLE Lead Designer / Researcher
TEAM One Visual Designer (+ Me) / Product Manager, Technical Program Manager, Dev Manager, Engineers (8)
TOOLS Sketch (Wireframes, Visual Design) / Axure (Rapid Lo-Fi Prototype) / Confluence + JIRA / Agile Development in 2 Week Sprints
WHY When I was in the second grade I went home with my friend Ginny without telling my mom. For over an hour she frantically made calls to find out where I’d gone. That was the early 90’s, but even after all of the technological advancements that have arrived since second grade, I’m still better able to locate my microchipped terrier than a child who got on the wrong bus or off at a bus stop miles from their home.
Verify is an Android app for school bus drivers to manage their roster and ensure that students are safely dropped off as expected, with feedback letting them know if a student scanning their ID card is on their roster or assigned to a stop.
DEMO THE PROTOTYPE (ABOVE)
selected Screens
Schedule (Home) Screen
Drivers start a trip from those listed in the schedule: often they drive 3 trips in both the morning and afternoon, with one or two in between.
Trip Preview Screen
Drivers preview trips in their schedule before starting them. Adding the step helps to ensure they don’t select the wrong trip accidentally, as often the stop sequence is the clearest way for routes to be identified.
STOP SCREEN
Automatically opens when the bus enters a geofenced area surrounding the stop.
The state of each assigned student’s card changes as student ID’s are swiped.
Drivers are extremely distracted as students board the bus. This screen needed to have minimal if any interactions and clearly communicate the rapidly changing states of the roster cards.
If a big yellow school bus is at capacity, 72 students have boarded. The screen was organized to make such a large number of student cards easily manageable. Groupings, hierarchy, and grid were major points of interest.
ADD RIDER FAB
If a student does not have their card, a common occurrence with kids of all ages, the driver can “virtually” swipe them on/off or search for their name.
The only interaction required by drivers during stops, the prominence of the FAB made it a successful choice. We found that content in the header tended to get lost.
If “virtual swipe” is selected, and generic student card is added to the stop screen to represent the student.
NOt on ROSTER DIALOG
Several dialogs communicate to the driver when a student swipes at the wrong stop or on the wrong bus.
Student exception states include: Pick-up on wrong bus, pick-up on wrong stop, drop off at wrong stop, swipe on but no swipe at exit.
Dialogs need to be manually dismissed as drivers could easily miss the message if it timed out.
We worried these dialogs would be a nuisance, but testing showed drivers were happy to spend a few seconds to review them before proceeding.
TRIP REVIEW SCREEN
Summarizes the roster exceptions, with the most significant issues at the top.
For technical reasons drivers need to manually end a trip.
how verify was made
Zonar developed the app in partnership with a large school district customer in Texas that transports 70,000 kids a day with the funds and exemplary operations that make it a leader in school transportation across their state. Their goal is to solve the two biggest problems schools face: losing a child and accidentally leaving them on the bus. As students scramble on and off the bus, it’s easy to lose track of who’s who and where they exited. Drivers can only count on memory and a printout roster of assigned students to keep track.
Our Texan customer wanted to maximize the value of the data collected with ZPass, Zonar’s RF transponder-based product that identifies students when they swipe their school ID card. While ZPass only presents this data for administrative reporting, Verify would send data from each swipe to a dash-mounted tablet and displays the student’s name, along with confirmation that the student is on the correct bus and stop, or a warning that the student is not on the roster.
Prior to Verify, I headed the company’s first user research study, conducting contextual inquiry with student transportation customers across the country. I had a lot of user data to hit the ground running when Verify kicked off. I partnered with a product manager and we worked closely with our customer partner, but also other customers to ensure the solution was not irreversibly bespoke. I also worked closely with the engineering team and a more experienced visual designer on the UI.
During development, we travelled to Texas to test the app with 25 drivers. I spent a week riding shotgun with drivers, and a whole bunch of kids, while I observed and conducted usability testing. We did it all again two months later towards the end of development. I hosted feedback sessions with the drivers, in which many shared how guilty they felt for not knowing every student’s name. They greatly appreciated having the means to get to know them better, individually.
Verify shipped in time for the upcoming school year and our customer gradually increased the number of units running it over the following months. Transportation directors visited from far and wide to see the app in action and we sold it to a limited number of customers utilizing the same routing provider integration. Zonar continues to support Verify, but has delayed efforts to expand and integrate Verify with other third-party routing solutions.
design artifacts
CONCEPT FLOW
Created while working through user stories to communicate the basic IA, stories, and tasks involved in using the app and RFID system.
SITE MAP
Block layouts represent each screen in the app, the system was simplified further before development with the details outside of the primary flow removed.
Early user research showed that it was unlikely drivers would have the time or even ability to navigate away from the stop screens during a trip.
Affinity Wall (Section)
Before starting Verify, I conducted a research study with student transportation customers and assembled an affinity wall to process the mountain of interview data collected.
FAB ALTERNATIVE
Predictive search was scoped out of the first release and replaced with a roster list for drivers to swipe through to find a student. It did not test as highly as search, but did well enough to be included as an intermediate solution.
STOP SCREEN ALTERNATIVE
1 Student cards are grouped with the least important grouping located at the bottom. In most cases all cards would fit without the need to scroll, allowing all info to be viewed at once. This layout was ultimately chosen.
2 Tabs divide student cards between “on the bus” (scheduled) and “off the bus” (completed).
3 Main content area horizontally divides students into two sections, those who have scanned on the left and those scheduled but have not yet swiped.
4 Divides students into two groups with each group given equal weight.
5 Tabs divide students into three groups, with a third group isolating and making more prominent the anomalous student activity
FAB MENU ALTERNATIVE
Links in the menu were initially broken down so that users are forced to select from 4 options. An approach that reduced the options to two choices was much quicker for users to complete.
USER TESTING
View from the GoPro recording bus drivers as they used Verify while driving a morning route.