Overview
A major customer needed to migrate to our digital signage platform—but the way they organized content depended on a metadata structure our product couldn’t support.
It would have been easy to recreate their existing system. Instead, I designed a flexible metadata framework that could accommodate their complex taxonomy while giving every customer more control over how they organize content and devices.
From Migration Blocker to Flexible System: Designing Metadata That Could Scale
What I owned
I led this project from problem definition through final interaction design, turning a customer migration need into a scalable product capability. I defined the custom-field framework, worked through key system constraints, and identified opportunities beyond the original requirements.
Role + Scope
Sr. Product Designer → Discovery, requirements, product strategy, interaction design, UX writing, stakeholder alignment
The real problem wasn’t metadata. It was rigidity.
Different organizations classify their content in very different ways. Language, geography, deployment type, campaign, market—what matters depends entirely on how that organization operates.
Our existing metadata system assumed we could determine those categories for users ahead of time.
That limitation became critical when one of our largest customers prepared to migrate to the platform. Their workflows depended on a highly structured taxonomy, including fields that had to be completed consistently by teams across the organization.
Supporting their migration mattered. But recreating their structure exactly would solve one customer’s problem while leaving the underlying limitation intact.
The opportunity was bigger: give organizations the building blocks to define their own structure.
My first solution was too literal (oops)
Because the platform already supported tags, I initially explored extending them into a nested hierarchy.
It seemed efficient. The customer could reproduce the structure of their existing CMS, and we could build on a familiar product pattern rather than introduce another system.
But as I worked through the actual workflows, the approach broke down.
Tags could classify something after the fact, but they couldn’t enforce the information an organization needed users to provide. If an administrator needed every uploaded asset to include a language, market, or description, a tag hierarchy couldn't require it.
→ We didn’t need a better tagging system. We needed configurable data.
Designing a framework, not a taxonomy
I shifted the concept from hierarchical tags to custom fields defined by administrators.
Instead of deciding how customers should organize their information, the product would define the rules of the system and let each organization configure the structure inside it.
Administrators could create fields using the data type appropriate to the information being captured:
Text
Number
Date
Boolean
Single-select lists
Multi-select lists
Nested list structures
That distinction made the system useful well beyond the original migration. One customer could organize assets by language and market; another could classify devices by region, installation type, or any structure we hadn't anticipated.
The flexibility came from designing the primitive rather than prescribing its use.
-
Data type: Boolean
-
Data type: Date
-
Data type: Integer
-
Data type: Multi-Select List
-
Data type: Single-Select/Nested list
-
Data type: String
Required fields created a system-level problem
Allowing administrators to make fields required introduced an important edge case.
A newly created required field would immediately apply to objects that already existed in the platform. Those objects wouldn't have a value yet, creating invalid records and potentially disrupting existing workflows.
Rather than weaken the requirement, I introduced a Default Value whenever an administrator made a field mandatory.
The default gave the system a valid fallback for existing objects while ensuring new work followed the organization’s requirements going forward.
It was a small interaction solving a much larger product problem: how to introduce stricter rules without breaking the data already in the system.
Looking beyond the stated requirements
Discovery also revealed something the customer hadn't explicitly asked us to build.
Their taxonomy wasn't valuable simply because it helped them label content. They used it to understand how content was distributed across their device fleet and maintain the right mix.
That made metadata useful not only for classification, but for visibility.
I advocated for adding “Related Objects”, which showed how many objects were associated with each metadata value. It gave users a way to understand how their taxonomy was actually being used instead of treating metadata as static administrative information.
Engineering flagged that calculating those counts could sometimes take time, so I also designed clear loading states and messaging to keep system status visible rather than leaving users wondering whether anything was happening.
From migration requirement to product capability
The final system met the customer's migration requirements without hard-coding their organizational model into the product. More importantly, it replaced a rigid metadata structure with an extensible capability other organizations could adapt to their own workflows.
The work:
Removed a significant barrier to migrating a major customer onto the platform
Reduced the need for teams to rely on manual organization or workarounds
Gave administrators control over both the structure and consistency of organizational data
Created a framework flexible enough to accommodate use cases we didn't need to predict in advance
What began as a customer-specific constraint ultimately became something more valuable: a system designed to absorb complexity instead of continually designing around it.