← Product Product · Case study

Salary benchmarking: designing the version the data could support

12 weeks · Four-person intern team · Team lead and program lead

My roleI set the scope and pacing, coached the team, and made the UX and UI calls wherever options narrowed to one. Four interns ran the research and built the screens.

The final design, recreated with illustrative data: benchmark results for a product designer in Austin, with the median base salary, percentile calculator, percentile breakdown, salary histogram and historical median.
Final design · benchmark results · Clickable prototype ↓
The problem

Clients had no way to compare their pay with the market inside the product. 18 client requests asked for it, and some clients paid outside vendors instead, one about $8,000 a year.

The constraint

12 weeks, a four-person intern team, and a brief that asked for everything. The only data source was a third-party salary survey: US only, unconfirmed bonus and incentive data, and market averages rather than named companies.

The outcome

A benchmarking tool tested in 13 sessions, 6 of them with people who set or approve pay. Product management received a 69-page report, specs at four screen widths and a guided prototype, took it to leadership and got the project prioritized.

The ask

Clients were paying someone else to answer a question the product couldn't

At a publicly traded HR technology company, clients set salary grades and pay ranges in the product's compensation module. Nothing in the product told them what the market paid for the same role, so they entered those ranges by hand from whatever source they had. Clients had filed 18 requests for a market comparison, the oldest dating to 2021. Some clients had stopped waiting: one paid an outside vendor about $8,000 a year for salary ranges. Prospective clients raised the gap as well, and competing HR platforms already offered benchmarking.

The product brief estimated the tool would reach about 4 million employees. It would sit inside a compensation module that only 1,266 of about 40,000 clients had used, and the team argued that market data would give more clients a reason to adopt it.

18
client requests for a market comparison, the oldest from 2021
$8,000
about what one client paid an outside vendor each year for salary ranges
4M
employees in the tool's estimated reach
1,266
of about 40,000 clients had used the compensation module
Sources: ·

The brief asked for nearly every comparison a compensation team could want, plus a dashboard widget to act on the results. Sorting that list into a product the data could support became the team's first real problem.

A brief that asked for everything
  • Geographic locationAsked forMVP · market filter
  • Level of experienceAsked forMVP · as career level
  • Base salaryAsked forMVP · the main results
  • Short-term incentivesAsked forMVP · total comp tab
  • Long-term incentivesAsked forMVP · total comp tab
  • Fixed allowancesAsked forNot built
  • RevenueAsked forReshaped · company size and ownership filters
  • Industry segmentAsked forMVP · market filter
  • New hires versus existing hiresAsked forNot built
  • Out-of-range employees widget, with pay actionsAsked forLater · salary grades

The original scope, item by item, as the product brief listed it before any research.

7 kept, several of them reshaped · 1 later · 2 not built. The MVP added job title as a required input, because the survey organizes jobs by title and career level. Incentives moved to a lighter total compensation tab beside base pay.

In clients' words

What clients asked for

From the client requests the team affinity-mapped
In their words
“I'm looking for salary benchmarking based on data that you have for us to use to compare how we're paying our employees to market standards. I know several other payroll companies offer this as part of their system.”
“As a manager, I've experienced several of my employees leave the company for a higher paying position. When I give annual raises, I want to see a salary comparison tool to see how far off my employees' salaries are from the market rates so I can adjust them accordingly.”
Also in the requests
  • A client currently pays a salary data vendor about $8,000 a year to help determine salary ranges.
  • Prospective clients raised concerns that the product neither provides nor integrates with salary benchmarking data.
  • A client with positions out of market wants positions outside the range flagged, for fear of losing employees or increased turnover.
The original brief

Salary benchmarking

Project brief
Project description
There is no way in the system for companies to benchmark their salaries and compare them with other companies and the market. This will help solve employee retention with equal pay opportunities. This would impact about 4 million employees.
Background
We are working with a third-party salary survey provider to get pricing on outsourced compensation data.
Roadmap fit
Not dependent on any other release. Will eventually tie into position management, personnel actions, and career and succession planning.
Value to the team
Helps compensation become its own module, rather than being sold with performance management.
Risks
We can build this tool without having the third-party data ready.
Success criteria
A big win for current clients, and more sales of the module to future clients.
Original scope
Compare position salaries with other position salaries, based on geographic location, level of experience, base salary, short- and long-term incentives, fixed allowances, revenue, industry segment, and new hires versus existing hires. An easy way to see employees who are out of range of the benchmark for their position, as a dashboard widget with actions to adjust the employee's wages or edit the salary range they're tied to.
The setup

I asked for a plan in kickoff week and decisions at every check-in

The team was four product design interns working over 12 weeks in the summer of 2025. I ran the internship program and led this team. A senior designer served as the team's subject matter expert, and a product champion and a product manager shaped the scope, with a development lead advising on feasibility.

I ran the team's first week of standups myself, and the team built a project plan with me by the end of kickoff week. Every activity in it needed an objective and an expected outcome, so the team could say why they were doing it.

12 weeks, summer 2025 · select a point to see what I did
Plans I set
Reviews and coaching
My test sessions
Every week
Week 2 · May 27 · Standups

I ran the team's standups myself for the project's first week.

Week 3 · Jun 4 · First review

I asked for real results and decisions by the next check-in, plus a rough wireframe while research was still under way.

Week 3 · Jun 5 · Project plan

The team built its project plan with me by the end of kickoff week, with an objective and an expected outcome for every activity.

Week 5 · Jun 20 · Coaching 1

First presentation coaching session: frame the problem with business needs, for an audience starting at awareness.

Week 6 · Jun 24 · Coaching 2

Second session: rest the case on the industry standard, and let the client requests decide the features.

Week 6 · Jun 27 · Run-through

Final run-through before the readout: 20 to 40 words a slide, early wireframes labeled not final, and room for interaction.

Week 8 · Jul 7 to 8 · Design-stage plan

I planned the design stage with the team, sorting features into primary, secondary and future.

Week 9 · Jul 19 · Hand-off structure

I set the structure of the hand-off package three weeks before it was due.

Week 9 · Jul 19 · My test session

I tested the early prototype myself: create a benchmark from the job library, view it, save it, edit it and group it.

Week 10 · Jul 23 · Script pilot

I was the first participant in the pilot of the formal test script, a day before the formal tests began.

Weeks 10 to 11 · Documentation reviews

I reviewed each intern's documentation for the hand-off report.

Week 12 · Aug 4 to 5 · Final run-through

A final run-through with the subject matter expert and me, ahead of the Aug 6 presentation.

Weeks 3 to 12 · every week

Every week from kickoff: a review with the subject matter expert and me, and a one-on-one with me for each intern.

At the first review I asked for real results and decisions, plus a rough wireframe by the next check-in, while research was still under way. My rule was progress over perfection. Early sketches show how flows might work and what the research still has to answer, without locking in a solution. From then on, I asked that every review open with the same 15 minutes.

The order I asked every review to open with
15 minof real presentation, in this order, at every check-in
  1. 01

    What we have so far

  2. 02

    The outcome we're heading toward

  3. 03

    What's next

  4. 04 · The point

    The decisions we need to make

“I want to see decisions made by the next check-in.”My notes, first review, Jun 4
My notes from the first review · week 3

First review

My notes · week 3 · Jun 4
Data partner

Product leadership wants to use this project to see which data partner would be the most useful. Which data do we need? What if a client wants a visualization that doesn't exist in the system? There needs to be some kind of feedback system.

Work on things one by one

What are we going to do after the competitive analysis and affinity mapping? Do we have enough information to work on wireframes? Understand whether we have enough to close that phase.

Present findings

This is what we found out and how we can use it to inform our next step. Always look for connections and get the story going from the beginning.

Interviews

Know where the gaps are before you go in. Have a script for when you're talking to people.

Communication

Keep communicating with all product partners about what you're working on, so you have their buy-in. Synthesize together, and include the subject matter expert.

Every meeting

Structure 15 minutes of real presentation in each meeting: this is what we have so far, this is the outcome we're heading toward, this is what's next, these are the decisions we need to make. I want to see decisions made by the next check-in.

Make a wireframe: a quick one of what the main page could look like. It doesn't have to be complex. Let's see how it informs next steps. Sketch ideas by hand.

Progress over perfection

The minimum we can create to get the maximum solution. Treat this phase as research and ideation, with direction. Sketching doesn't mean solutioning, but it helps us see how flows would work and what we'd need in certain areas.

Expectations for Monday
  • Formal synthesis of the affinity map and the competitive analysis
  • A project plan to work from every week (decide what to present each week)
  • Some flows, sketches or wireframes
  • T-shirt sizing to estimate time
Project plan

Come up with objectives and outcomes. Why are you doing each thing? Add dates.

Affinity mapping

What's the objective? Themes are usually broad. What insights are we getting, and how are they informing decisions?

Assumption mapping

What's next? What's the plan to investigate, and what are we getting out of it?
Making the case

The strongest case for the tool was that competing platforms already had one

The team's first draft of the stakeholder research presentation justified the tool with the client requests. I pushed back. A short list of requests tells you which features clients want, but it would not convince leadership to fund a new tool. The stronger argument was the industry standard: competing HR platforms already offered benchmarking, and clients were paying outside vendors to fill the gap.

The argument, before and after

The team's first draft rested the case for a new tool on the client requests.

My pushback. A short list of requests would not convince leadership to fund a new tool.

The final case rested on the market. The requests still mattered: they decided the features.

Before · the team's first draft

The case rests on client requests

Build a salary benchmarking tool
Because
18client requests
Tells you which features clients want. Not why leadership should fund a new tool.
The team's first draft, week 6
After · the case I coached them to make

The case rests on the market

Build a salary benchmarking tool
Because
Competing platformsalready offer benchmarking
Clients pay outside vendorsone about $8,000 a year for salary ranges
Then: client requests decide the features.
From my coaching notes, weeks 5 and 6

I also taught the team to pitch at the level their audience started from, using the ADKAR change model (awareness, desire, knowledge, ability, reinforcement). Most of the room would start at awareness, so the deck had to establish why the problem mattered before it showed any screens. I asked for business value in the terms leadership uses: return on investment, client efficiency and revenue, and the project's objectives and measures.

Pitch from the step where the room starts
  1. AAwareness
    Where most of the room started

    Frame the problem with business needs: why the company wants this tool.

    Most
    Most of the room starts here
  2. DDesire

    Client feedback drives desire: themes first, then direct quotes.

    Most
    Client feedback drives it
  3. KKnowledge

    The business value: return on investment, client efficiency and revenue.

    Some
  4. AAbility

    The proposed solution, and testing it for validity.

    Some
  5. RReinforcement

    Not needed in this presentation.

    None
    Not needed in this presentation
Read from the bottom. From my coaching notes; not slide counts.

The deck followed one arc, from problem to validation, solution, implementation and feedback. I held them to 20 to 40 words a slide, a clear label on every early wireframe saying it wasn't final, and 15 to 20 minutes for questions.

This team was strong at design and wanted to stretch. Much of my coaching that summer connected that skill to the business value the company would pay for.

My coaching notes · weeks 5 and 6

Presentation coaching

My notes · weeks 5 and 6
Week 5 · Jun 20
  • Structure is close. Intros can be brief: names and positions.
  • Users don't need the full piece, because they're part of the solution.
  • Arc: problem statement, knowledge, solution, implementation, feedback.
  • Frame the problem with business needs: why does the company want this tool?
  • ADKAR: awareness, desire, knowledge, ability, reinforcement. Most of the audience is likely starting at awareness, so scale the presentation to where they start.
  • Client feedback drives desire.
  • Add business metrics and impact in terms of return on investment: efficiencies for clients (quality of life, time, reduced workforce) or revenue (cost to build versus price to customer).
  • The product manager decides how much of the solution we need to provide.
  • Ability means providing solutions and testing them for validity. Reinforcement isn't needed in this presentation.
  • Provide overall project objectives and measures.
Week 6 · Jun 24
  • Problem statement, validation, solution, implementation, feedback.
  • Make the stat numbers bigger.
  • Why are we making a whole new tool based on a handful of client requests? Industry standards tell us this is a tool we should already have: competing platforms have it and we don't. The client requests gave us insight into the features that need to be included.
  • Use call-outs with direct quotes: start big with themes, then get specific with quotes.
  • Include resources in an appendix.
  • With an hour, leave at least 15 to 20 minutes for questions.
  • Present flows as features.
Week 6 run-through · Jun 27
  • Break the problem down more. Make room for interaction.
  • Reduce text: people aren't reading the slides. 20 to 40 words a slide.
  • Show the overall flow, then zoom in as you walk through it.
  • Note that it's a desktop-only solution.
  • Make sure the audience knows the early wireframes are not final.
  • Put the graphics next to the key features.
  • State expectations for the audience at the beginning.
  • Point out integrations with other parts of the system.
Cutting to scope

The data source set the edges of the MVP

The team listed 27 assumptions about the business, the users and the interface. Its final tracker followed 24 through research and closed 19 with evidence. Two answers redrew the product. The salary survey reports market averages rather than individual companies, so the tool could compare a role with the market and nothing narrower. Interviews showed that job titles mean different things at different companies, so a benchmark had to match on responsibilities.

27 assumptions, 19 closed with evidence
Two counts from the team's records · one square per assumption
27listed in the team's workshop, about the business, users and interface
24followed in the final tracker: 19 closed, 3 abandoned, 2 on hold
  • Closed with evidence 19
  • Redrew the product 2 of the 19
  • Abandoned 3
  • On hold 2
Two answers that redrew the product
Answer 1

The survey reports market averages, not individual companies.

What it changed

The tool compares a role with the market only.

Answer 2

Job titles mean different things at different companies.

What it changed

Benchmarks match on responsibilities, which is why the job library exists.

The survey's structure decided the inputs. It organizes jobs by title and career level, so those became the two required choices, with location and industry as filters because clients had asked for them. What the data couldn't support moved off the main view. Bonuses and incentives went to a lighter second tab, since no one could confirm what total compensation data the survey would provide. Benefits and comparing two locations side by side waited for a later release, and salary suggestions based on a candidate's skills, which would need AI, moved to future work.

I also decided against a user survey. The need was already clear, and interviews and stakeholder sessions were enough for a project this focused.

What the data could support
Inputs
Results
Integrations
MVPIn the final design
LaterNext steps after the MVP
FutureFuture work
MVPInputs

Job title + career level

The survey organizes its jobs by title and career level, so both became required choices. Together they name one survey role, with its own description of the work.

Select any item for its reason
Design decisions

The team learned to defend each design call with a reason

Each intern sketched alone first. The team then merged the strongest ideas into one set of wireframes and built the final screens on the company's design system. I asked them to write down the reason for every change and what each one gave up, and the final report records that reasoning screen by screen.

The create panel changed after my test of the early prototype. To see a benchmark, a user had to build a set of filters, save it, and then apply it. I asked what happens when someone only wants to try a location without saving anything. The team rebuilt the panel so a user picks a role and filters, sees results, and saves only if they want to. I also flagged that "filter set" wasn't intuitive, and it became Market Filters.

The create panel, before and after my test
Early prototype · week 9
Calculate salary benchmark

Calculate a new benchmark, or view one of your saved benchmarks.

Job title
Product Designer
See job library
Career level
Level 3 (Experienced)
What are career levels?
Market
Manage filter sets
To try a new location
  1. 1Build a filter set
  2. 2Save it
  3. 3Apply it
  4. then see results
Illustrative data.

Other calls followed the same pattern, each written down with its reason and what it gave up.

Other calls, each with its reason

Median in its own card

Compensation teams set range midpoints from the market median, so it stands apart from the other percentiles.

Job library in a side drawer

Survey titles won't always match a company's own. The drawer keeps the user in place, like the rest of the product.

Saved benchmarks are private and named

People use saved benchmarks for different purposes, so each one belongs to the person who saved it and carries a name.

Benchmark groups left the MVP

Testers found groups confusing and had no need for them. The idea moved to a later integration.

Illustrative data.
From the team's report · Median

Median base salary

Final report · design decisions

Research showed median base salary and the other percentiles mattered most. Most companies target the median as their range midpoint, or slightly above or below.

Shown together with the percentiles, the median struggled to be the focal point, so it moved into its own card.
From the team's report · Job library

Job library

Final report · design decisions

The survey's job library is made up of job titles and career levels, combined to create a particular role with a unique description. Survey jobs won't always match a company's jobs, so the job library lets users read descriptions to make sure they benchmark the role they expect.

A modal with a table was dropped after feedback that long descriptions created visual load. The final version is a side drawer, consistent with the rest of the system, with a progressive link into a nested drawer for each role's full description.
From the team's report · Saved benchmarks

Saved benchmarks

Final report · design decisions

For the MVP, benchmarks are private: only visible and editable by the person who saved them.

Naming became required after discussion and feedback, because people use saved benchmarks for different purposes.
From the team's report · Benchmark groups

Benchmark groups

Final report · design decisions

A history tab and benchmark groups were dropped from the MVP: testers had no need for them and found them more confusing than helpful.

Groups moved into a later integration idea.
Testing

I had the team build the prototype around the test's question

The team ran 13 test sessions. Three product designers tried the early prototype, I tested it twice, two more mentors piloted the test script, and six people who set or approve pay tested the final design: a compensation analyst, a talent acquisition lead, two design managers and an executive product leader in the formal test, and a second executive product leader in a follow-up on benchmark groups.

13 sessions
13 6 with people who set or approve pay 2 were mine 5 with designers and mentors
Jul 16 · week 9

Early prototype

  • 01Product designer
  • 02Product designer
  • 03Product designer
Jul 19 · week 9

My session

  • 04Me
Jul 23 · week 10

Script pilots

  • 05Me, first participant
  • 06Subject matter expert
  • 07Mentor
Jul 24-25 · week 10

Formal tests

  • 08Compensation analyst
  • 09Talent acquisition lead
  • 10Executive product leader
  • 11Design manager
  • 12Design manager
Jul 31 · week 11

Follow-up on benchmark groups

  • 13Executive product leader
I took the early prototype in week 9 and the test script in week 10.

My pilot of their script exposed a problem in the test itself. The team had prototyped nearly the whole tool, which took longer to build, caused more build problems, and let users wander into screens the test wasn't about. I had them narrow the test to what they needed to learn and prototype only that flow, and the plan went from six tasks to three. A focused prototype still teaches you something when someone clicks off the path. It also gets people narrating their own expectations, the "I guess the direction I thought isn't the right one" moment a facilitator can follow up on.

The test plan, before and after my pilot
Before · the week 9 prototype

6 tasks, across nearly the whole tool

  1. Create a benchmark using the job library
  2. View it
  3. Save it
  4. View a saved benchmark
  5. Edit it
  6. Group benchmarksOut of the test; a follow-up session in week 11
After my pilot · week 10

3 tasks, one flow, one prototype

  1. Create a benchmark and save itWas tasks 1 to 3
  2. Open a saved benchmarkWas task 4
  3. Edit itWas task 5
"Just build the prototype for the flow you're trying to test."My advice to the team after piloting their script · week 10

The team scored each step across five users. Saving and reopening a benchmark scored 5 of 5. The percentile calculator and the total compensation tab scored 1.5, and confirming an edit scored 1. Each low score got an owner and a fix: plainer labels, a percentile explainer, a preview step before an edit is saved, and a confirmation after saving.

Task scores across five users
Task 1Create a benchmark and save it
Went to Create a Benchmark4
Entered location and industry4.5
Found the median5
Read the percentiles3
Found the survey info4
Historical chart5
Career level and year comparison4
Saved a benchmark5
Task 2Open a saved benchmark
Went to saved benchmarks5
Chose the right benchmark5
Task 3Edit it
Found edit5
Edited the benchmark5
2 or lessAbove 2FixSelect to see what changedFull completion = 1, partial = 0.5
Select a step marked Fix
The team logged 16 problems from testing, 3 high, 6 medium, 4 low and 3 quick fixes, and gave each one an intern owner.
"All the information they need in one place. The user doesn't need to go outside of the system."Tester · user testing
"Very clean interface. Overall easy to understand and intuitive."Tester · user testing
Notes from my two test sessions · weeks 9 and 10

Notes from my two test sessions

Early prototype, week 9 · test script pilot, week 10
Week 9 · Jul 19 · early prototype

Tasks: create a benchmark using the job library, view it, save it, view a saved benchmark, edit it, group benchmarks.

  • Entry page tabs: consider whether we actually need them.
  • When you click the filter set, it should say "No filter sets created" and "New filter set".
  • "Filter set" isn't intuitive, because all the filters (job title and career level) fall under it. Fix the wording. Is "market" more user-friendly?
  • What if someone just wants to build a benchmark for the first time, or test a location without saving a filter set? Right now: build it, save it, then use it in the widget. Consider: build it, use it, and offer to save it after. Maybe we don't need the filter set at all.
  • Team note: at 34 minutes we were walking him through the prototype instead of him going through it himself.
  • Saved benchmarks: split screen, showing what you've saved beside a detailed view of one, like a project-tracking dashboard or an email inbox. Let me choose the columns I see. Edit benchmark should go to benchmark creation.
Week 10 · Jul 23 · pilot of the formal test script

I was the first participant.

Design
  • Make career levels optional, to show all product designers.
  • Add a confirmation after saving a benchmark.
Testing
  • Narrow your focus to what you're trying to validate: build something that lets them reach the part of the prototype under test without doing too many things.
  • Just build the prototype for the flow you're trying to test.
  • The task may be too big; give them more time to explore.
  • Ask more questions about what they see on the outputs page.
What the team observed
  • He went straight to Create a Benchmark and skipped the job library.
  • He wasn't sure how the survey's career levels matched the company's own.
  • He expected to reach saved benchmarks from the filters panel.
  • He read the filter chips as editable.
  • He wasn't sure whether applying an edit saved it.
Looking back · Oct 2026

The team had built an overly complex prototype that took more time and caused more problems than one built around the test's objective. If users click on parts of the prototype outside the objective, that tells you enough about the flow. A focused prototype keeps people from getting lost or going down a rabbit hole, and it leads to more self-narration ("I guess the direction I thought isn't the right one") that you can follow up on.
Solution and hand-off

Product management got a design it could take to leadership

In the final design, a user picks a role from the survey's job library or from two drop-downs, narrows it with market filters, and sees the median base salary, a percentile calculator, the spread of salaries, the median over time and a comparison across career levels. Total compensation sits on a second tab. Benchmarks can be saved, named, edited with a preview and exported.

The final design, annotated
    Illustrative data. Run it in the prototype ↓

    In week 12 the team handed product management a report, every final screen specified at four screen widths with spacing and component specs tied to the design system, and a guided prototype that walks through each feature and why it exists. The report's next steps included a dashboard widget counting salary grades above and below the market median, a way to push a benchmark into a new position, and four models for who can see what. The product manager said the findings and deliverables were what let them take the project to leadership and get it prioritized.

    What the team handed off · select one to see a sample
    Sample
    After the hand-off

    Development was never the goal of the program. The product manager planned to fold the tool into the compensation roadmap, with its own build and release strategy.

    The final prototype · four tasks, clickable

    The hand-off included a guided prototype. This version runs the same flows, rebuilt with illustrative data.

    Illustrative data. Esc or “Back to case study” returns here.
    Illustrative data