Last last year we announced we’re building an HRIS, the industry shorthand for a Human Resources Information System, which is the central repository for all employee data—personal information, employment status, role details, hours worked, compensation, and more. This type of data constitutes the current and historical records of the people that power your company and the programs that power your people.
As designers at Lattice, we’ve traditionally focused on the people and programs. How can we make managers more effective? How do we design the best tools for people teams to run performance review cycles? How do we enable employees to be heard and have their feedback addressed? Once we got to building an HRIS, our focus shifted to the underlying foundation that make or break these experiences: the employee data. Through our last 2 years of designing an HRIS we’ve developed 3 particularly noteworthy lenses to crafting a great experience. (1) Data Integrity, (2) Data Regulation, and (3) Data Integration.
People Teams, HR Administrators, Payroll Specialists and many other functions are constantly adding, changing and managing employee information. Just think about your own employee journey to when you’ve been hired and begin onboarding. Behind the scenes you’ve been added as an employee into the company’s record with your name, role, title, start date, employment classification. You’re being asked for personal information such as address, bank information, tax withholdings, and even your t-shirt size. You’re being assigned to pay cycles and time off policies. Tasks and workflows are being kicked off.
When designing, we need to ensure that data is accurately being entered or captured throughout this process to ensure a smooth, delightful employee experience and avoid catastrophes such as not being paid! We need to make sure there’s consistency across the platform in how its being collected, configured and used.
We took the approach of HR Administrators creating onboarding templates that can be applied to a newly added employee based on their employment type (full-time, part-time, contractor) and other factors. In the template, we provide recommended defaults for what fields to include and clearly mark who will need to fill them out. The admin then configures what data they need and want to collect based on their operations. One challenge we face is determining when to expose the flexibility of the system, in this case choosing from the vast fields library we have, and when to be opinionated in our guidance and automation.
It starts to get complicated when you factor in local regulations and role permissions. Who sees what—where, when, why, and how? For example, an employee in our Lattice London office shouldn’t be asked for and have a social security number on record. I should see my own pay information, and unless you’re my manager or a privileged Admin, you shouldn’t. A contractor can’t have access to certain systems. It’s critical for us to thoughtfully handle sensitive employee information, and design intuitive controls for privacy, compliance, and access.
We provide a comprehensive fields library where admins can configure which data they record for their employees, including the ability to add custom fields for data unique to their business and how they operate. It can get unwieldy for an admin to easily understand how a record is configured for a specific person or group of employees.
We initially were going to introduce a new construct called “Employee Records” to provide that visibility, however, it would have to be another entity that admins configure—and configuration can spiral out of control, creating additional, unnecessarily confusing work. This is a tension we often face when designing systems of record, how to provide intuitive configuration while showing the effects.
Instead we built upon the atomic unit of our HRIS, fields, and designed the ability within the same space to configure field details, their values, assignments, and permissions. We then re-introduced the concept of record as a preview based on criteria you enter.
We’re designing for mid-sized businesses who likely had a starter system or manually tracked data before coming to us. This means getting data in (import) is crucial for getting started. And once with us, companies still operate within an ecosystem of HR tools that we need to seamlessly integrate with. This is where syncing data dependably is paramount.
CSVs are the common denominator across systems and the most basic way to get data out if a system, re-formatted, and then into another.
A lot of the challenges with integrations come down to data being structured, formatted, and named in a different way and which data you want to move from one system to another. This is where the field mapping experience helps limit errors and enable smooth transfer of data. A seemingly simple screen has more going on than at first glance. We need to communicate default mappings that can’t be changed (in this example, first name and last name), required mappings where you can choose a field (in this example, what email field do you want to reference), optional mappings depending on whether or not you want to send that data, and then custom fields.
These are just a few examples of how we need to think about the display and configuration of data that underpins every workflow and experience in Lattice HRIS. While we are still designing for people, we’ve come more and more to appreciate the ecosystem of data that describes and connects these people in a workplace.