Designing AI experiences that help non-technical users understand, trust, and act on complex system behavior.
Redesigning the configuration workflow of an enterprise AI platform to make complex modeling decisions visible and easier to iterate.
Role
Senior Product Designer
Product
dotData Enterprise AI Platform
Team
2 Designers
Focus
Workflow Design, Complex Systems UX
This project focused on redesigning how users configure AI models by making system dependencies and data alignment visible earlier in the workflow.
Problem Overview
The primary users were business analysts, people who understood their domain well but had limited hands-on experience with machine learning. Most of them were introduced to dotData by their organization, not by choice. Before the platform, many had relied on Excel or leaned on their data science team to run analyses for them.
That dependency didn't go away when dotData arrived. During configuration, analysts would typically work through settings in regular check-ins with a dotData data scientist, and in many cases, the DS would end up configuring the model on their behalf. The tool existed to give business users independence, but in practice, it still required expert support to operate.
The cost of a misconfiguration was hours of lost time. Model training could take one to two hours, sometimes longer, depending on data size. If a user set the wrong data type, they'd have to re-upload the dataset and start the entire configuration over from scratch. If the model ran but accuracy came back low, they often had no idea why. The feature list meant nothing to them. They didn't know what to do with it, and they didn't know what they'd done wrong.
What made this worse: most of dotData's customers didn't have an internal data science team. That's exactly why they were using the platform: to run ML without needing one. But in practice, every time something went wrong, they were filing it into our DS team's calendar. We were absorbing the cost of a UX problem as customer support hours.
Hidden Dependencies in the Model Pipeline
Building a predictive model in dotData involves configuring several key parameters that determine how the training dataset is generated.
These include:
Time column
Prediction target time
Lead time
Feature windows
Table relationships
These settings define how raw data is aligned, transformed, and converted into training samples.
However, many of these dependencies were invisible in the original interface. Users could configure parameters without realizing how those choices would affect the final dataset.
This created a frustrating workflow:
Because the system did not surface configuration consequences early, users were forced to make high-stakes decisions without feedback. Below are the three systemic issues that emerged:
Expert Trap
Although the interface was graphical, many concepts were still framed in data science terminology. A business analyst setting up their first model had no way to know what "prediction target time" meant or why getting it wrong would break everything downstream.
Invisible Ripple Effects
Configuration changes silently altered the dataset used for modeling, but users could not see these effects until the end of the process. By then, the only signal was a low accuracy score with no explanation attached.
Rigid Workflow
The step-based wizard forced users into a linear process, making experimentation slow and error-prone. If something went wrong, there was no way to adjust a single parameter. Users had to restart from the beginning.
Understand the system
Going into this project, I assumed the problem was mostly terminology. The interface used data science language, and business analysts weren't data scientists, so the fix should be a language problem, right?
An engineer pushed back on that early. He told me to take a real dataset and try to configure a task myself. See if I could get it right without help.
I couldn't.
That changed how I thought about the problem. I started digging deeper, reading documentation, asking engineers to walk me through the pipeline logic, and using ChatGPT to translate the technical concepts into plain language with concrete examples. Slowly, I built up a mental model of what the system was actually doing. And that's when I realized the terminology wasn't the real issue. The issue was that the interface gave users no way to understand the consequences of their decisions before it was too late to fix them.
Rethinking the Interaction Model
v2
Our first instinct wasn't to scrap the wizard. We spent time exploring how to make it better — clearer section labels, easier navigation between steps, more explicit definitions for each parameter. But the more we dug into the configuration flow, the more something felt off.
At some point I realized: what users were actually doing, across all these steps, was defining a single flat table. That table was the training dataset. Every parameter — time column, prediction target time, lead time, feature windows — was just determining what that table would look like. The wizard was hiding that. It was breaking one coherent decision into a sequence of isolated steps, so users never had a mental model of what they were building toward.
That's when the canvas idea came in. If the real task was constructing a dataset, the interface should make that visible — not walk users through it one field at a time.
Design Details 01
Helping Users Understand Time Relationships
Prediction Target Time sounds like a configuration field. It's not — it's the reference point the entire training dataset is built around. Get it wrong, or skip it, and the model trains on misaligned data. Accuracy comes back low and there's no obvious explanation why.
The problem was that PTT showed up in two places. Users configured it in the Target Panel, but it was also required later when they manually defined the historical data range during table connection. If they hadn't set it earlier, the system would stop and ask for it mid-workflow — a different screen, a different context, no explanation of why it was suddenly needed. Most users just gave up.
Prediction Target Time is primarily configured
in the Target Panel.
The Challenge: Cross-Workflow Dependency
When users chose to define the historical data range, the system required PTT to calculate the correct time alignment. However, by that point, they were already three steps away from where PTT was configured.
When users select Auto range (left), the system handles time alignment automatically. When they switch to Define range manually (right), Prediction Execution Time depends on PTT to calculate correctly — but PTT is configured in a completely different part of the workflow.
Design Solution: Configure PTT Inline
Instead of forcing users to navigate back to the Target Panel, the interface allows them to configure Prediction Target Time directly within the current workflow.
When PTT is required but missing, users can click the edit icon to open a lightweight configuration panel.
This approach preserves workflow continuity while ensuring that the required parameter is correctly defined.
Any time-based entity relationship requires Prediction Target Time to be defined making it a required dependency
across the entire table connection workflow.
Helping Users Understand Time Relationships
Four time-related parameters — prediction target time, execution time, lead time, and data lead time — are configured in different parts of the interface but collectively determine the data window used for training. Without a way to see how they relate, users had no mental model of what they were actually setting up.
This visual explanation helps users build a clearer mental model of how prediction time and historical data windows relate.
Design Details 02
Auto-Connecting Tables
To build a training dataset, users need to connect multiple tables and define how they relate to each other. In the original workflow, this meant manually selecting join keys for each connection. This is a step that assumed familiarity with database relationships, but most business analysts didn't have.
We introduced auto-connect: when a user adds a table, the system scans the schema and suggests a likely relationship based on detected column matches. The goal was to get users past this step without having to understand what a join key is.
There was an obvious risk: what if the system suggested the wrong connection? We decided to let it. Users who needed to adjust could do so manually, and anyone who missed an error would hit validation when they tried to run. The priority was reducing the decision load upfront, not making the interface feel cautious.
Validation
Testing scenario given to participants — predict server failures using four linked datasets.
An early concept explored during testing — making prediction target time interactive rather than explained in static text.
We tested with three external participants: master's students in business analytics, who were given a real dataset and a concrete problem to solve:
Predict which servers were likely to fail in the next seven days
Before the session, a PM briefed them on the scenario. During the test, I sat back and observed, tracking behavior rather than what they said.
One thing stood out immediately. All three skipped every tooltip and description text without reading it — not because they were rushing, but because they were focused on getting through the task. They weren't learning the system; they were trying to use it. This confirmed that any solution relying on user education would fail in practice.
One tester flagged something that directly shaped a later design decision: she found herself going back and forth between the description text and the configuration panel trying to understand prediction target time, and suggested the concept should be interactive rather than explained in static text. That observation led directly to the timeline visualization.
On configuration speed: in a separate benchmark where users already understood the task and encountered no errors, configuration time dropped from around 10 minutes to 5. The gains came from intelligent defaults and inline validation — fewer decisions to make, fewer mistakes to recover from.
"The canvas flow is so much smoother than before." - dotData DS team
Impact
The bigger change was around iteration. Users could now adjust any part of the configuration without starting over, something that wasn't possible in the original workflow. The CS team flagged this as one of the most noticeable improvements after launch.
On the dependency side, users responded well to the timeline visualization and auto-connect. The feedback was that the examples made the time relationships click without needing to cross-reference documentation, and auto-connect removed most of the manual work upfront, leaving users to just review and confirm. One thing that came out of this: users still had to hover to see connection details, and a few mentioned that a way to scan all connections at once would help. That's something I'd want to go after next.
Reflection
When I first looked at this system, it felt like a black box. Users put data in, waited an hour or two, and got a result they couldn't interpret. My assumption was that the fix was simple — just show people more.
That turned out to be wrong. The question I kept coming back to was: does the user actually need to know this? Or is it just going to make them feel like they're doing something wrong? Some information helped. Some just made people second-guess themselves. Most of the real design work was figuring out which was which and I'm still not sure we drew it in exactly the right place.
One thing I wanted to push further but didn't get to: closing the loop between configuration and model performance. Right now users set things up, wait, and get a result — but they can't connect what they configured to what came out. That gap is still there, and I think it's the most important thing to go after next.
