A Continuous Discovery Model
Continuous Discovery Across Complex Enterprise Workflows
I built a continuous discovery model for complex payroll and HCM experiences, connecting customer interviews, usability testing, support themes, product data, and cross-functional expertise to help teams make better decisions under significant operational, technical, and compliance constraints.
Project Overview
Payroll and HCM products serve users with very different responsibilities, environments, and levels of expertise.
A single workflow may affect:
Payroll administrators
Business owners
Managers
Employees
Implementation teams
Support teams
Compliance stakeholders
Product and Engineering teams
Their needs often conflict.
Experienced administrators may value speed and dense information, while infrequent users need guidance and reassurance. Product teams need to deliver quickly, while payroll accuracy, permissions, compliance, accessibility, and legacy-system constraints leave little room for error.
At the same time, customer insight existed across interviews, support conversations, implementation feedback, product data, sales input, and internal expertise—but it was not consistently connected to product planning.
The challenge was to create a repeatable discovery loop that gave teams enough evidence to make better decisions without turning research into a slow, separate phase.
The challenge
I led the development of the research and discovery operating model across interconnected payroll, people, navigation, time and attendance, onboarding, and scheduling experiences.
My responsibilities included:
Defining the research approach and priorities
Partnering with an external research team
Recruiting and segmenting customer participants
Reviewing research plans and discussion guides
Participating in interviews, synthesis, and debriefs
Connecting insights to product strategy and roadmap decisions
Helping teams distinguish user evidence from internal assumptions
Balancing research depth against delivery timelines
Integrating Product, Engineering, Support, and customer-facing perspectives
Establishing repeatable discovery and validation loops
My role + What I LED
I structured discovery as a continuous loop rather than a one-time research project.
1. Frame the decision
Before selecting a method, we clarified:
What decision must the team make?
What do we already know?
What are we assuming?
What carries the greatest customer or business risk?
What evidence would materially change the direction?
This prevented teams from conducting research without a clear decision in mind.
2. Identify the relevant user segments
The platform served customers with substantially different:
Company sizes
Product configurations
Roles and permissions
Operational models
Technical comfort levels
Workflow frequency
Implementation histories
We avoided treating “the customer” as one uniform group.
Participant selection reflected the workflow and decision being studied, including differences between administrators, managers, employees, and customer organizations using different combinations of products.
3. Combine evidence sources
No single research source was sufficient.
We brought together:
Customer interviews
Employee interviews
Usability testing
Support themes
Implementation feedback
Customer-facing team input
Churn and retention signals
Adoption and usage data
Existing research
Product and domain expertise
This helped distinguish isolated preferences from recurring experience problems.
4. Synthesize around workflows and decisions
Instead of organizing findings only by interview question, we synthesized around:
User goals
Workflow stages
Pain points
Decision points
Workarounds
Risks
Differences between segments
Opportunities for simplification
Implications for product strategy
Insights were documented in shared artifacts such as research summaries, rainbow sheets, repositories, journey views, and decision-oriented readouts.
5. Translate findings into product action
Each insight was connected to one or more actions:
Validate an existing direction
Revise a workflow
Change information architecture
Simplify terminology
Add guidance or system feedback
Address an unmet need
Investigate a segment difference
Update the roadmap
Create a new usability hypothesis
Defer a lower-value feature
This ensured research changed decisions rather than simply producing documentation.
6. Test and iterate
Concepts moved through progressively higher-fidelity validation:
Workflow sketches
Journey maps
Early prototypes
Task-based usability testing
Stakeholder and domain review
Engineering feasibility review
Refined prototypes
Post-launch feedback and product signals
The loop continued as new evidence emerged.
THE DISCOVERY MODEL
Next Up
McDonald's
Customer constraints
Different roles and permissions
High-frequency and infrequent users
Varying technical confidence
Established workarounds
Different product configurations
Business constraints
Retention and cross-sell priorities
Delivery commitments
Product positioning
Customer-segment value
Implementation and support costs
Technical constraints
Legacy architecture
Existing data models
Shared platform dependencies
Design-system maturity
Engineering capacity
Operational constraints
Limited participant availability
Research recruiting complexity
Multiple product teams
ADO and Jira workflows
External design and research partners
Risk constraints
Payroll accuracy
Compliance
Permissions
Accessibility
User trust
Cost of workflow failure
THE CONSTRAINTS
I used four questions to guide decisions:
1. What is the user consequence?
Would the issue create confusion, delay, financial risk, loss of trust, or task failure?
2. How broadly does it apply?
Is this a recurring need across segments or a specialized case requiring flexibility?
3. What is the reversibility?
Can the decision be adjusted later, or would it create expensive architectural or behavioral lock-in?
4. What is the time-to-value?
What is the smallest meaningful improvement that gives customers value while preserving a path toward the stronger long-term experience?
This framework helped teams avoid two common extremes:
> Oversimplifying the product by ignoring real operational variation
> Overengineering the interface around every possible edge case
How I made tradeoffs
Discovery was not owned by Design alone.
I brought together:
Product managers to clarify strategy and business priorities
Engineers to identify technical constraints and opportunities
Researchers to structure evidence and reduce bias
Support and implementation teams to surface recurring real-world issues
Customer-facing partners to improve recruiting and contextual understanding
Designers to translate findings into workflows and prototypes
Leadership to connect insights to roadmap investment
By involving these groups throughout the loop, we reduced late-stage disagreement and created shared ownership of the problem.
Cross-FUNCTIONAL
COLLAB
Discovery was not owned by Design alone.
I brought together:
Product managers to clarify strategy and business priorities
Engineers to identify technical constraints and opportunities
Researchers to structure evidence and reduce bias
Support and implementation teams to surface recurring real-world issues
Customer-facing partners to improve recruiting and contextual understanding
Designers to translate findings into workflows and prototypes
Leadership to connect insights to roadmap investment
By involving these groups throughout the loop, we reduced late-stage disagreement and created shared ownership of the problem.
The discovery model helped the organization:
> Bring customer evidence into roadmap conversations earlier
> Recognize meaningful differences between customer segments
> Identify workflow risks before development
> Improve alignment across Product, Design, Engineering, and customer-facing teams
> Make research more repeatable and decision-oriented
> Validate concepts through iterative testing
> Connect tactical usability findings to broader product strategy
> Build a stronger foundation for UX health indicators
