Designing the decisions before the decisions.
A compensation round is a pay-review cycle. Before managers propose a salary or bonus change, an administrator decides who is included, what each role can see, which rules apply and how approvals move forward.
I owned the end-to-end user experience and product design of the compensation round builder.
The case follows the connection between information architecture, detailed interfaces and the states around a task: configuring, reviewing, validating and publishing.
The compensation product is in use by enterprise customers. This case explores the configuration decisions behind that experience, alongside earlier iterations that shaped the work.
Why this matters to the product
Different organisations have different pay policies. A reusable configuration model needs to accommodate those differences while keeping the consequences understandable to administrators and managers.
beqom presents guided rounds, configurable workflows and administrator self-service as product capabilities. The design challenge here sits at their intersection: making flexibility usable.
Product context from beqom ↗Organise around the decision being made.
The earlier wizard separated eligibility and guidelines into their own steps. But an administrator thinking about a salary column needs those rules in context. Moving between steps can make that relationship difficult to follow.
DECISION 01 / INFORMATION ARCHITECTURE
Bring related policy decisions together.
I organised the experience around the column being configured. Its settings, eligibility and guidelines belong to the same task, even when each needs a different level of detail.
- Use explicit labels for configuration choices; compact icons alone do not explain the task.
- Separate the rule definition from its consequence, then show the relationship.
- Keep warning and blocking states distinct in both wording and behaviour.
Bringing rules onto columns reduces separation, but loses the old all-rules overview. A consolidated validation step becomes essential for reviewing the round as a whole.
DECISION 02 / PERMISSIONS & INTERACTION
Make access and approval consequences visible.
An actor is a role in the round, such as a compensation manager or an HR reviewer. I used a role overview with a detail drawer so administrators could move between the whole configuration and one role’s settings.
Show the approval path in context.
Workflow stages describe the overall process. Steps within them describe who acts. The visual structure starts with one understandable path, with more detailed settings kept in context.
A visual canvas helps explain relationships, but dense configuration still needs precise labels and explicit progression rules. The precedence between multiple conditions remains something to demonstrate and validate.
DECISION 03 / FEEDBACK & RECOVERY
Make configuration safe to complete.
The experience continues after the last field is filled. Administrators need to know what prevents publication, what deserves review and what the system is doing once publishing starts.
Validation reports also distinguish generation from file preparation, with retry and download actions appropriate to the state. These details are part of the task, rather than a separate layer added after the main flow.
Progress feedback should reflect what the system actually knows. The design uses named steps and states; a time estimate or percentage would require reliable supporting data.
A reusable product, with room for different policies.
The design connects reusable configuration patterns: rules on columns, settings on roles, staged workflows and named budget definitions. Shared wizard patterns also extend to bonus plans and payout curves.
The product rationale is to support different policies through a coherent configuration experience. Lower implementation effort, faster setup and fewer errors are useful measures for evaluating that direction; they are not yet established outcomes of this case.
What the work demonstrates
- An end-to-end configuration model connecting administrators and managers.
- Detailed UI decisions around grouping, visibility, validation and progress.
- Exploration documented in screens and interactive-prototype references.
How I would evaluate it
These are questions for future evaluation, rather than measured results reported in this case.
- Can administrators explain who a rule affects before publishing?
- Can they resolve a blocking issue without retracing the whole setup?
- Where do they revisit steps, and what information is missing there?
What I would carry forward
Align the language of rules, roles and scope early. Prototype error recovery alongside the main task. Give experienced administrators a way to review the whole configuration without retracing every step.
The original working material.
These 35 exports preserve different iterations and explorations, including their original placeholders and sample data. They are supporting material, rather than a single final product version.