Designing an HR Portal
I worked with a Cornell HR department to build a new website over the course of 3 months. I worked on user research, design and web development.
I’m confused when I need to find out how to start a certain HR practice, or find a specific document. This is because:
- Information on HR related tasks appears on a number of different websites
- I’m not confident that a document I find online will be the most up to date version
Based on the problem we identified, we defined our earliest design goals to be to:
- Consolidate and provide guidance for the most common work tasks
- Organize the work tasks in a way that is intuitive and scalable
- Create a search for the most relevant, up-to-date documents
- Employees under the Research Division (primary)
- Supervisors (secondary)
- HR Administrators (secondary)
User research results
We interviewed the target users in their respective demographic group. The interview protocol involved questions that would help us understand how people approached both routine and specialized HR-related tasks, and their current interactions with existing systems.
We uncovered the following pain points:
- The central HR website has a lot of information —processes that go through the Research Division HR however, are slightly different and require special information
- It’s hard to for people to find an appropriate contact person
- Managers need a better sense of what to say when I hear: “can we…?” There are many gray areas.
- People often have questions about the following areas: benefits, retirements, tax questions, education benefits, on boarding, payroll and holiday.
Based upon our research, I created a primary persona of a new employee to the Research Division. I also created a secondary persona: a manager who supervises 20 staff, and typically makes one hire a year.
From the user research, we could tell that some use cases were extremely specific, for example looking for a specific document or how to start a certain process. Others were general and pertained to multiple activities by a type of user, for example the process undertaken by a manager when a new hire is made. This meant two different levels of navigation: one by user type (employee, manager, or HR administrator) and one by the type of work that was being done.
I established these work categories with the HR team. We found out that there would be a lot of overlapping content, so I proposed a system whereby blocks of content could fall under multiple categories. Every work category is composed of Primary work tasks, which are made up of secondary tasks and documents.
The result is a site is organized by topic. The building blocks of a topic page are modular pieces of functionality that can be moved around. This makes the design flexible as the Research Division grows.
A Suitable Home
The challenge was to structure the home page as to meet accommodate multiple use cases, while not succumbing to the lure of providing too much content at the top-level.
Based upon our user and market research, we aimed to put the following on the home page:
- Document/form search*
- Contact Information/contact tree
- Quick links (most commonly accessed)*
- Navigation by task*
- Navigation by user demographic*
- News and updates
I chose to go with a home prioritized document search, and featured the two levels of navigation, which addressed a dichotomy in use-cases that we had previously uncovered:
Branding was an interesting problem, because I was simultaneously restricted by the existing Cornell brand, and free to operate within those parameters. I created a style guide to help maintain consistency, after the project was passed on to the department.
I implemented the site using Drupal CMS. The site was piloted for a month, opened to all research employees, before a full launch was rolled out on December 2016. During this time I iterated off of constant user feedback.
After the pilot period, our team was confident that we had created a site that acted more as a helpful human than a bureaucratic instruction manual. User metrics came to prove this — after the release, we experienced a 200% increase in site engagement.
What I Learned
Getting team buy-in is difficult, but necessary. The HR team I worked with was unfamiliar with user-centered design at the beginning — and wondered why I couldn’t just “redesign the site”. I was tempted to do just that, but I knew the result would have been the same as before, maybe prettier, but the same.
The hard part was explaining the motivation behind the user-centric practices. Once we got started with the interviews though, the HR staff members proved to be invaluable in drawing out insights from the users, as they had so much domain knowledge.