Putting the safety of teammates at the forefront
In high-risk, on-site work environments you can’t always keep an eye on everyone. To limit safety incidents, we worked to create a safety dashboard that would help monitor any workers on it, communicate with them easily and handle emergency situations swiftly.
For example, what about the scare floor of Monsters Inc., in Monstropolis? With all of its child-alerts, how might we create a system that helps keep a track of all of its scarers to keep them safe?
This case study is based on a client project that I cannot share fully under a NDA. While it accurately shows my design process it has been modified to omit any data or details on the content and the designs have been altered to allow sharing of my work. In an individual interview I can elaborate my involvement in more detail.
Role
Lead Designer —
Discovery, UX Research, Design, Prototyping, User Testing, QA, Requirements & Strategy
Team
Business Team (PO, PM, BAs, Client Rep.,
Technical Advisor)
Development Team (FE, BE, QA)
Overview
A safety app to track field workers in high risk environments on site and communicate alerts to minimize safety risks
The Problem
In the past, there had been numerous high-risk issues on work sites that resulted in near-fatal accidents. Some incidents were due to workers being out in areas alone with no support, lack of quick communication when critical events are near (weather events, utility issues, etc.), and delayed emergency support when incidents happened.
The goal was to create an app that allows managers to monitor locations of users within a set geographical area that is deemed high risk, communicate high-priority messages, track incidents and quickly dispatch emergency response when needed. This project was aimed at decreasing risk to all workers on site to build a safe environment for all.
Because the project had to do with the safety and well being of users there was very little room for error. Additionally, the devices assigned to the users had its own set of restrictions we had to work around. The requirements and asks from the users and business continued to change so adapting pieces of the product to function properly
The Approach
Discovery
To start, there was existing work done prior with a different team to POC the tracking technology. Design discovery included reading up on previously done work and getting familiar with the new technology, establishing relationships and contacts with the user group, setting cadence with the BAs who would work closely between the users and myself, start initial contact gathering on the pilot site and users and use this information to write requirements to set up user stories.
Design
With a short timeline, we jumped straight into building screens and interactions
Wireframe: Overall tool structure and layout, especially since we knew early on that this product would need to be optimized for tablet for a secondary user group
Styles & Design Systems: I used a mix of internal and Material design components so needed to build out and organize a design system to use (done in consultation with the developers to ensure effective development time)
Design: Once wireframes were reviewed by the larger team, I designed individual screens for all cases and instances. We followed a fairly straight forward agile cadence and as the only designer, I not only worked on the designs but was deeply embedded in UX reviews, requirement validation sessions with the BAs and reviewing the testing of acceptance criteria. The main principle to follow was intuitive use and ease of navigation.
Prototype: To ensure accurate and comfortable showcase of the designs, we prototyped each functionality, including all actions and states
Iterate: Feedback from business team > update designs > approval > feedback and questions from development team > design notes for handoff
Testing (QA and Users)
Assist QA team is product testing prior to release. Additionally ran user testing sessions (moderated/unmoderated, remote, qualitative) with different user groups, gathered feedback and synthesized to future stories.
Iterate
Based on the feedback and changing business requirements (including scaling product due to high demand) we continued to grow our tool.
The Outcome
Creating Geo-Fence Areas for Monitoring
Write, Save and Send Messages to Users
In event of emergency, audio and visual alerts show on the screen, allows monitoring of all monster locations and track EMT dispatch
The Results
The client team was very satisfied with the product and we had great feedback and reactions during user testing. We started with 1 initial pilot site and ended up planning for roll-out in 5+ sites by MVP launch. The team also won runner-up in a company-wide award for good product build and safety enhancements.
“Having [this tool] would make me feel like I wasn’t alone, like someone was watching my back”
— User after testing
If I were to do it again..
Lessons Learned
Regulatory requirements & cultural details for a global product. This was the first safety product I worked on that was truly global. Regional regulations for each site as well as social and cultural considerations was something I had not worked with before and proved a unique learning curve
Proper QA. This was also the first project I worked as closely with the QA team on, so learning how to do testing and debugging with the development team was helpful to learn what specifically to keep in mind when designing in the future.
What would I do differently?
Better requirement gathering. I didn’t get access to the users till later in the project, would request for more feedback/research time early on
Better tracking post-launch. Per standard procedure, once our product was adopted the development, growth and management we weren’t able to track usage, feedback or painpoints. I would like to be able to manage products for a longer period of time post-launch to be able to track metrics and feedback and work on continuous improvement plans.