As part of the product team at eCompliance, I worked on the redesign of their mobile app with a focus on the front line worker’s experience as it relates to safety in the workplace. Participation plays a huge role in safety, so we set out to:
“Provide a platform that empowers, educates, and motivates employees to participate in safety and improve safety culture.”
Here’s what we came up with 👇
Empowering the workforce to take safety into their own hands — holding each other accountable, promoting transparency, and recognizing each other’s efforts.
Introducing gamification to motivate front line workers to participate in safety while educating them on how they make an impact on the lives of their coworkers.
Simplifying the reporting process to encourage front line workers to report unsafe work practices in just three simple steps.
As the Product Design Intern, I was fortunate enough to play a role in the entire lifecycle of the product from strategy to research and later design.
To get to the solutions above we followed a design process that included our front line workers and clients as a key part of the decision-making process. We relied on research, data, and interviews to validate any assumptions and regularly presented concepts to clients for feedback.
At a high level, our process looked like the diagram below. We would often go back and forth between stages, yet always made sure to test our concepts before moving forward.
The following case study will walk you through how we used this process to tackle the following two challenges:
“How might we encourage front line workers to regularly report hazards, observations, near misses, and incidents?”
Scroll to section“How might we simplify reporting of meaningful data in order to encourage participation amongst front line workers?”
Scroll to sectionBefore we were able to determine the challenges we’d be tackling, we needed to understand exactly what was the root cause of a lack of participation amongst front line workers when it comes to safety.
Workers observe 4-5 or more hazards a day
Minor incidents at work are happening daily
Major incidents at work happen less frequently
“Why are workers not reporting the small stuff?”
“They tell us that small cuts and stuff have to be reported, but that would slow down production. You can’t produce with that kinda of stuff getting in the way.”
“My own mistake, I wouldn’t report. Unless I really got injured by my own mistake, which has happened.”
“We’re 97% men out in the field, so we try to act tough.”
“You can’t report it because it causes too much tension between groups of people at work. There’s a lot of drama. You don’t want to bash other trades”
“You don’t want to say too much. You don’t want to piss them off. I wouldn’t go above their heads to report it. I wouldn’t rat them out, unless I see that what they’re doing could cause injury to someone else.”
The following personas represent the main user types that we considered while carrying out this redesign. Each of these were made from interviews done through guerrilla research methods.
By the time I joined the team at eCompliance they had already started their first design sprint for the new project. Research, brainstorming sessions, and many more workshops were held before this sprint, which led to many of the ideas that were explored during this sprint.
When I started, the problem had been set with a focus on reporting as it relates to safety. Being able to report observations, hazards, near misses, incidents, and more was the main functionality that front line workers used in the mobile app.
With reporting being our main priority, this design sprint revolved around the following statement:
“How might we encourage front-line workers to regularly report hazards, observations, near misses, and incidents?”
Part of the design sprint involved participants outlining the existing flow for reporting a hazard/observation/etc... to find the main problem areas that could be replaced or simplified. Below are the flows they came up with.
Worker Wally sees an unsafe activity and submits a hazard report using the eCompliance app
Worker Wally sees an unsafe activity and submits a hazard report using the NEW eCompliance app
I joined the team after the sprint was completed and was tasked with designing a prototype using the deliverables as a guide. We wanted to explore different concepts while still maintaining a similar goal, so me and Cat (Senior Product Designer) each made individual prototypes to test with our clients and front line workers.
The benefit of having two different prototypes when testing was that we received a variety of interesting insights regarding interaction patterns, concepts, and so much more. Using an affinity mapping exercise, we outlined some of our key findings.
With our new found insights, we decided to focus the second sprint on the reporting flow. When front line workers send reports, they can come in many forms: observations, audits, and much more. The time it took to complete these reports was long which often led to reports coming in with missing details that safety managers need to make accurate decisions.
We planned this sprint with more time allotted to prototyping and testing. We knew that the problem we were facing here was more complex compared to the first sprint and that recruiting clients to test this time around might be a challenge. While I worked on the prototype, Cat recruited and booked time with clients to test.
Working with the product team and colleagues from Marketing, Customer Service, and Engineering, we worked through various sprint activities to discover a new approach to our existing reporting flow.
Front line workers in high risk industries need to be able to report hazards and other safety observations in a timely manner to avoid possible injuries and encourage safe workplace practices
Submit a report within 1–2 minutes
Submit a report at least 2–3 times a day
Working with the product team and colleagues from Marketing, Customer Service, and Engineering, we worked through various sprint activities to discover a new approach to our existing reporting flow.
Front line workers in high risk industries need to be able to report hazards and other safety observations in a timely manner to avoid possible injuries and encourage safe workplace practices
Submit a report within 1–2 minutes
Submit a report at least 2–3 times a day
When trying to understand the entire reporting process, we discovered there was a lot of back and forth communication needed between workers and their supervisors.
Using a note and map exercise, we laid out the story and came up with the following user flows to represent how this communication works through the app.
Worker Wally Reports a Hazard
Supervisor Sally Receives a Hazard
Worker Wally Reviews Changes
The testing sessions we held with our first sprint were focused on presenting new concepts for our redesigned app. This time around, we introduced new concepts like our news feed, iterated on the reporting flow idea we presented the first time, and adjusted our approach to gamification. With this testing session, we had two goals:
In order to accurately test these prototypes, we created three tasks to go through based on our user flows. When presenting with clients, we went through all three tasks to get their feedback on the flow from a worker and supervisor perspective.
Using an unmoderated testing method, we invited front line workers to only go through task #1 and #3. This allowed us to measure the time they took to complete the task and focus their feedback based on how they'd interact with the app.
"While on the job, you've spotted an opening that has been left uncovered by a crew member that was working on-site the night before. You're 50 stories up and recognize that this can be a very serious hazard for others working in the area."
Use the app to report the hazard.
"You receive a notification letting you know Worker Wally has submitted a hazard report. You notice the hazard severity is higher than declared and should be attended to immediately."
Use the app to edit the severity to "High" and reward Wally for participating with extra points.
"You've received an in-app notification indicating your report has been edited."
Navigate to the notification and view what changes have been made.
After two weeks of testing, we went through our notes and collected some of our key findings. Using an affinity diagram, we were able to find some common feedback that informed our final designs.
After this testing period, we were in the final weeks of my internship. The project would continue beyond my time with the company, so before I left I delivered an iterated version of the prototypes above.
In this time we also worked on building the app with our development team. We followed an agile approach to build the app in weekly sprints.
Sometime after my internship ended, the team had planned to get some clients set up with the alpha version of the app. Unfortunately, I wasn't able to participate in that test as my internship had ended.
Before I left, I assisted in preparing for the alpha test by facilitating a workshop to determine how we'd measure the user experience of our new app.
Working with our Director of Product, Senior Product Designer, and Manager of Data & Insights, I ran a workshop to outline how we'd be measuring the UX of our app using Google's HEART framework.
Working as the Product Design Intern with eCompliance was an experience I'll never forget. It was my first role as a product designer after graduation. Jumping headfirst into a redesign project, I had some internal doubts regarding my competency level. With the help and support of my team, I was able to explore another side of product design that you don't get to experience when in school.
This was where I really grew my understanding of the business side of design, and the real impact design has on business objectives. It was from this experience that I was really able to grasp what it means to be a product designer and I continue to take these learnings with me throughout my career.
From beginning to end the process we took relied on the generative and evaluative research we did throughout the project. By involving our front line workers and clients directly, we were able to make well-informed design and product decisions.
My expert knowledge of Sketch and InVision allowed us to quickly go through different explorations with ease. I oftentimes designed live in meetings with developers to visually display our concepts in a way that was easy for everyone to review.
With only four months to design and build an MVP, we were well aware that we wouldn't be able to incorporate everything the existing app had. Breaking the problems into individual sprints allowed us to focus on effectively solving one problem before moving on to the next.
Looking back at the designs, I think there were definitely opportunities to simplify the reporting flow even further. Under time constraints I wasn't able to, but I would've liked to also test a version of the flow that broke the steps down even further to avoid the need to scroll.
Since we had more clients interested in participating, the testing period for our second sprint went beyond schedule. While the input was valuable, we found that we were receiving a lot of the same feedback. We later determined 5-7 participants to be the ideal amount of testers.
