Qualitative HR Data: Examples, Structure, and Governance

Short answer

Qualitative HR data includes employee language, examples, observations, and narratives that explain how work is experienced or performed. Make it usable with a purpose-specific record: preserve provenance and context, separate source from interpretation, minimise identity, restrict access, define retention and deletion, record corrections, and link findings to accountable decisions.

Examples of qualitative HR data

Qualitative data is defined by the kind of evidence it carries, not by whether it sits in a spreadsheet.

A rating with an open explanation creates both quantitative and qualitative data. A transcript may contain identifiers and special-category information as well as research material. A theme label generated from comments is derived data, not the employee's original account.

Treat each layer according to its purpose and risk.

Use a data contract before collection

A data contract states what the dataset means and how it may be used.

Do not write “employee experience improvement” as the only purpose. It is too broad to guide minimisation, access, or a decision. “Understand where the new store-manager handover fails so operations can test a revised transition” is specific enough to design a dataset.

Preserve provenance

Provenance lets a reviewer trace a finding back through the transformations applied to it.

Use separate fields for:

1. Source segment: the exact or agreed employee wording.
2. Context: the question, role, location, language, event, and time needed to interpret it.
3. Translation: translated text and the method or reviewer used.
4. Observation: what the segment directly describes.
5. Code: a descriptive label from a versioned codebook.
6. Summary: a concise interpretation, clearly marked as derived.
7. Uncertainty: ambiguity, missing context, or conflicting evidence.
8. Human review: reviewer, date, correction, and reason.
9. Decision link: where the evidence was used, by whom, and with what other material.

Without this separation, a generated summary can become indistinguishable from the employee's words. A model or analyst may simplify “The new system is quicker, except when a return needs a supervisor after six” into “positive system sentiment.” The summary loses the actual exception.

Store the least identity needed for the purpose. A participant key can preserve restricted traceability without putting a name into every analytic table. Removing a name does not necessarily make the material anonymous. Job title, site, event, and a distinctive quotation may still identify someone.

Set access by data layer

One access rule rarely fits every layer.

Managers do not need raw conversations merely because the topic concerns their team. A broad leadership audience usually needs a bounded finding, coverage statement, evidence examples that do not expose contributors, and a decision brief.

For UK processing, the ICO's worker data guidance emphasises a defined purpose, transparency, minimisation, accuracy, retention, security, and the ability to consider challenges to potentially adverse information. It also warns that analytic tools can make incorrect inferences about workers. Review the actual programme with data-protection and employment advisers because purpose, collection method, jurisdiction, and employee relationship affect the requirements.

For US operations, applicable privacy, employment, labour, safety, discrimination, and sector rules vary. The data contract should identify the relevant owners and routes rather than claiming one global consent or compliance formula.

Define retention and deletion by layer

“Keep insights forever” is not a retention rule. Source recordings, transcripts, coded excerpts, aggregated findings, and decision records serve different purposes.

For each layer, record:

• the reason it is retained;
• the start event and review date;
• the deletion or anonymisation action;
• any required hold or case exception;
• the system owner;
• downstream copies and exports;
• how corrections and applicable requests propagate.

The GOV.UK guidance on managing research data recommends collecting only what is needed, restricting access, defining a retention period, organising records so specific participant material can be found, and using material only within its stated purpose. An employer should approve its own lawful process, but the operational lesson is useful: deletion fails when the organisation cannot find the source and its copies.

Check data quality before counting themes

Qualitative data quality is more than spelling or transcript accuracy.

Do not call theme counts prevalence unless the collection and coding support that claim. Ten mentions can come from ten employees, one long group, repeated follow-ups, or duplicated records. Count the unit you defined and display its denominator and coverage limits.

AI can help transcribe, retrieve, code, summarise, and check consistency. The NIST AI Risk Management Framework core calls for documented scope, representative and suitable data, human oversight, generalisability limits, and contextual interpretation. Maintain model and prompt version, source links, review status, corrections, and known failure modes for assisted fields.

Fictional worked example: from comment to decision

Eastborough Care is a fictional UK organisation reviewing the transition from clinical expert to team leader. It collects voluntary interviews from a defined cohort and links only approved context fields.

One participant says:

I knew the clinical side, but on the first weekend I did not know who could approve extra cover.

The record is structured as follows:

Several participating leaders describe similar uncertainty. The team checks onboarding materials and finds that the on-call card exists but is not included in the transition pack. This does not prove that the missing card caused staffing outcomes or resignations.

The decision owner tests one change: add the controlled on-call card to the transition and ask the next cohort to use it in a scenario. The review combines scenario results, operating exceptions, and voluntary feedback. The finding, source, contrary case, action, owner, and review date remain linked.

A procurement data-flow test

Ask a vendor to demonstrate one record from invitation to deletion:

1. How is the purpose shown to the employee?
2. Which identity and context fields are collected?
3. Where are recordings, transcripts, translations, codes, and summaries held?
4. Can a reviewer see source and derived text side by side?
5. Who can view raw, identifiable, coded, and aggregate layers?
6. How are urgent matters separated and handed to the proper route?
7. How are model versions, corrections, and reviewer actions recorded?
8. What happens to exports and integrations after a correction or deletion?
9. Which retention rules apply to each layer?
10. Can individual analysis be excluded from employment decisions by design and policy?

If guided conversations are one approved source, review the Lontra product approach against this data-flow test. Verify identity, group access, source and derived records, languages, routing, export, retention, deletion, and integration behaviour in the proposed deployment.

Qualitative HR data becomes useful when a reviewer can see what was said, why it was collected, how it changed through analysis, who may use it, and which decision followed. Structure should protect that chain without pretending a theme is a fact about an individual.