Designing for Complex Enterprise Workflows

Shefali Netke
SmartRecruiters Design
6 min readAug 6, 2018
Storyboard for Report Builder

It’s a challenge to maintain a simple interface and smooth experience when you are designing to accommodate for a variety of user workflows. In many cases, a user’s process spans multiple software applications so the complete user workflow may not actually be contained to the system you are in control of designing. This is especially true for enterprise users who may be using up to 5 different tools to get their work done. We often run into this situation when designing enterprise features at SmartRecruiters and make sure to be mindful of the variety of workflows in our design discovery process.

Our challenge

Our older 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. In order to solve these issues we developed Report Builder, which allows users to create customized data sets, automate report delivery, schedule reports, and specify report recipients.

The old version of pre-built reports in SmartRecruiters

Report Builder is a part of our analytics product, which helps users better understand and measure their hiring processes. Our customers need to use the data in the SmartRecruiters system to create custom reports such as an “Open Jobs Status Report” or a “Monthly New Hires Report.”

A big problem from the design perspective when starting this project was that it seemed as if each user had an incredibly intricate and specific way of creating reports. Some users knew exactly which data points they needed while others wanted to explore the set before deciding. Some users created reports every day while others came in ad hoc. Some users wanted to freely share reports while others were concerned about data privacy.

To make the design process manageable and create a robust feature with great UX, we leaned on this set of five ideas to drive the project:

1. Identify 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.

The top four reporting areas were surfaced as quick selections in the Report Builder UI

2. Be aware of the context

We observed that users had varying start and end points for their workflows. For some, the report creation process began with an ad hoc request from their manager, versus others who started the process on their own as a part of a daily morning routine. After extracting the data from SmartRecruiters, most of our users continued their building workflow in another software (eg. Excel, Tableau) before the report was ready to be used. From seeing this, we realized that we had to accommodate for different starting mindsets and maintain a smooth experience with other software that came before the final report.

To better understand the mindset of your users as they enter the product, be aware that the true starting point of their workflow may be in a different application entirely. You can better design the steps of your experience once you have an understanding of the common entry points. If you can identify a common partner software used as well, you could use similar navigation to that software and workflow patterns to create a more cohesive experience overall despite the shifts. For example, we knew that most users also worked in Excel so we incorporated a spreadsheet style visual preview into our feature.

Our users reporting workflow often started and ended externally

3. Full customization ≠ Good UX

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 realized this would not be the best approach. They 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. To dig deeper into this, we worked with our engineering team to solidify which pathways worked and which would fail. 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. We 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. Just because users can or want to customize everything does not mean they should. Over-customization can be overwhelming. Apply restrictions in a friendly way to guide users to successful outcomes.

Available columns were restricted to only those that would produce a valid report

4. Bring automation to workflows

We accounted for both ad hoc and recurring reports while designing Report Builder, but knew that the majority of users would utilize recurring reports more often. We did not want users to be unnecessarily repeating the task of creating the same report and manually running it again and again. After a user sets up a report, the template is saved, accessible, and editable whenever needed. We also introduced scheduling in an effort to further automate the process. Users can schedule a report so it comes directly to them every day, week, etc. Together, these features ensured our users would have a smooth, automated process for reporting.

Entire Report Builder form

5. Give yourself time to iterate

Report Builder was not designed in one go, it was the result of many iterations and a strong partnership with Product & Engineering. The design process started with user interviews, storyboarding, competitor analysis, and several low-fidelity wireframes. I mocked up many different layouts and interaction patterns before getting to a design. Once fully developed, we ran a beta program as well to collect feedback and made further design adjustments to the feature. The combination of extensive ideation, teamwork, and user feedback were critical to the success of Report Builder.

A few of the design iterations for Report Builder

Final thoughts

Designing for custom enterprise workflows is ambitious, but certainly doable. Identifying your users’ patterns, being aware of their workflow context, having the appropriate guardrails and automation in place, and finally iterating with them will help you build delightful products.

Curious about design at SmartRecruiters or have thoughts on Enterprise UX? Reach out to us at design@smartrecruiters.com. We’re also hiring!

Other places you can find us are on Twitter @SmartRecruiters, @ShefaliNetke @triciflores, @chanishere149.

--

--