ECOMPLIANCE  |  10 MIN READ

Redesigning the eCompliance app to encourage front line participation in safety culture

Role

  • Product Design Intern

Project Type

  • Mobile App Redesign (MVP)
  • Alpha Launch

Tools Used

  • Sketch, Zeplin, InVision
  • Maze, Usertesting.com, Lookback.io

Team

  • Cat - Senior Product Designer
  • Harish - Director of Product
  • Quadri - Product Manager
  • Ivan - Manager of Data & Insights
  • Kasi - Mobile Developer
  • Chris - Mobile Developer

Duration

  • May 2019 – Aug 2019 (4 months)
OVERVIEW

Building a high participation safety culture through the redesign of the eCompliance mobile app

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 👇

News Feed

Empowering the workforce to take safety into their own hands — holding each other accountable, promoting transparency, and recognizing each other’s efforts.

📌
Real-time safety updates
📌
Relevant news related to safety on your team/site
📌
Transparent view into safety within the company

Safety Dashboard

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.

📌
Team and individual leaderboards
📌
Safety contribution data visualizations
📌
360 view of safety performance

Hazard Reporting

Simplifying the reporting process to encourage front line workers to report unsafe work practices in just three simple steps.

📌
3 step hazard reporting
📌
Built in camera annotation
📌
Push notifications for immediate resolutions
RESPONSIBILITIES

Contributing across the various stages of our product's lifecycle

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.

Product Strategy

🤔
📌
Defining potential solutions
📌
Understanding customers
📌
Defining UX success metrics
📌
Assisting in facilitation design sprints

User Research

🔍
📌
Synthesizing existing data and research
📌
Conducting interviews with users/stakeholders
📌
Setting up and conducting moderated/unmoderated testing with clients/users

UX Design

✏️
📌
Sketching/wireframing concepts
📌
Facilitating brainstorming/ideation workshops
📌
Analyzing test results and finding key themes/insights

UI Design

🎨
📌
Leading the visual design approach for the app
📌
Creating prototypes to test with participants
📌
Handing off designs with developers
DESIGN PROCESS

Taking a human-centered approach to involve clients and workers every step of the way

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:

Challenge #1

“How might we encourage front line workers to regularly report hazards, observations, near misses, and incidents?”

Scroll to section
Challenge #2

“How might we simplify reporting of meaningful data in order to encourage participation amongst front line workers?”

Scroll to section
⛔  Disclaimer

The following generative research and personas were done prior to when I joined the team. I’ve included them in the case study for context, however this work was done by Cat (Sr. Product Designer), not me. Just wanted to make that clear! You may now continue reading :)

GENERATIVE RESEARCH

Gaining a new perspective on safety by talking to front line workers directly

Before 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.

Key Findings

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?”

Productivity / Inconvenience

“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.”

Shame / Embarrassment / Pride / Ego

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.”

Peer Pressure

“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.”

PERSONAS

Creating a visual representation of the people we’re designing for

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.

Worker Wally
Contractor
Summary
📌
Reports to Supervisor Sally
📌
Just trying to get the job done with minimal disruption
📌
Finds paperwork gets in the way when working
📌
Sees a lot of unsafe acts but keeps it to himself
Foreman Fred
Skilled Labourer
Summary
📌
Reports to Supervisor Sally
📌
Wants to meet deadlines and keep himself/his crew safe
📌
Would like to spend less time on safety tasks and more on production
📌
Leads by example and reports unsafe acts
Supervisor Sally
Site Supervisor
Summary
📌
Reports to Process Paul & Bill Safely
📌
Ensures the team fills out paperwork, is ready for work and is getting the job done
📌
Directly responsible for safety on site
📌
Takes a proactive approach to ensure safety on-site
CHALLENGE #1

How might we...

encourage front-line workers to regularly report hazards, observations, near misses, and incidents?

DESIGN SPRINT #1

Hitting the ground running mid-sprint to deliver some fresh ideas for the eCompliance app

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?”

USER FLOWS

Taking the existing flow and finding opportunities for improvement

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.

Existing Reporting Flow

Worker Wally sees an unsafe activity and submits a hazard report using the eCompliance app

NEW Reporting Flow

Worker Wally sees an unsafe activity and submits a hazard report using the NEW eCompliance app

User Flow Sketches
CONCEPT TESTING

Exploring concepts with clients and workers to ensure we were heading in the right direction

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.

GOAL #1

Test whether the concept of goals as gamification is worth pursuing

GOAL #2

Determine whether points and/or streaks are a motivating incentive to encourage participation

AFFINITY MAPPING

Gathering our test results and determining our key findings

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.

Key Findings

Gamification Methods

📌
Preference towards points
📌
Clients liked the idea of creating a sense of competition between sites
📌
Some mentioned “bragging rights” is motivation enough and an incentive isn’t needed
Key Findings

Reporting Hazards

📌
Workers often send photos with no description or explanation which makes it difficult for supervisors to assess the hazard
📌
Save as draft would be helpful when working on a site where photos are not allowed (offline mode)
📌
Scrolling to complete the form made it feel long and demotivating
Key Findings

Supervisor Acknowledgement

📌
Workers appreciated having their report acknowledged by a supervisor, even if it was just a thumbs up
📌
Read receipts were concerning for supervisors considering the fact that reports lower in severity don’t always get resolved immediately
📌
Supervisors didn’t want read receipts making employees to feel discouraged from participating
CHALLENGE #2

How might we...

simplify reporting of meaningful data in order to encourage participation amongst front line workers?

DESIGN SPRINT #2

Diving deeper into the hazard reporting flow to simplify the process for front line workers

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.

FACILITATING THE SPRINT

Collaborating to find new solutions for the reporting flow

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.

Problem Statement

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

Success Metrics

Submit a report within 1–2 minutes

Submit a report at least 2–3 times a day

FACILITATING THE SPRINT

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

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.

Problem Statement

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

Success Metrics

Submit a report within 1–2 minutes

Submit a report at least 2–3 times a day

USER FLOWS

Understanding the entire reporting experience from beginning to end

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.

Flow #1

Worker Wally Reports a Hazard

Flow #2

Supervisor Sally Receives a Hazard

Flow #3

Worker Wally Reviews Changes

User Flow Sketches
CONCEPT & USABILITY TESTING

Reconnecting with test participants to present our new concepts and redesigned reporting flow

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:

GOAL #1

Test whether the report a hazard flow is intuitive and easy to use

GOAL #2

Determine whether clients would be open to this solution for quick hazard reporting

PROTOTYPE

Designing a prototype to present with clients and workers

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.

Task #1 - Worker Perspective

"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.

Task #2 - Supervisor Perspective

"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.

Task #3 - Worker Perspective

"You've received an in-app notification indicating your report has been edited."

Navigate to the notification and view what changes have been made.

GATHERING INSIGHTS

Synthesizing our test results across multiple tests

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.

Key Findings

Reporting Flow

📌
Average time to submit: 1:21 minutes
📌
Clients need to be able to customize these reports according to government requirements (ie. some reports need a signature)
📌
Offline mode has to be explored as some workers are not allowed to have their phones on site
Key Findings

Gamification Methods

📌
System of rewarding points for tasks seemed to be “trivializing safety”
📌
Tracking and gamifying participation was a preferred method of motivation amongst workers
📌
Participation insights in the form of a dashboard would promote safety transparency amongst both workers and supervisors
Key Findings

News Feed

📌
Likes/comments needed further testing and exploration with a focus on moderation before releasing to public
📌
Having roles/permissions was required to have a notification system that notified the correct supervisors based on location/team
FINAL DESIGNS

Putting together the final touches for the alpha version of the app

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.

THE RESULTS

Contributing to the next steps before the end of my internship

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.

UX METRICS

Using Google's HEART framework to measure the UX of our 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.

Goals

🎯
📌
For workers to feel empowered, educated, and motivated to participate in safety and improve safety culture
📌
For workers to feel like the app is easy to use

Signals

🚨
📌
Responding to surveys
📌
Leaving 5 star ratings
📌
Leaving user feedback

Metrics

📊
📌
Net Promoter Score
📌
Customer satisfaction rating
📌
Number of 5 star reviews

Goals

🎯
📌
For workers to use the new reporting flow to submit hazard reports
📌
For workers to use the news feed to digest information
📌
For workers to use the dashboard to monitor their safety participation

Signals

🚨
📌
Submitting a hazard report
📌
Tapping on the news feed tab
📌
Expanding feed card to view content
📌
Tapping on the dashboard tab

Metrics

📊
📌
# of workers who have submitted a hazard report / total workers
📌
# of workers who click into the news feed tab / total workers
📌
# of workers who expand a feed card / total workers
📌
# of workers who click into the dashboard tab / total workers

Goals

🎯
📌
Workers are coming back to the app to consume information from the feed
📌
Workers are coming back to the app to complete a hazard report
📌
Workers are coming back to the app to review their safety dashboard

Signals

🚨
📌
Worker opens the app daily
📌
Workers are staying active in the app (viewing content, submitting reports, etc)

Metrics

📊
📌
% of total workers using the app more than 3-5 times a week
📌
Avg time spent in app
📌
% of total users entering the app through notifications or directly
📌
% of users opening the app to submit a report
📌
% of users opening the app but not submitting a report (assumes they are consuming feed or dashboard content)

Goals

🎯
📌
Workers are submitting a hazard report within 1–2 minutes

Signals

🚨
📌
Worker reports and submits a hazard report

Metrics

📊
📌
Avg duration to submit a hazard report
📌
% of hazards being completed under 2 minutes
KEY LEARNINGS

Reflecting on my process, the project outcome, and how I’ve grown in this role

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.

What went well...

Including our workers and clients in our design process

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.

Rapid prototyping helped us move quickly through iterations

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.

Strategically prioritized the core functions of the app

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.

What I’d do differently...

Break up the reporting a hazard steps even further

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.

Keep the amount of testers at a maximum of 5-7 participants

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.

Ready for more? ✨

Scroll to top icon