Summary:

The older SmartRecruiters reporting system only offered a set of pre-built reports for users to pull their data out of SmartRecruiters. However, this solution fell short for many as they needed more customized data point grouping and filtering. As a result, users had to manually merge multiple data sets each time they wanted the latest data. In addition, they had to manually send reports to recipients as well.

The pain of these tasks added up as many of our users utilize the reporting functionality on a weekly or daily basis.

My Role: Product Designer
Goal: Allow users to create customized data sets, automate report delivery, schedule reports, and specify report recipients

User Research

Finding patterns: During user interviews, we saw that users did steps in different order, spent varying amounts of time on sections, and had distinct vocabularies when talking about their process. Although each had a unique workflow for building a custom data set, there was also a lot of overlap in the types of actions they took. We found that they had general data themes in common which we then surfaced in the first step of the building process (see below). It was critical to zoom out and focus on the patterns across users instead of getting overwhelmed by the complexity of an enterprise analytics workflow.

Challenges

Building a report is a fundamentally exploratory process. However, it can be difficult for users to conceptualize all the intricate relationships between different objects within our software. We had initially considered opening up all the pathways to give users full report control, but users would be at risk of encountering dead ends, errors, or empty reports when selecting data because the underlying data structure may not support a specific data pairing. In order to prevent frustration, we only surfaced the successful pairing options by default.

Users can still select most custom data points with this approach, but they are prevented from selection patterns that would result in a complicated error message. I also designed a toggle that allowed users to see the data points that may not be available for a specific type of report. This helped users to transparently access how they might reconfigure the report to get certain data. The goal here was to prevent over-customization to lead users down a successful path.

Design Process

I went through several iterations on the layout and interactions involved in Report Builder. I first stared with the overall form pieces based on the key elements identified through research. Below is a compilation of some of the iterations I went though.

Simple Icons: I started with an approach for a small number of reporting areas and columns. This layout did not work because the report areas quickly exceeded the six listed in the design and the columns needed to scale up as well.

Search and right columns layout: This next iteration started to explore ways to build a scaleable columns selection interaction. The selection would be in the searchable view on the left with a preview on the right.

Vertical layout with preview: I tried a version with more white space to simplify the layout with a vertical build up of the columns. I also included a preview with live data at the end of this form.

Vertical layout with expanding menu: This shows the how the column selection could work with the vertical layout.

Immediate preview: I explored a version with a column preview showing up right away after selecting an item from the menu.

Beta Prototype

We ran a beta program with a select customers to further gather feedback on this design. Overall, the feature was well received. The most feedback giver after additional data points was around a better way to conceptualize rows and columns. The row concept was confusing to many users and the beta form provided too many options to sort through well. Once a row was selected, the columns layout was not optimal for long lists which became clear with the live data. Users found the descriptions helpful, but couldn’t categorize and discover data points as easily as they needed to.

Next iteration

I took the feedback and data from the Beta users and made a handful of critical design changes. I brought back the icons approach and surfaced the most popular rows that were selected. I also renamed the section “Rows” to “Reporting Area” to make the concept more clear and accessible to those less familiar with building reports. The second big change was to revisit the grouped columns menu. By adding this back in, the column options were more digestible and had better context. I also made a handful of small UI changes to improve usability, such as separating out the search bar to give it more visibility. This version received a lot of positive feedback from users.