How do you design a secure, trust-sensitive feature when engineering rules out your best solution from day one?
Workday · Senior Associate Product Designer · Shipped
An acquired product with something to prove
Worksheets was the flagship product of a startup acquired by Workday — a native spreadsheet tool competing directly with Excel. Templates was one of several use cases being pursued to demonstrate the acquisition's value.
Identifying knowns and unknowns after initial research
A painful process, repeated every cycle
HR admins were running compensation planning in Excel: manually slicing data for each manager, distributing files through SharePoint, and repeating the whole process every cycle — all to keep sensitive salary data from reaching the wrong person. They wanted to build a compensation model once and distribute it, with each manager seeing only their data. The engineering reality made the obvious solution impossible.
Our goals were straightforward
01
Never expose sensitive data
02
Preserve formulas, modeling and workbook structure
03
Make distribution simple
The ideal solution was technically impossible
Workday's architecture made it impossible to create a spreadsheet with live data that wasn't the author's actual data. That meant the template would always contain real compensation data — and we had to design an experience that got users to trust it wouldn't be shared with people who shouldn't see it.
Two constraints made this harder:
Security model conflict. Worksheets worked like Google Sheets — share with anyone. Templates required the opposite: a new paradigm where the worksheet respected Workday's permission model, with no onboarding UI to explain it.
40 pixels. Workday's header consumed a quarter of vertical screen height. Our entire template status system in Worksheets had to live in roughly 40px.
Progress required a hard reset
With 15–20 stakeholders across three product teams, alignment was a constant battle — terminology debates stalled progress for months. The design team formally pushed back on a direction we believed was driven by risk mitigation rather than user needs. That intervention led to a focused task force with real decision-making authority, which finally broke the deadlock. From there we ran focused usability testing and validated a solution we could stand behind.
The task force that broke the deadlock — a smaller group with real decision-making authority, after weeks of 15–20 person alignment sessions going nowhere.
One word was breaking trust
Any language around "publishing" triggered fear — users assumed their compensation data was being exposed. After 5+ rounds of testing, we landed on "Available to Run" — language that made the state's functional meaning explicit without triggering data exposure anxiety.
"Publish" made users think their salary data was going public. Five rounds of testing later: "Available to Run"
"Works like magic"
Templates shipped to production. Compensation planning processes that previously took days were reduced to under an hour. Post-launch feedback: "Works like magic."
