How do you design a secure, trust-sensitive feature when engineering rules out your best solution from day one?
2020 · 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.
Trust had to be designed in
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,” and made the template’s locked state explicit so no one could edit a live template by mistake.
"Publish" made users think their salary data was going public. Five rounds of testing later: "Available to Run"
With no room for onboarding anywhere else, the conversion was dialog was the only moment to explain what a template was. The first version left users confused. After many revisions, the final one tells them plainly what a template does, and that their data stays private. Users had to check “Got it” before Convert became active, ensuring they would read the list before converting.
With no onboarding, this dialog had to explain templates. The old version left users confused. The final one makes it clear that their data stays private.
"Works like magic"
Templates shipped to production and compensation planning processes that previously took days were reduced to under an hour.