Creating Custom Characteristics

When the data doesn't match the question

Nielsen analysts work with large, structured datasets to understand products, markets, and consumer behavior. But the way data exists in a database doesn't always match the way an analyst needs to organize or report on it.

As the UX Architect, I designed a workflow that allowed users to create custom characteristics: new, meaningful groupings built from existing data without changing the underlying dataset. Users could define their own values, create filtering rules, group matching records, account for data outside those groups, and then use the resulting characteristics in reporting.

Structured data, seen through a different business lens

Nielsen's underlying data was highly structured, but analysts often needed to interpret that data through a different business lens. The categories available in the database didn't necessarily represent the segments needed for a particular analysis.

For example, an analyst might want to report on a segment such as Alcohol Free, even though "Alcohol Free" did not exist as a predefined value in the dataset. They needed a way to essentially say:

The architectural challenge was providing that flexibility while keeping an already complex enterprise data environment understandable and efficient.

Building on a word analysts already used

An important part of defining the experience was understanding the terminology and mental models already familiar to Nielsen analysts. Within Nielsen, characteristic was an established vocabulary term for this user group. While someone unfamiliar with the platform might think of it simply as a category, group, or item, experienced analysts already understood the concept of a characteristic.

Rather than introducing a new model, I structured the experience around terminology and behaviors analysts already understood. This helped the new capability feel like a natural extension of the larger Nielsen data ecosystem, rather than a separate tool users needed to learn.

A progressive sequence, not a wall of configuration

I translated a complex data-management task into a progressive workflow:

Instead of exposing every possible configuration at once, the interaction architecture guided analysts through a sequence of decisions. An analyst could create a characteristic such as a Custom Beer Segment, define a value within it such as Alcohol Free, and then establish the conditions determining which records belonged in that value, for example beer type and alcohol-content criteria.

Additional values could be created using combinations of categories, product attributes, countries, brands, or other available data. The experience essentially translated complex filtering logic into meaningful business terminology users could understand and reuse.

Built for many values, not an idealized example

This was not necessarily a workflow users would complete only once. Analysts could create numerous values and rules within a single characteristic, which made efficiency an important part of the interaction architecture.

After completing one rule or value, the interface prepared the next available action, for example opening the next selection control, rather than requiring users to repeatedly navigate through the same steps. These small interaction decisions reduced unnecessary clicks and helped maintain momentum through a potentially repetitive configuration process. I also considered how the experience would scale when analysts created many values, so the workflow wasn't designed only around an idealized example with two or three rules.

Giving "everything else" a home

Another important architectural question was: what happens to everything that doesn't match one of the user's rules? Leaving unmatched records undefined could create ambiguity downstream.

The workflow therefore allowed analysts to define a catch-all value such as Everything Else, giving them control over how data outside their custom segments would appear in reporting. This created a more complete and predictable data model, while helping users understand the consequences of the rules they were building.

Working at mid-fidelity to prove the interaction model

I developed the experience progressively, moving from early ideas, sketches, and user flows into low-fidelity wireframes, and then an interactive mid-fidelity InVision prototype. At this stage, visual polish was intentionally limited. The purpose of the prototype was to work through and communicate the interaction architecture:

• How users entered the custom-characteristic workflow
• How characteristics and values were created and named
• How filtering logic was constructed
• How multiple rules and values accumulated
• How users efficiently moved from one task to the next
• How unmatched data was handled
• How the completed characteristic returned to the larger data-selection experience

Working at mid-fidelity allowed the workflow and interaction model to be evaluated before investing in final visual design and development.

A technically complex operation became a guided workflow

The resulting experience gave Nielsen analysts a structured way to create reportable business concepts from existing data without modifying the underlying database. Instead of being constrained by predefined categories, analysts could organize data around the questions they were trying to answer, and create reusable characteristics for downstream reporting.

This project reflects an important part of my work as a UX Architect: understanding a complex system, identifying how expert users think about their data, and designing an interaction architecture that preserves the power of the system while making that power easier to use.