ROLE:
LEAD PRODUCT DESIGNER
TIMELINE:
DEC 2025 - FEB 2026
SKILLS:
DESIGN, RESEARCH
ABOUT
When Lattice sunsetted its HRIS product, we made a strategic decision. Instead of competing as a system of record, we would double down on Talent and integrate seamlessly with leading HRIS platforms.
Workday was the first and most critical partner. The risk was clear: If Lattice-generated performance data could not reliably live in Workday, customers would consolidate.
Churn analysis showed:
~50% of Workday-related churn cited consolidation
22 enterprise accounts ($3.5M+ ARR) cited integration/data gaps
CHALLENGE
When I was asked to flex onto the Integrations team, designs were already moving toward development under an active Workday partnership timeline. The work needed to ship, but the structure wasn’t built to scale.
All of this unfolded during an HRIS strategy pivot and team instability, requiring rapid ramp and structural clarity under pressure.
PROCESS
1. Clarified the Mental Model
The existing model was direction-based: Lattice → Workday, Workday → Lattice. Technically could work, but I immediately felt it wasn't scalable based on what our future Integrations strategy (bi-directional, multi-domain).
Even though Phase 1 was outbound-only, I proposed shifting to a domain-based integration model: Performance, People Data, Compensation, Goals, etc. This would keep IA stable as additional sync functionality is introduced.
2. Reducing workflow ambiguity
When I joined, the sync set up process (what cycle, what data, maps where) was in all in one dense, screen.
I restructured the experience into a clear, sequential flow:
Select review cycle(s)
Choose what review questions to sync
Map Lattice fields to Workday fields
This reduced cognitive load and made each decision explicit. Instead of scanning a settings page, admins move through a structured sync setup with clear intent at every step.
3. Making Data Mapping Explicit and Safe
What we learned
Admins think in terms of review cycles, not question categories
Admins typically sync only 2–3 targeted ratings, not full review templates
Question type (competency, growth area, goals) rarely affects their decisions
The original mapping table surfaced everything at once. Each rating appeared twice (pre- and post-calibration), and content was organized by question type. This made the surface dense, repetitive, and harder to parse.
What I changed
Grouped questions by review cycle
Separated data selection from data mapping, so admins first choose what to sync
Consolidated calibration into columns instead of duplicate rows
Removed question-type tabs and added lightweight icons for context
The result was a mapping surface that felt more deliberate and readable.
4. Designed a trustowrthy Sync Log
The initial design only surfaced success and failure as flat states without enough context to diagnose issues.
Admins needed to answer questions like: Did this sync fully complete? Which employees were skipped? Why did values fail? Is it safe to rerun?
I redesigned the sync log to:
Elevate run-level state (Success, Partial, Failed) clearly at the top
Separate summary metrics (updated, skipped, failed) from row-level detail
Make employee-level errors explicit and human-readable
Scale to log multiple runs of the same sync
This shifted the sync log from passive reporting to an operational tool admins can trust and act on.
Tradeoffs
Speed vs Structural Stability
We could have shipped a narrow ratings export.
Why: We invested in a domain model that prevents future re-architecture.
Technicality vs Admin Mental Model
We went with the latter.
Why: Domain-based IA reflects how HR leaders think and operate.
Automation vs Administrative Control
We chose manual/scheduled sync to to tackle first.
Why: To preserve oversight in sensitive workflows as we gain trust.
Speed vs Friction
We opted for a longer setup process to confirm trust and clarity.
Why: High stakes workflows should have breathing room.
Impact
I ramped quickly into a new domain, audited the existing direction, and pivoted the approach before it solidified in code.
Although still in Beta, this work:
Establishes a scalable integration architecture
Protects enterprise accounts from consolidation risk
Enables expansion to Rippling, HiBob, and future providers
