Context

Those clients (sponsors/PEOs) who use PrismHR can have the function to synchronize the data between Prism and our database automatically. However, sometimes, sync errors happen on some 401(k) participants, and our current process and the hotfix cannot solve this problem.

Current Solution

Developers receive error notification → Developers tell PM → PM contact our client (PEOs) and remind them to fix it

Hotfix

Developers receive error notification → Automatically send the emails with sync error data to remind clients to fix it

Problems

Understand Problems

# 1: Trackability

Users (PEOs) don’t have any way to track the error records except via email search.

# 2: Scalability

In the long run, this solution can’t efficiently support large PEO clients.

Problem Statement

How do we automate the process and make it scalable?

User Tasks

I started by listing out what user tasks need to be done to evaluate different solutions.

1. Resolve error items

  • Users used to resolve daily need to see today's unresolved errors.
  • Users used to resolve many errors across many days at once need to see all records sorted by date.

2. Mistakenly mark items as resolved

  • Accidentally hit the resolve button, so they need to revert.

3. Check history

  • One participant's contribution has a problem, so they need to see this participant's past changes.
  • Other reasons.

Proposed Solution

Build on Current Structure

We currently use the product DataBridge to communicate with clients about all the participants’ contribution changes. This product serves clients who don’t have API integration. For another group of users who use API integration, we need to give them a new DataBridge to complete their tasks. The following solutions are built on the current DataBridge.

Current DataBridge for clients who don’t have API integration. The Daily Changes tab has two layers: data is grouped by the Sent Date, while the All Records tab contains all data that allows users to search for a particular record.

Consideration

# 1

Leverage the current structure: Daily (two layers, group by date, only error) + All (one layer)

  • Task 1-1: Use Daily. Mark after solve.
  • Task 1-2: Use All. Mark after solve.
  • Task 2: Use Daily. Won't disappear after solve.
  • Task 3: Use All. Search participant & filter date. (Use Daily select date.)

Two-layer structure groups data by date that is beneficial to users who solve errors everyday.

# 2

Use a new structure: API (one layer, only error) + All (one layer)

  • Task 1-1: Use API. Move to resolve tab when solve
  • Task 1-2: Use API. Move to resolve tab when solve
  • Task 2: Use API. check the resolve tab
  • Task 3: Use All. Search participant & filter date.

One layer structure is useful for users that prefer to solve errors all at once.

# 3

Have three tabs: Daily + All + API

  • Redundant because each task has two ways to complete the task

Compare Solution 1 and 2

To those API users, their main task is to focus on those error records. If users can quickly locate error records, they can complete tasks earlier. The second solution, having a one-layer structure, is a better way to fulfill the needs, while the current structure forces users to have one more click to go into the daily group and unpack those Sync-error records.

Design and Revision

Status Location on History

original

On the most right

Follow the convention to make the frontend dev easier to develop, but it is hidden on a smaller screen.

Revised

#1: On the most left

Difficult for the frontend dev to work on it because the table component has been built without the tag on the left.

#2: Pin to the right

The final solution is that users can always see the status with low dev effort.

Actions on History

original

Can move to resolve or error in History

This provides flexibility to users to solve status in History, but this causes two problems.

  • History is a place for “view-only,” and the flexibility contradicts the definition.
  • The dev team needs to put more effort into implementing a set of rules that we can only display the action “Move to error” when there are only solved items. If users select multiple items, including error and resolve, users will only see “Export.”

Revised

Don’t allow to change status and train users to use the Error and Resolved tab as their major location of completing the error-solving task.

Error Reason Location

original

One line

Directly displayed it, but not easy to read.

Revised

Two lines (expand/collapse)

  • Create a separate row for other data points, including the error reason and default as expand so that you can still directly see them.
  • Since the dev team requires us to include the email sent out time and the Error ID to better identify each error when users ask for help, I need more space for that information. Thus, a second line is a better way to do so.

Learning

Focus can shift

The design for the product was approved by the stakeholders and it was included in the roadmap. However, the product was put on hold for some time as the leadership decided to prioritize the development of a CSV report that could be downloaded by users. As this only required the involvement of the backend team, the frontend resources were utilized for other pressing projects that could generate more business value. After a pause of three months, the project was restarted with a new development team consisting of 50 people based in India.

Make peers’ life easier

As a UX designer, user experience should be one of my priorities. However, as a product designer, I need to find a balance between thinking about how to make the design easy to implement and not sacrificing usability.

Copyright © Shih-Tsai Wei 2024