DANIEL FALCÃO
Back to case studies

BEQOM / PRODUCT DESIGN CASE STUDY

Compensation planner

Bringing context to complex pay decisions.

A pay decision needs more than a spreadsheet. Bringing people, budgets and approvals into the same view — without losing the detail.

Enterprise UXData-dense interfacesDesign systems
P01Planner overview: stages, people, budgets and grid

Product work used by enterprise customers, illustrated with design exports and sample data. The archive includes earlier iterations. Product UI remains in English.

The project, in brief.

One workspace for managers to propose pay changes, HR partners to review them and auditors to understand what happened. The design challenge was to keep every decision connected to the people, permissions and budget behind it.

Context
beqom · Enterprise compensation
My role
Lead product designer
Period
2025–2026
Format
Desktop web application

I was the lead product designer for the Compensation Planner, working with product managers, developers, the tech lead and services colleagues to understand customer needs and make product decisions.

The table was only part of the decision.

The original grid covered workers, compensation columns and filters. As the product grew, managers also needed to understand whose data they were looking at, which budget applied and who needed to approve the next step.

A flat list could show the numbers, but not enough of their context. The task was to make room for that context without taking the working surface away from the manager.

P19Earlier grid direction, October 2025

The constraints

  • Columns and permissions come from the round configuration.
  • Server calculations introduce loading, validation and failure states.
  • One workspace serves different roles and levels of the hierarchy.

The decisions behind the screens.

Give context its own place.

Workflow stages, the Population tree and a budget band sit around the grid. Choosing a manager establishes the scope for the workers and numbers on screen. Context can collapse when the task needs more room for rows.

The trade-off is vertical space. Separate regions make the relationship between scope, budget and action more explicit than putting every control in one toolbar.

P04Selected population scope and its connected data
P06Expanded workflow stages and responsibilities

Let the budget expand as one band.

Independent expand controls made neighbouring budget widgets jump between different heights. The explored solution gives the whole band three sizes: collapsed, medium and expanded.

One control trades individual widget expansion for a steadier layout. The expanded state adds detail by scope; it does not change what the total means.

P02Budget band in its medium state
P03Expanded budgets with detail by scope

Use one language for warnings and limits.

A soft breach saves the proposal and explains the warning. A hard breach blocks the change and offers a clear recovery path. Budget validation follows the same pattern as compensation guidelines, so people do not have to learn a second set of rules.

P23Soft validation: save the value and explain the warning
P24Blocking validation with a recovery choice

Remember a useful view — and explain when it changes.

Saved views combine column visibility and order, filters, sorting, page size and row height. The design also covers the less obvious states: a view modified by the user, or a saved view affected by a later change to the round.

The supplied brief describes a 394-column stress test. That is a design test condition, not a measure of customer adoption or business impact.

P08Saved views menu
P09Column setup: visibility, order and pinning

Design what happens after a bulk action.

Applying one increase to many people starts with selection, but continues through recalculation, progress and validation. A modal gives the field, value and required note a clear place. An inline fill-down idea could not carry all of that context.

P11Selecting workers for a mass update
P12Mass update: field, value and note

Keep the reasoning beside the proposal.

The notes drawer groups entries by field, newest first, and distinguishes proposal notes from general notes. It favours a scannable record over rich text. Individual history and the audit trail provide another level of detail when a reviewer needs it.

P17Notes grouped by field, newest first

Making the behaviour tangible.

Interactive HTML prototypes and Figma documentation supported conversations with engineering. The important handoff details were the behaviours between states: selection, recalculation, validation, view changes and recovery. The screen archive also includes tree anatomy, analytics exploration and a mobile direction that was not pursued.

What changed. What comes next.

The product work shown here has been implemented and is used by enterprise customers. It brings scope, budgets, approvals and editable data into one workspace. The archive also preserves earlier iterations and explorations behind the delivered experience.

What I would carry forward

  • Define the scope model before designing the surfaces that depend on it.
  • Test with demanding column counts early, not just tidy demo data.
  • Plan for saved settings to become outdated, and explain the recovery.

Useful measures for future evaluation include time to first submission, use of saved views and over-budget proposals. These are evaluation questions, rather than measured results reported in this case.

A closer look.

The full set of supplied screens, including earlier versions and explorations. Open any image to inspect it in the image viewer.

Explore all 25 screens
P01Planner overview: stages, people, budgets and grid
P02Budget band in its medium state
P03Expanded budgets with detail by scope
P04Selected population scope and its connected data
P05Population tree: row and selection states
P06Expanded workflow stages and responsibilities
P07Labelled toolbar for views, filters and column controls
P08Saved views menu
P09Column setup: visibility, order and pinning
P10Creating and naming a saved view
P11Selecting workers for a mass update
P12Mass update: field, value and note
P13Read-only calculation rules from the planner
P14Analytics exploration with summary tiles and charts
P15Chart drill-down in a detail drawer
P16Individual view with compensation history
P17Notes grouped by field, newest first
P18Audit trail with actions, editors and filters
P19Earlier grid direction, October 2025
P20Mobile exploration, not pursued
P21Tree node anatomy documented for engineering
P22Budget states: on track, near limit and over budget
P23Soft validation: save the value and explain the warning
P24Blocking validation with a recovery choice
P25Budget scope in manager focus mode

THE OTHER SIDE OF THE EXPERIENCE

Compensation round builder

Designing how administrators configure rules, permissions and approvals — before a pay review reaches managers.

Working on a complex product?

Let’s discuss how I could support your product or team.

Let’s talk