Case study

Turning Sequential Records into a Batch Operation

Grant Management · Pris

Reducing support dependency in a complex B2B workflow

  • Product Design
  • User Research
  • Usability Testing
  • B2B SaaS
  • Complex Workflows
  • Maze

One operation at a time created dependency

In Pris, a B2B platform for variable compensation management, grants and batches were registered individually. In larger operations, repetition pushed configuration work toward implementation and support teams.

The problem moved to the internal team

An administrative task ended up being performed manually outside the product. The interface needed to preserve each registration rule while enabling high-volume operations.

Management of multiple batches in Pris with percentages, dates, values, edit actions, and pending states identified per item.
The overview keeps each pending state localized without invalidating the other batches.

Original process

  1. one grant / batch at a time
  2. more repetition
  3. more operational effort
  4. support dependency or manual operations
The UX problem was not only in the interface. It was also an operational problem.

Research revealed where the operation broke down

I mapped the flow with Customer Success, Product, and Technology and conducted qualitative interviews with clients. Research revealed dependencies, rules, and failure points in larger operations.

Customer SuccessProductTechnologyQualitative client interviews
Volume ↑Effort ↑Rework risk ↑
An error in one batch could require restarting a significant part of registration; some operations were performed by the internal team.

Different rules remained part of the model

Companies configured programs with different rules and structures. The solution preserved that flexibility while reorganizing how the full set was operated, monitored, and corrected.

Good UX does not always mean removing complexity. Often, it means giving people better tools to control it.

Batch operations changed the logic of the flow

Registration was divided into stages that could be saved independently. A central entry point began to gather multiple grants, added through the interface or imported from a spreadsheet.

BeforeOne grant at a time

Repeated flow and operational dependency.

Redesign
AfterCentralized management

Multiple grants and batch operations.

Create batch
Add multiple grants manuallyImport from spreadsheet
Both paths support the same management model without inventing extra file rules or formats.
Side panel for manually adding a batch to the management of multiple grants.
Manual entry preserves each batch rule within the combined operation.
Spreadsheet import modal with the batch list still visible in the operational context.
Spreadsheet import provides a second path for high-volume operations.

Batch operations also required an overview of the full set, per-item states, and continuity when part of the processing failed.

Recovery happened per item

A partial failure should not invalidate all previous work. The interface identified which item had failed, allowed it to be corrected, and resumed the operation without restarting the rest of the batch.

Happy path
  1. create
  2. review
  3. complete
Recovery path
  1. error
  2. identify
  3. correct
  4. continue
BeforeOne error could compromise a larger flow and require rework.New modelIdentify the item, correct it individually, and continue without restarting everything.
Error is an understandable flow state, identified by text and structure rather than color alone.

Testing changed important details of the solution

In Maze, 14 participants tested how they found the new area, identified the current stage, and added multiple batches through the interface and spreadsheet import.

14participantsMaze usability test
Core modelUnderstood

A few points needed refinement.

BeforeFair value calculation elsewhere in the flow
LearningThe content made more sense within the rules model
AfterFair value moved into Rules and explanatory copy adjusted
Testing did not only confirm the model. It changed the solution before implementation.

The overall model was understood. Testing moved fair value into “Rules” and guided adjustments to explanatory copy before implementation.

A model prepared for partial failures

  1. Create / import
  2. Manage multiple grants
  3. Review
  4. Correct items individually
  5. Complete
  1. One at a timeMultiple grants
  2. Fragile flowRecovery per item
  3. Support / manual operationGreater administrative autonomy
  4. Initial solutionRefined after testing with 14 participants

The operation moved from sequential registrations to managing multiple grants, with per-item recovery and greater autonomy inside the product.