David Hirotsu

ADD Employee: Helping users to help themselves

About Onboard by HR Cloud

HR Cloud is a Human Resource Management System Saas software company, and Onboard is their flagship application. The biggest advantage to using HR Cloud's Onboard versus competitor solutions is that Onboard automatically triggers complex workflows and custom checklists from pre-determined fields on the Employee Profile when you add the employee (referred to as “Add Employee"). The checklists are composed of tasks to simplify onboarding responsibilities such as filling out Forms (I-9, W-2, W-4, WOTC.), watching training videos, assigning assets, approval workflows, as well as integrations for background checks, payroll account creation, etc.

Any field, such as "Department", that is used to trigger checklists, is called a smart field and an input is subsequently required during the “Add Employee” flow for new user activation. The fields on the employee profile (internally referred to as the “Employee Custom Object") are able to be customized with new data fields (T-shirt size), an API field such as payroll information fields for (direct integrations), made required, or trigger a workflow with subsequent fields exposed based on an initial choice.

HR Admins, HR Operations and HR Users (collectively known as the users) work with our internal Customer Success and Account Management teams to customize their account during the implementation process. Competitor systems are predominantly manual, using a wizard process to manually modify a new hires onboarding checklists. Our tenants with the highest renewal rates tend to have multiple complex checklists as it saves them much time and hassle compared to other systems that require a manual wizard process for each employee added to the system.

My Role AND TEAM:

As the design lead on this project, I worked closely with the Customer Success Manager Ryan G. and Onboard's Product Owner Franka S. to help uncover the customers pain points while considering the technological constraints. The core team for the project was the three of us and a jr. UI designer Nika T. who I brought on for the middle phase to get some rapid prototyping and user testing exposure. For understanding technical constraints, I also worked closely with my manager, the CTO Krishna S., as well as occasional questions for developer leads across teams, including front-end developers, backend engineers as well as the API's team.

Interfacing with these roles were critical in providing deep context of the customers pain points, as well as providing feedback on which solutions amongst the multiple generated were both feasible and reasonable for development.

I was involved end-to-end in this project, from discovery to production. I discovered the problem with the Customer Success Manager, defined the projects goals, held workshops for low fidelity mapping and card sorting, collaborated on lo and hi-fidelity prototypes, and then solely owned that project from final UI through to design QA and onto production after it was developed.

Identifying Pain points: 

Adding an employee to trigger multiple checklists is the main experience for the Admins using HR Cloud’s flagship Onboard application. The Customer Success Manager would often share information on various product calls regarding the pain points of our users from support tickets generated. We quickly noticed a pattern that (sorry, NDA)% of tickets pertained to issues stemming from this new account creation experience.

When we spoke with the head of Customer Success, they said the users found the existing flow was too confusing for users, cumbersome and error prone. They had issues with the wrong tasks being triggered, and had lost confidence in the reliability of the system. They also were very frustrated by the many error warnings they would get by inputting certain information incorrectly. I identified and consolidated the main problems of these frustrations during a UX audit, and presented them to the team as goal posts for our redesign:

Problem #1. Confusing UX Writing - Unhelpful 'Helper Text’: There were many moments along the experience that contained application specific language that was not representative of how HR Admins thought about employee records. To help users, we offer several one-on-one training sessions and help center articles to read through during implementation in order for them to understand this system. This didn't change how difficult the system was to use, and it was a growing issue as our customers hired new HR employees on their team to use the system.

For example, when adding any new user, HR Admins were first prompted to choose from: “Add Employee with Details”, and “Add Pre-Hire Employee”. Clear and simple UX writing in familiar language would greatly reduce confusion at many points in the flow.

Goal #1: Simplify language, give helpful context for the user in their own domain specific language.

Problem #2. Low Visibility of System Status - Lack of System Feedback and Credibility: The implementations team handles the setting up of complex workflows that trigger from input criteria on the Employee Object. Even experienced HR admin users did not understand how these tasks were being triggered in correspondence with which assignment criteria within the employee form fields during “Add Employee". It was even worse for new HR Users to the team.

The systems correlation in terms of required fields for each employee add type was not clear, and produced errors such as the one shown above: In this example, the “Employee Number” field being conditionally required on a specific “Add Employee” type chosen in the first step is not clear until after the error is triggered.

Upon Saving an Employee Form, users were taken back to their starting point without any confirmation or summary until after the new user account is already added to the system. This forces the user to memorize what conditional fields trigger what checklists, and many users found themselves diving into the employees profile to check that the correct tasks were triggered and to add “ad-hoc” tasks.

Goal #2: Give users confidence in the system through improved feedback and confirmation dialogues. Increase visibility of system changes particularly when important events such as tasks are queued to trigger.

Problem #3. Exposure of Meaningless Yet Consequential Information: There were many required fields on the Employee Profile field. The majority of them were pre-defaulted by some field, and unless modified in a highly specific order, would trigger an error message when trying to save them.

Statuses were particularly confusing to users. When we interviewed actual users, many of them did not know what these statuses did. They were only familiar with “Employment Status” which is a familiar HR term. The other two correlated to the users record in the system, and caused more problems without any valid use cases.

In addition to these Status fields, the following fields were all required by default: First Name, Last Name, Email, Start Date, Employee Number, Position, Department, and Location. This was problematic and excessive as some customers (SMBs) didn't have clear cut Departments in their company, or multiple locations. It was making them jump through hard coded hurdles in the system to have these fields all required by default for all tenants.

Goal #3: Reduce the number of required fields, including simplification of statuses.

Mapping the Complexities:

- First I created a flow map of the current system. Looks very simple on paper, and thus lies some core issues. If a user selects one Add Type versus another due to the confusing language, they will have to exit the form, and then start all over. 

- To understand the use cases of creating a new user, I relied heavily on CS at this point to find out all the main edge cases for this feature. I also had them ask follow up questions to our main customers (especially those with particularly complex checklists or integrations), and did deep dives into the product myself to find those edge cases. I then identified three main use cases of this flow for the team to tackle (the fourth was deemed out of scope by stakeholders).

• Case A: HR Admins adds a new employee, with a future start date to use Onboard application. Wants to review Onboarding tasks.

• Case B: Add an employee for pre-boarding to finish tasks. Once finished, and approved, they are moved into normal Onboarding.

  • Common when running background checks or other tasks before Onboarding.

• Case C: Add an old employee, just to have their record in their system. Admin does not want to have onboard tasks assigned. Common when moving employees (both previous and current) from a former system.

  • Adding ad-hoc tasks at this stage (optional).

• Case D: Import (group add). Deemed out of scope by stakeholders.

Cases C and D were not possible to do in our current system. Case D was decided as out of scope for this phase.

With these three use cases in mind, I worked on several iterations of the new proposed flow. I worked closely with the Product team, technical leads and developers to meet the specific feature requirements we defined together in defining the customers problems. I white-boarded and sketched out a number of potential solutions, and used weighted points based on discussion to decide which solution was best.

Here is the final flow we landed on, which gave us great direction for prototypes:

Prototypes and Testing (A/B/C)

At this point, we had a strong foundational flow to create multiple variations of prototypes. I pulled in a Jr. Product Designer at this point, to participate in two parts of this stage, Card Sorting to re organize and reduce the complexity of the Employee Profile, and creating clickable prototypes. We worked closely together every day despite being located halfway across the world.

Through Nika and the rest of the teams contribution, we were able to re-organize the employee profiles default field into more relatable groupings and naming conventions for the HR Admin.

After sketching out dozens of approaches, we landed on three in collaboration with the Product Team.

• Wizard version (good for walking the user through a step by step process, must view tasks each time)

  • Pros: Harder to get lost.

  • Cons: Must view tasks, even if you are a super user who knows your checklists well.

• Tabbed approach (with optional ability to view tasks)

  • Pros: Hides Complexity

  • Cons: Might hide important sections

• Long Scroll approach (with optional ability to view tasks)

  • Pros: Makes everything viewable, collapsible cards make it not as long as before.

  • Cons: Tedious to scroll through

This was a high-risk area to tackle as every single account at the company's HR Team users rely on this feature almost more than any other flow in the entire HR Cloud ecosystem. Because of this high risk, we were able to petition for time and resources to test this extensively.

We then tested out to of these chosen designs with customers feedback against our existing version.

In order to stay impartial, I wrote a Interview Framework with walkthrough scenarios for our Account Managers to conduct with the users on designs behalf. Small details such as the naming conventions of the prototypes had to be carefully chosen to not introduce any implicit bias.

User Testing and Interviews: After 5 customers tested the software, we had enough information to continue with one of the designs.

The issue with the wizard was that users who liked our system as-is, found this new step by step process tedious. A good chunk of users who were very familiar with their checklists simply wanted to add the required fields and move on. Wizard, out.

Surprising Discoveries: The tabbed approach was fairing very well in the experiments. We thought for a little while that the 'Tabbed Concept, may be our winner. However, there was a power user who when following the steps in our interview, used “Command+F” on the mac to use the browsers find function to quickly access a specific field in the form on the existing version. By hiding things in tabs, she was no longer able to find the field she wanted. Tabbed version now had a big drawback as opposed to the long scroll.

A New Approach to a Familiar Layout: While the long scroll was the least ‘exciting’ of re-design concepts, it was the best compromise of usability, optimal quickness amongst all use cases, and most familiar when we collected user feedback. I thought hard about the long scroll issue, and proposed a new interaction pattern in our system, side bar tabs to access anchor links within the profile. With a quick prototype in hand, we retested the interaction and it faired very well amongst our testers.

This solved the long scroll concepts drawback of hard to find fields, while preserving all the positives of the experience. This was done by reclaiming the space unused to the left of the "Fly out” pattern overlay.

High Fidelity Mockups:

After the team could sense the excited of the users on the new redesign, we moved forward with polishing up the Hi-Fidelity prototype to vet across the company. Here are some of the key screens below:

Test Out the Clickable Hi-Fidelity Prototype Here.

Biggest Improvements:

Goal #1: Easier to Understand and Use:

Users now choose checklists types they want to trigger as opposed to “Employee Add Types” like Add Employee with Details or Add Pre-Hire Employee. The card groupings on the employee profile are also more natural for HR Admins to understand as it better matches the mental model of Employee Profiles that Admins already had.

Goal #2: Improved System Feedback and Reduced Errors Related to Task Creation

Users can see how the fields they input generate tasks in real time. They also have the ability to audit tasks and delete them before adding the user to the system.

Feedback such as this above when filling out fields are incredibly helpful yet unobtrusive ways for users to understand how the system is working.

Goal # 3: Better Organization and Less Required Fields by Default.

Improved grouping names, (no more "Basic Info"), and collapsible cards make it a breeze to navigate through. Icons added visual anchors for users to more easily find fields.

Other Improvements: Goal Completion Confirmation and Quick access to Next Common Flow

A Confirmation Toast presents an option after Adding New User to go to their HR profile and add additional information, or additional setup needs. This reduces the number of steps for admins that want to check on the newly created account, to perhaps give additional permissions to, etc.

Results:

Increased trust, happy admins who can more easily debug issues before they arise. Use of new “ad-hoc” task features increases. The Customer Success admins receive unsolicited feedback from customers praising the new “Add Employee” feature, which they shared with the rest of the company:

As a Product Designer, there really is not much better feeling than getting some unsolicited positive feedback from our customers. This is why I love what I do!