Skip to content
VoiceQC

Why Name / Value — the Property model design

VoiceQC’s Properties are structured: every tag is a Name / Value pair drawn from your account’s Property library. You don’t type tags as free text. That structure is a deliberate choice, and it’s worth a couple of paragraphs on why.

What free-form tags get wrong for a team

Section titled “What free-form tags get wrong for a team”

The obvious alternative is “let people type anything.” Many tools work that way — Gmail labels, GitHub Issue labels, project-management tools that let you tag a card with whatever string you want.

It works fine for one person. It falls apart for a team.

The failure mode is consistent across every team that’s tried it: drift. Two engineers tag the same situation needs-retake and needs retake and needsRetake and now you have three labels for one concept and your filters miss two of them. Someone tags Approved on Monday and someone else types approved on Tuesday. A reviewer types Hero (the character) and a director types Hero (Player 1) (more specific) and now neither of them knows whether the other actually meant the same character.

The damage is real. The team’s mental model fractures into one-per-person, and the data nobody can rely on is data nobody uses. Free-form tagging is a tax on the team that compounds with every new member.

What the Name / Value structure buys

Section titled “What the Name / Value structure buys”

The structure makes drift hard:

  • Names are reused, not retyped. Once Status is in the library, the editor offers it from a dropdown. You don’t type it again.
  • Values under a Name are a finite menu. Once Status / Approved exists, every reviewer picks Approved from a dropdown. You can’t accidentally type approved and create a near-duplicate.
  • Renaming propagates. If the team decides Status / Needs retake should actually be called Status / Retake required, you rename the Value in one place and every chip already applied updates.

The price is one extra step on the very first time someone tags a new concept — you click into the dialog, type the new Name and Value, click Create. After that it’s a dropdown choice. The cost is paid once; the consistency is shared by everyone forever.

When the structure is overkill

Section titled “When the structure is overkill”

The structure assumes the team has enough tagging that consistency matters. If you’re a solo user tagging a handful of items for your own reference, free-form tags would do.

VoiceQC doesn’t ship a free-form mode because once you have collaborators (or a future-you trying to reproduce a filter from six months ago), the structure pays itself back. But it’s worth being honest: for a one-person workflow on a small batch of audio, the Property editor is heavier than it needs to be.

The compromise is in the editor itself. The first time you create a Property, the dialog is just two text fields — Name and Value. You’re not asked to plan a taxonomy upfront. Your Property library grows by use, not by design meeting.

Why there’s no third level (today)

Section titled “Why there’s no third level (today)”

Internally, VoiceQC’s data model has three levels — a Type above Name. The UI hides it.

The original design surfaced all three. User testing in early access found that asking people to think about Type and Name and Value at tagging time was too much. People wanted to type “I’m calling this take rejected” and the dialog was demanding they first decide whether Status belonged under a Type called Workflow, Process, or something else.

The team’s call: hide Type. Everything you tag goes into a system-default Type behind the scenes; you’ll never know it’s there. If a future workflow needs Type — for example, separating “QC tags” from “production tags” — a power-user mode can surface it then. Until that need is real, the simplicity wins.

This is the kind of decision that’s easier to make than to unmake. Surfacing Type later is straightforward; calling Property a flat tag now and then introducing hierarchy when the team scales would be confusing. The hidden level is a hedge for when teams ask for it.

See also

Section titled “See also”