Feedback taxonomy

The question it helps answer

Use the feedback taxonomy to organise the reasoning behind this question: How should themes, requests, examples, bugs, and business impact be classified consistently? The working view makes hierarchy, definitions, and inclusion rules visible so discussion can move from general opinion to a specific action or decision.

When to use it

Use the feedback taxonomy when people working on feedback and customer insight are using different mental models for hierarchy, definitions, and inclusion rules, and that difference is changing choices or coordination.

What it is

The feedback taxonomy is a set of connected concepts for examining one situation from several necessary angles. Its core working elements are hierarchy, definitions, inclusion rules, and examples. Those elements belong together because each changes how the others should be interpreted or acted on.

Core elements

Hierarchy

Capture hierarchy only at the level needed to answer: How should themes, requests, examples, bugs, and business impact be classified consistently? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the feedback taxonomy, connect this entry to definitions so the relationship can be reviewed rather than inferred.

Definitions

Capture definitions only at the level needed to answer: How should themes, requests, examples, bugs, and business impact be classified consistently? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the feedback taxonomy, connect this entry to inclusion rules so the relationship can be reviewed rather than inferred.

Inclusion rules

Capture inclusion rules only at the level needed to answer: How should themes, requests, examples, bugs, and business impact be classified consistently? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the feedback taxonomy, connect this entry to examples so the relationship can be reviewed rather than inferred.

Examples

Use a short fictional scenario to show how the structure changes a choice or action. Keep the example neutral and label any illustrative values as examples. Within the feedback taxonomy, connect this entry to ownership so the relationship can be reviewed rather than inferred.

Ownership

Assign one accountable owner and distinguish final accountability from contributors, reviewers, and people who must be informed. Within the feedback taxonomy, connect this entry to change control so the relationship can be reviewed rather than inferred.

Change control

Capture change control only at the level needed to answer: How should themes, requests, examples, bugs, and business impact be classified consistently? Use observable evidence, name any unresolved judgment, and state what action or choice this entry can change. Within the feedback taxonomy, connect this entry to quality checks so the relationship can be reviewed rather than inferred.

Quality checks

Define the standard before judging the work, and make each criterion specific enough for two reviewers to apply consistently. Within the feedback taxonomy, connect this entry to change control so the relationship can be reviewed rather than inferred.