top of page
Workers' Comp Cover.png

Workers' Compensation Dashboard

My project role:

Lead Product Designer + Researcher

Duration:

5 months

Platform:

Web app (Bootstrap)

Justworks

Redesigning a workflow dashboard for an internal Workers' Compensation insurance team.

1. Background

Justworks' main product is a B2B software for small businesses to help them manage payroll, benefits, HR, and compliance. Their target customer sizes range from 2 to several hundreds of employees.

 

One important piece of compliance that Justworks helps their customers with is management of Workers’ Compensation insurance, which is insurance covered by the employer in case employees are injured on the job.

​

The Workers’ Compensation dashboard is an internal tool used by the Workers’ Compensation team within Justworks to review and fix any errors related to Workers’ Compensation. Without fixing these errors, it would lead to inaccurate insurance coverage for employees, inaccurate billing charges to customers, and overall risk and loss of money for Justworks.

2. Why re-design this dashboard?

As part of the Growth team at Justworks, my team was working towards our quarterly OKRs :

1. Increasing internal team efficiency by reducing cycle time for major work functions by 10%, and

2. Reducing the number of Workers’ Compensation errors blocking payroll by 50%

  • In the first 6 months of 2021, over 40,000 errors were being manually addressed by the Workers’ Compensation team, with almost 500 of them happening before payroll ran every month (which led to highly stressful and last minute situations).

​

  • On average, it took a team member about 5 minutes to fix a single class code error.

3. Let's talk to our coworkers!

In order to get a better understanding of the existing ecosystem, I started the project by leading user research.

​

  • I wrote a research plan in Google Docs that included outlining the research goals, timeline, participant criteria, methodology, and interview questions.

​

  • Within my timeline, I also included Milestones for check-ins with various collaborators such as the Product Manager on the project and my design manager.

Screen Shot 2023-10-20 at 2.36.33 PM.png

To narrow our scope and help the team prioritize, I defined the research goals to focus on uncovering pain points and opportunities around the 2 tools the WC team used the most often: the error queue and experience of fixing a class code error. The reason why I focused on the latter is because missing class codes made up about 80% of all errors.

 

I interviewed 6 individuals from the Workers' Compensation team and asked them a series of exploratory questions, as well as asked them to screen share and walk me through some of their processes and tools.

Screen Shot 2023-10-20 at 2.33.39 PM.png

My coworker on the Workers' Compensation team walking me through how they use the current dashboard to fix an error.

4. Research synthesis & findings

After completing the 6 interviews, I compiled my notes and synthesized the findings using FigJam.

 

Based off of the quantity of notes as well as qualitative insights from how participants expressed how they felt about pain points, I started prioritizing the themes.

Screen Shot 2023-10-20 at 2.42.07 PM.png

Screenshots of my FigJam synthesis, where I used different colored sticky notes to represent categories such as quotes and themes.

Screen Shot 2023-10-20 at 2.42.18 PM.png

I wrote a research share out report in Confluence and Google Slides to share back with my project team, as well as presented more broadly at our monthly Product Engineering demo.

 

The 5 themes I outlined were:​

  1. The combinations of manual work + large volume of errors + frustrating tools meant the workflows wouldn’t be able to scale as the company grows.
     

  2. There are plenty of opportunities for small UI/UX improvements (such as bugs, linking through multiple pages, lack of live updating data = people might fix the same errors multiple times) that if we could fix many of them, would lead to improved quality of life for the team.
     

  3. Different customer use cases didn’t have explicitly built flows for them, leading to the team coming up with scrappy solutions (ex: a field that always requires a number input, but that number varies depending on the geographical state - for some states, the team just uses a placeholder number in the field).
     

  4. There are too many tools and platforms (at least 6 - Jira, Salesforce, Artex, Excel pricing tool, Redash, CS tools)! This leads to the team needing to jump around a lot in various tabs and windows in order to get even one thing done.
     

  5. A lot of existing knowledge around how to use tools or workflows was internal only, meaning teammates would just tell one another how to do things. This also wouldn’t be sustainable for scaling.

Screen Shot 2023-10-20 at 2.47.24 PM.png

Screenshot of my research findings documented in Confluence for cross-team and cross-company reference.

5. Co-creating designs

I kicked off the UI/UX design process by creating and leading a co-creation session with the project team, once again using FigJam.

 

Together, I led the team through exercises to review synthesis sticky notes and dot vote on what they thought would be most impactful work, which served as another level of prioritization. 

 

For our first focus, we prioritized fixing the various small but impactful UI/UX opportunities within the earlier outlined project scope of the error queue and missing class code error fix flow.

 

During this session, we also began to brainstorm ideas to address the UI/UX issues that were surfaced, for example “keeping users within the same flow without having to navigate to multiple pages”, which I was able to use to inform my designs for fixing a class code error.

Screen Shot 2023-10-20 at 2.54.06 PM.png
Screen Shot 2023-10-20 at 2.53.53 PM.png

Screenshots of the FigJam co-creation session template to review key opportunity areas, then brainstorm on them.

6. User flows

In addition to including my teammates in the design process, I also did some design thinking on my own, starting with analyzing the current high level user flow and creating a new, ideal user flow.

​

At a high level, the steps that my teammates on the Workers' Compensation team would currently take to fix a class code error would be:

​

  1. Log into internal tools

  2. Open error queue

  3. Click “Set class code” next to an error

  4. Enter diagnostic authorization

  5. Navigate to company-specific Workers’ Compensation page

  6. Scroll to find the error

  7. Fill out the “Class Code” field

  8. Navigate back to the error queue

Screen Shot 2023-10-20 at 2.57.31 PM.png

Screenshot of my FigJam documentation of the current screen flow someone would go through to fix an error.

Next, I created and proposed a new user flow, especially to cut down on users needing to navigate to multiple pages and tabs. One design decision I made at this point was to utilize a modal view. An outline of the proposed flow for a user:

​

  1. Log into internal tools

  2. Open error queue

  3. Click “Add class code” next to an error

  4. Class code modal opens up in the same view

  5. Fill out the “Class Code” field

  6. Click “Save”, modal closes and user is back in error queue view

Screen Shot 2023-10-20 at 2.57.56 PM.png

At this stage, I asked for async feedback from the Engineers on this project for early input on potential technical constraints and considerations, and reached out to our main stakeholder, the Director of Workers' Compensation Operations. All of the folks were able to review the design work done thus far (research share out, co-creation session, user flows) and provide comments in my design documentation.​

7. Lo-fidelity sketches

Now that I had a bunch of great ideas from the co-creation session and a basic user flow, I started hand sketching some initial designs.

 

In particular, I explored UI/UX like:

  • How to group errors, perhaps by payroll dates or error types

  • What kinds of granular data should be surfaced in the first level of hierarchy, versus within the secondary or following views

  • What kinds of content/data was helpful contextual information for the team in the modal view

​

In addition to hand sketches for the error queue and class code modal that was within our project scope, I spent a bit of time considering how the designs would scale.

 

For example, I explored mimicking the UI/UX patterns in the Workers’ Compensation page for each customer/company, or for fixing other errors that weren’t class code errors (for example, fixing a missing policy error).

Screen Shot 2023-10-20 at 3.59.44 PM.png

My hand sketched lo-fidelity wireframes, with annotations overlaid in FigJam. Also, using Post-it notes as dropdown menus!

Screen Shot 2023-10-20 at 4.00.32 PM.png

8. Getting more feedback!

At this stage I continued to share with the Product Manager and Director of Workers' Compensation Operations for their feedback (again, noted as sticky notes in these screenshots). I also shared my work with the broader Product Design team during our weekly design critiques for their feedback.

 

I made sure to document the questions and answers, as well as design decisions that were made in an ongoing design process Google Doc.

Screen Shot 2023-10-20 at 4.07.23 PM.png

Screenshot from bringing my designs to a Product Design weekly critique.

Screen Shot 2023-10-20 at 4.07.37 PM.png

Screenshot of my ongoing design process documentation Google Doc.

9. Mid-fidelity designs

Based off the feedback I was able to collect, I continued iterating in mid-fidelity, using some of our design system components to explore ideas.

 

In these mid-fidelity iterations of the error queue, I especially explored how to best visually group the information and more granular details like considering table sorting.

Screen Shot 2023-10-20 at 4.11.33 PM.png
Screen Shot 2023-10-20 at 4.11.23 PM.png

Two visual explorations of the dashboard home page.

For the class code modal, several iterations included exploring:

  • What data to include, and how to visually group/separate them

  • Which fields/actions did the WC team exactly need to fill out

 

For example, I explored using the horizontal divider to separate between company V. employee details, or required V. additional fields.

Screen Shot 2023-10-20 at 4.12.00 PM.png
Screen Shot 2023-10-20 at 4.11.45 PM.png
Screen Shot 2023-10-20 at 4.11.52 PM.png

Three explorations of the error fix modal.

10. Final designs

To highlight the difference, I included some comparison screenshots of the old V. new designs.

Old error queue home page

Screen Shot 2023-10-20 at 4.18.52 PM.png

New error queue home page

Screen Shot 2023-10-20 at 4.19.03 PM.png

Old class code error fix

Screen Shot 2023-10-20 at 4.19.26 PM.png

New class code error fix

Screen Shot 2023-10-20 at 4.19.40 PM.png

11. Hand-off and follow-through

Once I completed final designs, I handed off designs to Engineering through an organized Figma page that outlined each screen along with the flows. I added text annotations to explain interactions or additional details as needed.

 

I also worked with Engineering and the Product Manager to translate design work into Engineering work to track in our team Jira board, and provided Engineering support along the way (answering questions over Slack, adding additional design clarity in Figma).

Screen Shot 2023-10-20 at 5.44.32 PM.png

In addition to handing off designs to Engineering, I demo’d the new designs to the Workers' Compensation team and helped set up a Slack channel to continue monitoring for qualitative feedback and bugs. The project team was also able to utilize the initially set up dashboard to track metrics.

 

Even as we were working towards our MVP launch, I worked with the Product Manager to identify features to improve upon next, including displaying all 4 types of errors (not just class codes) along with the flows and designs needed to fix them.

12. Reflections

We were able to launch the Beta error queue and modal in November 2021, 5 months after kicking off the project. Since the Beta launch, our Engineers and Product Manager have continued to check in on metrics periodically and report back on any issues. We also have a Slack channel dedicated to gathering feedback or requests from the WC team as well.

 

Overall in reflecting on the project, what went well was the cross-functional collaboration throughout the process, from the team support during user research to the co-creation session. I also think I had early and often conversations with the PM and Eng on technical constraints and scope to ensure we were building plausible and scalable products.

 

In terms of improvements for next time, I would like to advocate for better accessibility as always and making sure scope cuts get prioritized. 

bottom of page