How to Set Findability Goals for a Media Library
Findability goals describe who must retrieve which known item, through which route, under which constraints, and what counts as success.
In short: Write goals as retrieval tasks: a named person must find a known item from a defined starting point using an expected route and within a reasonable household-defined effort. Cover search, browse, versions, languages, profiles, and unavailable items. Test the same tasks before and after organisation rather than rating how tidy the library looks.
Findability is the practical outcome of organisation. Categories and metadata are only useful when they help the right person reach the right item with enough confidence to choose it.
Replace vague goals with observable tasks
“Improve search” does not say what should change. Use this structure:
[Person/profile] can find [known item or type] from [starting screen] using [allowed route], and can confirm [critical distinction] before opening it.
Examples:
- find an exact film title from TV search and distinguish two versions;
- browse to an unfinished series from a profile's continue-watching area;
- filter candidates by a required language, then verify the actual track;
- find a favourite on a second supported device;
- identify that a selected version is unavailable before pressing play.
These are proposed tests, not claims about a result.
Choose goals from household needs
Interview each regular viewer with three questions:
- What do you most often fail to find?
- Which screen and input method are you using then?
- What information tells you that you found the correct version?
A TV remote user may need short browse paths and visible focus. A mobile user may prefer filters. A multilingual viewer may need audio and subtitle evidence. Map these differences with the household viewing needs worksheet.
Cover six retrieval dimensions
Exact identity
Can the user find one known title, episode, or recording by its expected name?
Category context
Can the user reach an item through a category whose label has a stable household meaning?
Version distinction
Can the user tell two source variants apart before playback?
Language evidence
Can the user narrow candidates and then verify actual audio or subtitle options? Language filters are not proof that every track exists.
Personal state
Can the correct profile find its favourites, history, or unfinished items without another person's state taking over?
Availability
Can the user understand when a selected source version is unavailable and inspect alternatives without confusion?
Define a fair effort threshold
Do not invent a universal time target. Choose a household threshold appropriate to the input method and task. Record:
- maximum number of screens or major route changes;
- whether typing is allowed;
- whether the user may know the category;
- what counts as an error;
- whether assistance invalidates the test.
The purpose is repeatability, not competitive benchmarking.
Connect metadata to a retrieval need
Dublin Core defines general terms including title, type, language, source, relation, and rights. A personal collection does not need to implement the full specification. Use a field only when a retrieval task depends on it.
For example, adding a language field is worthwhile when viewers routinely need it. Adding an unused descriptive field creates maintenance without improving findability. Set those rules before migration with the pre-import metadata guide.
Original evidence: retrieval acceptance sheet
| User/profile | Target | Start | Route | Critical distinction | Result |
|---|---|---|---|---|---|
| TV home / Library / Search | Version / Language / Availability | Pass / Recheck | |||
| Pass / Recheck | |||||
| Pass / Recheck |
Run each task before changing the library and record the obstacles. Repeat after a pilot. Count only observed errors, route changes, and assistance. Use the library success measures guide to interpret the results without turning one session into a universal claim.
Common mistakes and limitations
- Measuring visual neatness instead of retrieval.
- Testing only the organiser rather than regular viewers.
- Choosing unknown items with no expected answer.
- Treating a search result as proof of the correct version.
- Setting one universal speed target for remote, touch, and keyboard.
- Adding metadata with no linked use case.
- Changing the test between baseline and retest.
Source metadata limits what an organiser can display. Norva can organise a compatible authorised source but cannot invent missing titles, categories, tracks, or relationships.
Frequently asked questions
How many goals should I set?
Start with three to six essential tasks covering the household's common and costly failures. Add more only when the first set is stable.
Should speed be the main measure?
Not always. Correct version choice, independence, confidence, and error recovery can matter more than a few seconds.
What if a goal fails because source metadata is missing?
Record the dependency. Revise the source data through an authorised route if possible, or redesign the goal around information that is genuinely available.