Portfolio

A Framework for Bulk Actions in Enterprise SaaS

Highlights

  • Goal: Create a set of tools that allow our internal teams to scale their capacity as our client base grows
  • Conducted extensive research with internal customer service and client implementation teams
  • Developed a set of frameworks to automate existing processes in the form of bulk action request forms
  • Significantly improved efficiency for client implementation teams, reduced tedious work, and saved significant hiring costs

Who?

Blackline Safety

Role

User Experience Designer

Deliverables

A design framework for bulk actions, low-fidelity wireframes, high-fidelity prototypes

Timeline

2023 – Ongoing

As a UX designer at Blackline Safety, a lot of my work involves designing new features for our software platform, Blackline Live. One specific area of focus was designing features that our internal teams use in order for them to do their work more effectively.

There’s a phenomenal advantage when your end users are your own coworkers. It makes it extremely easy to find time to conduct user interviews, and the feedback you receive is candid and honest. It’s also really easy to advocate on their behalf to higher-level decision-makers. (It’s pretty easy to draw the line between our users and our bottom line, after all.)

For this project, I was working on developing a suite of bulk actions for our internal teams. But since this project is all about internal processes, we should probably take a moment to establish some context first.

The customer onboarding process

Blackline Safety is a B2B SaaS and hardware company that makes portable gas detectors. Their primary customers are oil & gas, hazmat, emergency response, and remote workers. Our gas detectors are always connected to a network, and any events are immediately broadcasted to safety monitoring agents. Customers can manage and monitor their devices and workers using our software platform, Blackline Live.

In order to fulfill sales orders, we have a team of Client Implementations Coordinators (CICs) that set up and configure a new customer’s accounts and devices. These are tasks that are also conducted through Blackline Live.

The general flow of onboarding a customer consists of a few key phases:

  • When a new device is manufactured, it is activated on Blackline Live and gets a device ID number
  • The CICs will create a new customer organization account, and create team member profiles for each worker or employee in that organization
  • The CICs also move the devices ordered by the customer to the customer’s organization account, set up configuration profiles, and assign devices to the team member profiles (if applicable)
  • The CICs will train the customer on how to use and maintain their Blackline Live account once everything is set up
A Miro flowchart early in the research phase that outlines all of the tasks that a CIC does to onboard a new client.

The problem

The problem is a simple one. There were no bulk actions prior to this project, so it meant that the CICs had to do each of these tasks for individual devices and team members, one at a time.

Blackline’s customers range from small local operations to multinational corporations with thousands of devices and team members. “Tedious” would be an understatement. The fact that our CICs had to do things like this was a clear sign that we needed a better solution:

“The trick we were using was to have multiple tabs open. We would click a button on the first tab, then cycle to the next tab and click the same button on that one. By the time we got to the end, the first tab would have finished processing that step, and we would do it again with the next step.”

—Client Implementation Coordinator

For larger clients, the CIC team would submit a Jira ticket with a spreadsheet of all their desired changes to the software team. The developer would then apply the changes on their behalf. But this meant that we were using up developer resources, and the CIC would be forced to wait for the developer before they could continue their own work. This bottleneck further reduced the efficiency of onboarding new clients.

This isn’t just a problem for the CICs. This affected our technical support, rentals, orders, and software teams. It was therefore in everyone’s best interest to create a system that could scale with the growth of the company.

Tasks to be done

As a starting point, product management identified a few required tasks that needed to be done in bulk:

  • Bulk device replacement: when devices are sent in from repair, we need to transfer the device data to a new replacement
  • Bulk device move: we need some way to move devices between organizations for customer support and for onboarding
  • Bulk service plan and warranty assignment: when sales orders are made, the Orders team will activate service plans and set warranty expiry dates on devices
  • Bulk team member creation: new clients will give us large spreadsheets of names and contact details, which need to be turned into team member profiles in Blackline Live
  • Bulk device assignment: we need some way to quickly update device settings and assigned users during onboarding
  • Bulk alert resolution: sometimes a single gas event will trigger multiple devices into an alert state, so when we have someone responding to an event, we want to be able to resolve all of those alerts at once

The developers can create the necessary backend operations to automate these actions. But how do you create a bulk action tool that can handle all of these tasks?

Design considerations

Okay, I know this is a lot so far, so let’s summarize the key problems we needed to address:

  1. We have to create something that is both suitable for advanced and less advanced users. The CIC team is comfortable with complex and dense information, but other users have said Blackline Live can be rather intimidating. So how do we create something powerful enough for advanced users, but not too overwhelming for others?
  2. Each bulk action can have very different workflows from each other. The process of creating a bunch of team members in bulk is very different than the process to select and resolve a bunch of alerts. How can we accommodate all of these different workflows?
  3. We need something that is extensible and futureproof. We might have six bulk actions for now, but more will come in the future. So how do we fit those in, too?

The solution

In the end, this project was less about designing a specific product, but more about creating a design philosophy on how we do bulk actions in general.

Instead of creating a single workflow that would try to do six very different tasks, we would create a modular suite of bulk action tools. Depending on the type of task the tool would perform, we would categorize it into one of three buckets:

Simple edits: inline table actions

“I want to do one quick thing to these items.”

These are single, one-step changes to some aspect of an entity like a team member profile, device, or alert. So for things like bulk alert resolution, we can select multiple rows in a table of alerts and then mark them all as acknowledged or resolved.

An example of a simple edit workflow. Multiple alerts in a table could be selected and you can mark them all as acknowledged or resolved, changing their status.

This is the same logic as how you would select multiple emails in your inbox to label or delete. The tasks would only require a simple click, or perhaps a simple modal at most.

Simple request form

“I want to apply a single set of actions to these items.”

Medium-complexity actions such as bulk device move usually involve applying the same set of actions to a group of entities. This requires steps that can’t be easily done through a simple inline table edit.

Since our users submitted requests through Jira, anyway, we decided we would recreate a similar workflow through Blackline Live.

To solve this, I designed a self-service request centre where users could submit a form with all of the required information. Once submitted, Blackline Live automatically processes the request, without any additional intervention from a developer.

As it turns out, other software tools also use a request centre as a design pattern for these types of tasks. Questrade, for example, has a suite of request tools for different operations in their main menu.

Questrade has a similar suite of request forms for more complex tasks that can’t be handled by a single inline table action.
The “request history” tab in Questrade also lets you to review past submissions, their statuses, and any details you may want to see.

Similarly, the request centre design I used would have a similar design pattern. A dropdown menu would allow the user to select a particular bulk operation, and the rest of the form would change accordingly.

Figma mockups of the different bulk action request forms when the user changes the operation (red).

Under the “Request History” tab, you would see a list of all the previous requests and the details.

Figma mockups of the bulk action request history tab. The user can view all past requests and be notified if any individual action failed or succeeded by going into further detail.

Creating an automated and modular request centre means that we can:

  • Allow client-facing teams to be more autonomous without waiting on developers to turn requests around
  • Introduce new modules and bulk tools in the future without interrupting the workflows of existing tools
  • Better control user access and permissions, so our teams can only access the tools that are relevant to their work instead of giving everyone superuser-level privileges

Complex edits via CSV

“Each item needs a unique set of changes made to it.”

The last use case is when you need to make changes to multiple entities, but the changes are different for each one. For example, if we want to create new team member profiles, each team member will have a unique name, employee ID, and contact information. Or, if we want to reconfigure a bunch of devices, each device could have different combinations of settings and assigned users.

Simple request forms wouldn’t be enough. Asking the CIC to break down their spreadsheets into smaller ones would be creating more work for them. The only way we can handle these types of requests is by processing the same spreadsheet that a CIC would otherwise submit through Jira.

(The exception to this rule is device replacement, which never handles more than 10 devices in a single case. I decided that was more easily done as a simple request form instead of a complex CSV process.)

For these complex use cases, the user downloads a standard CSV template file, and then populates it with the required information. Once uploaded, the user will see the changes that will be applied based on the data in the CSV.

Conceptual wireframe of how a bulk device edit would work by having the user submit a CSV file directly.

These actions still start from the same request centre as the simple forms, but direct the user through multiple steps instead of a single page. Once the request is complete, the information will still be accessible through the Request History tab.

Even though this may take a few more steps than simply writing out a Jira ticket, we believe that this is still more efficient because we no longer require developer intervention to do the task. We would be respecting the CIC team’s need for efficiency by keeping them in control during the entire task.

Outcome

As of this writing, we have created a self-serve request centre with a bulk device replacement tool, which allows technical support to transfer data from one set of devices to another for repairs. We are also actively developing a device move tool, a team member creation tool, and a mass device assignment tool.

We saw that our technical support team has quickly adopted the new replacement tool, and they’re now using it for all of our repair cases.

“We started off thinking it would just be for larger RMA orders, but it’s so easy to use that we just use it for all of them now, even if it’s just for one device.”

—Technical Support Agent

The feedback I’ve received so far is positive, but I think the CICs will be even more delighted when the modules they need get launched soon. I’m personally interested in seeing how this framework handles new modules and features in the future!