App and Web HR redesign to improve navigational efficiency and satisfaction

How I navigated constraints and adapted to changes to enhance a feature, enabling managers to easily select their employees within an HR and payroll platform.

Start Date: July 2023

Time period: 3 months

Role: Product design

Introduction

The project's aim was to enhance a feature that allows managers to select their employees within an HR and payroll platform, available both on the app and website. Through research, I identified that in the current product, managers select their employees before navigating to the relevant module. This was a pain point for managers, causing difficulty finding and navigating the platform. As the sole product designer on this project, I redesigned this feature, reversing its logic. The new design would allow users to access the module and then select their employees to maintain consistency and enhance navigation. There was great scope for opportunity in this project, but limited capacity and time. The challenge would be balancing those.

Deliverables:

Map user flows
Competitor/Comparative review
Usability testing
Wireframes
Prototypes
Hi-fi hand over

Process

The project started with some ambiguity. Although there was a clear problem to solve - selecting employees was not intuitive and was difficult to navigate - and a proposed solution - navigate to the module first and then select the user - the design brief lacked specificity. The brief was, "We need managers to be able to select team members." Initially, the project was predicted to take two weeks, and alarm bells were ringing.

With both the Subject Matter Expert (SME) for Team Selector and my direct supervisor away on leave. I had a host of unanswered questions. Which modules are included? How does the user goal vary between those modules? Who are the users, and which user segments relate to this? How many people do they need to select and why? Does the process of selecting multiple employees need to be flexible, easy to change, or comparable? What issues and opportunities exist beyond the navigation pain point? What other factors might influence this process such as lifecycle, delegation, posts, reporting lines, and team size? etc. The answers to which would impact the deliverables and timeline.

To find answers to these questions, I first looked into existing research, gathering insights from previous studies. From this, I identified some of the modules Team Selector applied to and, in turn, examples of user goals. This helped me to create a topic map to steer discussions with PMs and ‘managers’ enabling us to identify and fill in the blanks in our knowledge.

I had also hoped that the topic map would help me to push back a little on the 2-week deadline by articulating how little we knew about the ‘user’ or what they aimed to achieve. This was met with resistance and frustration, the source of which was misalignment on expectations. I had anticipated that we would design in context, with the users' goals in mind. This could potentially lead to a different team selection user interface depending on the module, the number of users being selected, and the user's goal. I provided an example of a major competitor doing this to help illustrate the point, relating it back to our modules.

The vision for Product Managers, however, was to create a single, universal component across all modules in order to significantly reduce development efforts. An extension of the deadline was not an option due to time constraints, leaving no room for the Discovery and Define stages.

No matter the module, the designs needed to guarantee that the logged-in user would be set as the default. The user should also have the option to select either single or multiple employees, depending on the module. I was instructed to "design it like the Microsoft Teams search bar," but this wouldn't indicate whether users could select one or many employees. I felt this idea wasn't thoroughly considered, especially in terms of the details we'd provide, how we would present and order employees, and how it would function for the user.

I wanted to bring more opportunities and ideas to the table so I examined competitive and comparable sites for inspiration. Using these inspirations, I created a few low-fidelity designs to facilitate discussion and to pin down the details and managers needs.

In the ideation phase of design, I like to prioritise quantity over quality, as I've found that my best ideas don't usually appear first. By pushing myself to generate more concepts, I not only improve my designs but also enhance the quality of discussions stemming from them. There are several questions we considered off the back of these designs: Should we include a Role, Post, and Role ID? Should we display the employee's official name or/and nickname? Should this information be visible or hidden from managers? Should we highlight recently selected team members? What sorting and filtering options could be beneficial? How does the component impact the user flow eg using a modal that disrupts users taking them out of the flow to focus on selection? How about if we take up real estate by using a side panel? How dynamically can we add and deselect users? How would I-framed content for MVP impact design considerations?

Through considering the above, stakeholders agreed on a top design. With scope in mind, I recommended a consistent and recognisable team selector bar at the top of the page. By default, it would display the logged-in user, and then populate with selectable employees. For the minimum viable product (MVP), this would be a visual aid for the user. Post-MVP, there's potential to make it more dynamic by enabling users to deselect individuals from the bar. Selecting individual or multiple users would be signified by radio buttons or checkboxes. We would show the employee's display name, role title, and role ID.

I had initially designed for two agreed user flows:

A. Logged-in user or one other employee

B. Logged-in user, or one or many other employees

However, while mapping the flows against the modules to create clear scenarios for user testing, it became clear that we were missing other flows:

C1. Empty state or one other employee

C2. Empty state or one or many other employees

D1. Logged-in user or one other (Same design as flow A but a different technical consideration)

D2. Logged-in user or one or many other employees.

With the discovery of newly required designs, no usability testing, and still needing to migrate the designs to Hi-fi, hitting the deadline didn’t look possible. Fortunately, my director and the Subject Matter Expert (SME) returned at this point. With their backing, I was able to articulate to stakeholders that the project's complexity had been underestimated. As a result, I was finally able to extend the deadline. Phew!

With this extended deadline, I was able to prepare testing, recruit participants, and begin incorporating designs to cover the new flows and an empty state for situations where the user cannot be displayed by default. These designs imitate our existing empty states, but now include a clear call-to-action (CTA) to guide next steps. Additionally, I added a progressive disclosure design for flow D2 that guides the user to select either themselves or their team before making a choice, enabling us to display employee and manager-level content within the same module page.

With the two participants both flying through the testing and succeeding directly on tasks, I migrated designs to Hi-fi, ready for development. Lacking time to conduct further testing I logged findings whilst adding a ticket for further testing to the UX backlog.

It was at this point that as a business we changed strategy. To speed up development, we would be moving away from our existing design system to Material 3 (M3). I would need to convert the Hi-fi files from our Design System to M3.

While transitioning the designs to M3, I took the opportunity to introduce some North Star designs, incorporating insights from testing. I presented these designs as scalable options to provide incremental value in post-MVP releases.

, including:

Better organising the logged-in user, direct and indirect reports with headers and dividing lines, instead of mixing them alphabetically.
Indicating the number of employees selected.
Displaying the role title and revealing the role ID through chips.
Providing filter tabs - We could include 'select all' and 'deselect all' options.
Allowing clients to set up custom groups.

We agreed it would be better to display the role title and remove the role ID for MVP and that, if development stayed on track, we could include the headers and dividing lines.

Results

This new design significantly enhances the current platform's usability. Whilst the conditions may not have been ideal from a design perspective, I'm pleased that the new design is more intuitive and doesn't present navigation difficulties. This project has underscored the importance of a clear, well-defined brief and the necessity of compromise to meet deadlines. I’m proud that I was able to navigate uncertainty and tension to deliver a design fit for purpose, now being built by development.

For the next steps, I plan to conduct A/B testing to compare the new design with the existing one. Following this, I intend to interview senior managers who oversee many indirect reports to better understand how the design could better serve their needs.

Delivered: