Improving child safety in school buses
Project Summary:
A redesigned driver notification strategy maximized the safety benefits of launching improved hardware for school bus passenger doors. 8 new driver notifications provide feedback related to door operation during 9 unique use cases.
Creating clear feedback for school bus drivers
Previously school bus doors were controlled by hydraulic actuation. Now there are smart door systems, controlled by motors, that stop the doors when obstructed by children. The system also prevent the doors from opening when in motion.
As a result, there are new scenarios where the doors will not respond to driver requested door commands. This door behavior could lead to confusion without a clear notification strategy to explain why the vehicle isn't honoring door commands.
My role in the project:
As the HMI Lead for this feature, I refined the use cases, defined interaction patterns, created wireframes, obtained stakeholder approvals, wrote UX requirements, and validated the feature.
I collaborated with the Program Chief Engineer, Lead System Engineer, Lead Architecture Engineer, and the software implementation team.
Vehicle testing began within 4 months
The need for a new HMI wasn’t identified until 6 months before the new buses were scheduled to ship. The need to quickly deliver new design requirements, that were simple to implement, was a top priority for program management.
I worked cross-functionally to understand identified use cases and refined them in terms of scenarios where drivers should receive feedback. I made concepts for the strategy and worked the with Lead System Engineer to define feasible notification trigger conditions.
I was able to present this concept to the program team and receive buy-in to pivot their proposed HMI solution and implement 8 new pop-ups to expand upon the previous system. Within 4 months of initial discussions with engineering we validated the HMI implementation in a school bus, at our proving grounds. This complete feature was ready to ship ahead of the scheduled program launch.
This control doesn't latch, so the switch will continue functioning normally without any driver action.
The warning severity is minimized by having the notification time out after 5 seconds and not having an audible alert.
Momentary Switch
Two-Position Switch
This control latches which can result in a disconnect between the switch state and the door position (switch latched to open while doors remain closed). The driver will need to return the switch to the closed position before they can request a door open again.
The warning severity is increased by having the notification present until the switch position is corrected or the driver acknowledges it and having an audible beep at the onset.
Due to regulations, school buses offer two types of door controls
This means that in some scenarios, the required driver action varies based on the control types. This example shows how the use cases were divided to provide an escalated warning when driver action is required. If the driver requests the doors to open while the vehicle is in motion the doors will remain closed and a driver notification will be provided.
Proposed HMI strategy was challenged by stakeholders
Due to timing, program management challenged the need to include additional notifications. My initial proposal was more complicated than anticipated by the program, however I was able to pivot the strategy after explaining the value of each notification based on differences between use cases.
I walked through the use cases and iterated the concepts together with the systems, architecture, and software leads. This allowed us to align on technically feasible solution for warnings based on use cases. Having this strong consensus prepared us to persuade the program team to invest in our solution.
Documenting and publishing HMI requirements
After getting stakeholder buy-in, I created a table to document the 9 use cases and define the 10 related driver notifications in a clear and concise manner. This table was published in our formal requirement development tool and cascaded to the involved teams.
Vehicle testing led to a verbiage update
During the vehicle testing we better understood the use case for when the door motor overheats. I documented, in Figma, the changes to the use case and lead a discussion with the HMI team. After tweaking the proposals we settled on replacing the implemented pop-up with the boxed option. I update requirements with this change and released a new revision.
Stakeholders appreciated the implemented HMI strategy
The Program Chief Engineer was pleased with the HMI during a test drive evaluation for each of the use cases. He noted his appreciation that the technical teams persuaded program leadership to implement the more comprehensive solution.
Project Takeaways
Program scope often proposes solutions, but the HMI team has the ability to add value for customers by identifying the needs that the initial "solutions" are aiming to solve and then designing solutions that align with our existing interaction patterns.
Finding a balance with the technical teams is key, we can argue back and forth but when we need external buy-in its critical to be aligned and supportive.
Ability to articulate the reasons behind nuances in designs can lead to significantly improved designs. Without clear justifications from the start complex designs will be challenged extensively.
If I had the chance to change these notifications, I would reconsider the use of colors. Potentially some of these notifications should be amber or white instead of red due to less criticality.