Short answer
Qualitative people analytics turns employee accounts into decision evidence through a documented research method. Define the decision, select relevant participants, use open and neutral questions, preserve source context, code consistently, examine disagreement and missing voices, test alternative explanations, and assign any action an owner and review date.
Start with a decision, not a listening theme
“Understand employee experience” is too broad to guide useful research. A stronger brief names the decision and the work context.
| Brief field | Example |
|---|---|
| Decision | Whether to revise the first six weeks of supervisor onboarding |
| Business context | Two distribution sites introduced the same operating model |
| Research question | Where do new supervisors lack the knowledge or authority to handle common exceptions? |
| Population | Recent supervisors, experienced supervisors, direct reports, and site support roles |
| Variation to include | Site, shift, previous experience, and internal or external hire |
| Evidence already held | Training records, operating exceptions, role materials, and workforce metrics |
| Output | Findings, evidence excerpts, contradictions, limits, and possible tests |
| Excluded use | Individual performance rating or departure prediction |
| Decision owner | Operations director with the people lead |
Quantitative data can show where a pattern sits or how often a recorded event occurs. Qualitative research can explore how the work happens, what a term means locally, which conditions change the experience, and why people disagree. It does not make causal claims automatically.
The people analytics beyond dashboards guide starts from a metric and moves toward a decision. This guide covers the deeper research step when the organisation needs to understand mechanisms, language, and context.
Choose participants around relevant variation
Qualitative selection is purposeful. The aim is to hear from people who can illuminate the research question and the different conditions around it. It is not a miniature opinion poll.
Build a sampling map:
| Dimension | Why it may matter | Planned coverage | Actual coverage |
|---|---|---|---|
| Role | Experiences and decision authority differ | New supervisors, experienced supervisors, direct reports | Complete after recruitment |
| Site or region | Workflows and local constraints differ | Comparable sites in the decision | Complete after recruitment |
| Shift or work pattern | Access, handovers, and support differ | Day, night, weekend where relevant | Complete after recruitment |
| Tenure or transition | Needs change over the employee journey | Defined bands or moments | Complete after recruitment |
| Participation route | One channel may exclude a group | Live, phone, text, accessible options | Complete after recruitment |
Do not call the findings representative of a workforce merely because every selected participant had an invitation. Document eligible, invited, participating, declining, and unreachable groups. If a relevant population is absent, state the gap and decide whether to recruit differently, narrow the claim, or stop.
Avoid selecting only high performers, managers recommended by leaders, employees with corporate email, or people known to be enthusiastic. Those groups may be relevant, but the selection rule and its consequences must remain visible.
Prepare a discussion guide
The GOV.UK guide to in-depth interviews recommends a consistent discussion guide, open and neutral questions, follow-up for stories and real examples, and enough flexibility to let the conversation develop.
A useful guide moves from experience to mechanism:
- Context: Tell me about your role and the part of the work relevant to this topic.
- Recent example: Walk me through the last time this happened.
- Sequence: What happened before, during, and after?
- Conditions: What made it easier or harder in that situation?
- Variation: When does the process work differently?
- People and tools: Who or what helped, and where was support missing?
- Interpretation: What do you think explains the difference?
- Alternative: Is there another explanation we should check?
- Change: What small change would be worth testing?
- Correction: What have I misunderstood or failed to ask?
Avoid “Would better training solve this?” because it embeds the desired answer. Ask “What did you need at that moment?” and let training, authority, staffing, information, tools, or another mechanism emerge from the account.
Use the same core topics across participants so analysts can compare material. Add role-specific probes only where they serve the research question.
Explain participation and data handling
Tell participants who is running the work, why, what will happen, what will be recorded, how outputs will be used, who may see them, and what can be withdrawn under the applicable process. Explain confidentiality and escalation boundaries in plain language.
The GOV.UK informed-consent guide says participants should understand the purpose, data collected, use and sharing, voluntary nature, recording, retention, and complaint route. Employment and jurisdiction change the legal assessment, so people, legal, and data-protection owners should approve the actual basis and notice rather than copying a research template uncritically.
Collect only the material needed for the question. The GOV.UK participant-privacy guidance recommends purpose-bound use, restricted access, a retention period, and careful treatment of notes, recordings, and sensitive information.
Do not promise anonymity if researchers know the participant or if a quotation can identify them from context. Agree how quotations, paraphrases, and small groups will be handled.
Create an evidence record before themes
Separate what was observed from what the analyst thinks it means:
| Field | Entry |
|---|---|
| Source ID | P07, linked to restricted participant records where needed |
| Context | Site, role, shift, journey moment, and relevant event |
| Source segment | Exact or agreed wording |
| Observation | What happened or was said, without interpretation |
| Code | A defined descriptive label |
| Analyst note | Possible meaning or mechanism |
| Contradiction | Evidence that does not fit the emerging finding |
| Route | Research, case process, safety, payroll, or another owner |
The GOV.UK analysis guide advises recording what was seen or heard separately from what it means, then organising observations into findings and actions. That distinction is especially important in workforce research, where an interpretation can affect a team or manager.
Code in two passes
In the first pass, use descriptive codes close to the material:
- unclear exception approval;
- delayed system access;
- peer demonstration;
- conflicting work instruction;
- schedule change;
- manager availability.
In the second pass, examine possible mechanisms across those codes:
- unclear decision rights;
- knowledge held informally;
- access dependency;
- handover inconsistency.
Keep a codebook with definitions, inclusion and exclusion examples, changes, and dates. Allow one segment to carry more than one descriptive code where needed. Recode earlier material when a definition changes materially.
Use more than one reviewer on a varied sample. Discuss disagreement rather than averaging it away. A difference may reveal an unclear code, missing context, or a real alternative interpretation.
Search deliberately for:
- cases that do not fit the emerging pattern;
- groups missing from participation;
- examples where the same condition produced a different outcome;
- changes in meaning across roles, sites, languages, or time;
- evidence that the apparent mechanism belongs to a different process.
Do not claim “saturation” simply because interviews stopped producing new headline themes. State what the team heard, from whom, in which context, and what remained uncertain.
Turn a theme into a finding
A finding should contain more than a label:
| Finding part | Example |
|---|---|
| Claim | New supervisors at the two studied sites described uncertainty about exception approvals |
| Evidence | Accounts from multiple roles plus examples of delayed decisions |
| Variation | Experienced internal hires knew informal contacts; external hires did not |
| Contrary case | One night-shift team used a written escalation card successfully |
| Coverage limit | Weekend direct reports were underrepresented |
| Alternative explanation | System access delays may create similar uncertainty |
| Decision implication | Test whether a visible escalation route reduces delay |
“Role clarity is a problem” is a theme label. The expanded finding tells a decision owner what to test and what not to assume.
Fictional worked example
Northstar Fulfilment is a fictional UK and US business investigating supervisor onboarding at two sites. Researchers interview new supervisors, experienced supervisors, direct reports, and site support staff. Weekend direct reports are difficult to recruit, so that limitation is recorded.
Initial coding produces a broad “training gap” theme. A negative-case review changes the interpretation. One night-shift team reports few problems despite using the same formal training. Its experienced coordinator gives every new supervisor a handwritten escalation map.
The researchers return to the source material. The repeated problem is not lack of course content alone. New supervisors describe not knowing who can approve unusual staffing, customer, or equipment decisions. System access delays contribute in some cases.
The action brief reads:
| Field | Decision |
|---|---|
| Finding | Several new supervisors lacked a visible exception route |
| Evidence | Cross-role examples at both studied sites |
| Limits | Weekend coverage low; no causal estimate |
| Test | Provide one controlled escalation map and named owner |
| Comparison | Track the same exception categories before and after the test |
| Qualitative follow-up | Ask the next cohort when the map helped or failed |
| Owner | Site operations lead |
| Review | Continue, change, or stop after the next cohort |
The study does not conclude that the map will improve retention or performance. It identifies a mechanism worth testing and a contrary case that made the proposed action more specific.
Use AI without losing the evidence trail
AI can help transcribe, search, suggest descriptive codes, retrieve related passages, and compare code applications. The research team remains responsible for the question, participant selection, source quality, codebook, interpretation, privacy, escalation, and decision.
For every assisted finding, reviewers should be able to:
- inspect the source segment;
- see which codebook version was used;
- distinguish employee wording from generated summary;
- correct the label or summary;
- find contradictory material;
- identify the model and processing step;
- prevent an individual research statement from becoming an employment score.
When a guided conversation is useful for a defined research question, review the Lontra product approach after completing the brief and governance design. Verify participant access, supported languages, source review, permissions, escalation, export, deletion, and fit with existing research systems.
Good qualitative people analytics narrows uncertainty enough to support a better test or decision. It does not turn a collection of vivid stories into proof, flatten disagreement into a theme count, or claim that an interview sample speaks for everyone.