Back
How do you migrate non-technical users to a more technical tool?
Lead Product Designer · Qualtrics
Qualtrics is unifying how customers manage their data. Currently, Qualtrics maintains two data modeling tools with different underlying technology and user experiences. Most of our users are non-technical and new to data, but our enterprise clients still need complex functionality. To migrate our novice users to the Data Modeler, I led design for the Data Modeler simplification initiative by redesigning how multiple user types create and clean datasets. This has also prepared Qualtrics to retire a long-standing legacy data tool, the Mapper, ultimately reducing technical load for engineering and giving users powerful capabilities.
This is the story of simplifying dataset creation for multiple user types. Every decision I made in this project started with three questions: When someone models data, what should I show a technical user and what should I show a non-technical one? Which capabilities do I offer to both, and which do I hide, and when? How do I get users to their goal as quickly as possible while keeping powerful functions within reach for when they want them?——What do you automate when you automate data modeling?
Simplified dataset creation for 97% of use cases
YEAR
SCOPE
TESTING
TEAMS
Outcome
My role
I am the lead designer on a cross-functional team spanning dataset applications and dataset catalog. I own all flows related to data modeling.
I designed this guided experience and flexible canvas around three main flows: single survey dashboard (single source dataset), combining surveys (union datasets), and advanced functions (datasets with joins, aggregations). This has meant working with PM and engineers from multiple teams, vibecoding a prototype, and interviewing users to test designs and defend product decisions. When a decision is contested, I defend it with research.
Mostly automated dataset creation
Like in art, giving people a blank canvas is more difficult than giving them constraints. With a guided flow, users will never start with a fully blank canvas. I designed a guided setup that starts with one question: what are you trying to build? A simple survey and a multi-survey union need different steps, so I split the experience into flows that fit each case.
I kept the complexity out of the way until someone needs it. The mapping screen stays simple: choose a field, name it, set its data type. I moved the complex transformations behind the surface so people can publish without learning the whole data model first.
Complex data transformations are obscured from the user until they need it.
Flexible data model canvas
I designed the Data Modeler canvas to show the same model three ways: as a node tree, by schema, or by row values. Each view answers a different question, so people can pick the one that matches what they need to check.
My thinking was to bring Qualtrics Data Modeler up to industry standard. I designed the canvas so people who have never worked with joins or aggregations can learn those concepts while they edit. Instead of hiding them behind documentation, the concepts show up in the flow itself.
A clear toggle between the model, schema, and final dataset.
Deprecation of legacy tool
Customers used to learn and maintain datasets in two different tools. I helped move everyone onto one: the Data Modeler. Once customers migrate, we can retire the legacy tool and stop maintaining it.
The before and after screens show the difference. The old experience split the work across two tools with no onboarding. The new one brings it into a single tool that does most of the setup automatically.
Next on the agenda is migrating existing datasets and creating onboarding, so customers can move over without losing their work on expensive, existing projects.
Goodbye Data Mapper, Hello Data Modeler.
Refactored logic
Three fewer flows to maintain. I mapped how dataset creation and editing decide which features to show, and I used that map to cut the flows down to one path that handles both cases.
I worked through the union schema and field mapping logic with engineers, so each branch in the diagram reflects a decision we made together. The flow now starts from one question: what is the dataset for? From there, the steps follow from the answer.
Technical Discovery and User Research
Building a tool for myself
This project spanned multiple teams and flows, which meant there were many long and detailed decisions recorded in our team PRD. I learned that on a project this large, teammates can miss changes. So, I built a tool that delivers a weekly digest of every change.
Automatic weekly digest of product design changes
This project is ongoing
The work isn't finished. I'm now focused on the final piece: moving existing data models into the Data Modeler.
Once those are done, the Data Modeler will be the only place customers build and maintain datasets.