2026
Preql AI
"Designing transparency without losing the user." - this is a 3-hour Preql product-design challenge, followed by a second iteration grounded in the original brief and feedback from Preql's founder, product manager, and designer.
"Designing transparency without losing the user." - this is a 3-hour Preql product-design challenge, followed by a second iteration grounded in the original brief and feedback from Preql's founder, product manager, and designer.
Role
Product/UX Designer
Skills
Interaction Design
Information Architecture
AI / Agentic UX
Data Visualization
Systems Thinking
Prototyping
Original Constraints
3 hours maximum
Final Prototype
preqlai.demo
Best viewed on desktop
This case study includes interactive flows and detailed system views that are designed for larger screens. For the full experience, please revisit on desktop or tablet.
INTRODUCTION
Preql is an AI-powered data platform that lets business users ask questions about company data in plain language, without needing to understand SQL, data pipelines, or the systems underneath.
Behind a simple question, however, the platform may need to connect data from ERP systems, CRMs, databases, and spreadsheets; reconcile inconsistent definitions; infer missing values; clean errors; and build the infrastructure needed to return a reliable answer.
INTRODUCTION
INTRODUCTION
Preql is an AI-powered data platform that lets business users ask questions about company data in plain language, without needing to understand SQL, data pipelines, or the systems underneath.
Behind a simple question, however, the platform may need to connect data from ERP systems, CRMs, databases, and spreadsheets; reconcile inconsistent definitions; infer missing values; clean errors; and build the infrastructure needed to return a reliable answer.
Preql is an AI-powered data platform that lets business users ask questions about company data in plain language, without needing to understand SQL, data pipelines, or the systems underneath.
Behind a simple question, however, the platform may need to connect data from ERP systems, CRMs, databases, and spreadsheets; reconcile inconsistent definitions; infer missing values; clean errors; and build the infrastructure needed to return a reliable answer.
01
The Challenge.
Preql asked me to design a 3-hour end-to-end experience for an AI data platform that could clean messy enterprise data, resolve inconsistencies, and return business insights automatically.
A business analyst asks, “Show me sales by region for Q4 2023.” Behind that simple question, the system discovers missing region values, inconsistent naming, and AI-inferred data before returning the answer.
Automation without opacity.
Automation without opacity.
How do you make invisible data work legible without turning the user into a data engineer?
How do you make invisible data work legible without turning the user into a data engineer?
WHAT THE SYSTEM PROMISES
Automation without technical burden
Automation without technical burden
The AI should be proactive. Business users should not have to make ETL, cleaning, or infrastructure decisions.
The AI should be proactive. Business users should not have to make ETL, cleaning, or infrastructure decisions.
VERSUS
WHAT THE SKEPTICAL USER NEEDS
Transparency without blind trust
Transparency without blind trust
A CFO who has been burned before wants definitions, changes, approvals, transformations, and lineage before putting their name on a number.
A CFO who has been burned before wants definitions, changes, approvals, transformations, and lineage before putting their name on a number.
02
My submission in 3 hours
Under the time limit, I designed a complete path from natural-language query to deep verification instead of expanding feature breadth. My first bet was to expose the system's invisible work through progressive transparency.
01. ASK
Natural-language query
02. ANALYZE
03. RESULT
04. EXPLAIN
05. INSPECT
Ask your data
Chat-style input, suggested questions, connected sources, and a small “How this works” explanation.
03
Product team's feedback
Feedback came from Preql's founder, product manager, and designer after the exercise.
OVERALL FEEDBACK
Preql product team
Post-submission feedback
"The visual direction had real promise, but the main area to focus on was navigation and spatial orientation: where am I, what's happening, and where do I go next? The sequence from idle → chatting → analyzing → results → detail needed to feel like one continuous, guided journey."
01 · Chat placement
Respect the established mental model.
The chat thread diverged from conventions established by products like ChatGPT, Claude, and Perplexity without a clear enough payoff.
02 · Analysis output
New system activity displaced the result.
As analysis arrived, it pushed the chart out of view. The team suggested a collapsible analysis treatment so the chart could remain anchored.
03 · Detail / lineage
Depth became a different destination.
Once inside lineage, the return path to chat was unclear, and it was difficult to distinguish genuinely new information from repeated content.
MY DIAGNOSIS
I designed the states individually, but not the continuity between them.
All three comments point to the same deeper issue: the user's spatial model resets as the system changes state. Transparency was present, but the experience required re-orientation to access it.
04
Redesign principles
The critique changed how I understood the problem: the question was no longer only how much system work to reveal, but how to reveal it without making the user repeatedly rebuild context.
The original challenge was automation without opacity.
The original challenge was automation without opacity.
The redesign challenge became transparency without disorientation.
The redesign challenge became transparency without disorientation.
New design question: How do I preserve transparency as the user moves from question → analysis → result → verification, without forcing them to rebuild their spatial model at every step?
New design question: How do I preserve transparency as the user moves from question → analysis → result → verification, without forcing them to rebuild their spatial model at every step?
One conversation.
One anchored result. Progressive layers of evidence.
The new direction is one workspace that evolves through states instead of a sequence of separate destinations.
One conversation.
One anchored result. Progressive layers of evidence.
The new direction is one workspace that evolves through states instead of a sequence of separate destinations.
PRINCIPLE 01
Maintain a persistent home base.
Use a recognizable AI-assistant spatial model and preserve the conversation context as deeper analytical states appear.
PRINCIPLE 02
Reveal complexity in place.
System analysis should enrich the answer without pushing the primary chart/result out of context.
PRINCIPLE 03
Deepen context without breaking context.
Verification should feel like increasing depth into the same result, with an obvious return path and no unnecessary repetition.
05
Design decisions
I redesigned the architecture around continuity — not around individual screens.
The goal was to preserve one mental and spatial model from question → processing → answer → verification.
Decision 01 · Direct response to chat placement feedback
Reassign the workspace: conversation owns the task; the side panel owns inspection.
User no longer has to relearn where conversation lives just because the system has produced an analytical result.
Decision 02 · Direct response to analysis-output feedback
Separate progress from proof.
Transparency matters, but it does not require equal visibility for every system action.
Decision 03 · Additional trust-model refinement
Scope confidence to what it actually describes.
Click to see the explaination of certain inforamtion - a trust signal is only useful when users know exactly what it applies to.
Decision 04 · Direct response to detail / lineage on different levels
Deepen verification from the object the user is questioning.
Each level answers a different question, and technical depth is an explicit threshold rather than the default next destination。
01
ANSWER
What’s the result?
02
EVIDENCE
What affected this answer?
03
EXPLAINATION
ON DETAILS
Why was this region inferred?
04
RELEVANT-PATH
LINEAGE
How did this transformation feed the result?
05
OPTIONAL
FULL LINEAGE
Complete data pipeline with query context
Decision 01 · Direct response to chat placement feedback
Reassign the workspace: conversation owns the task; the side panel owns inspection.
User no longer has to relearn where conversation lives just because the system has produced an analytical result.
Decision 02 · Direct response to analysis-output feedback
Separate progress from proof.
Transparency matters, but it does not require equal visibility for every system action.
Decision 03 · Additional trust-model refinement
Scope confidence to what it actually describes.
Click to see the explanation of certain information - a trust signal is only useful when users know exactly what it applies to.
Decision 04 · Direct response to detail / lineage on different levels
Deepen verification from the object the user is questioning.
Each level answers a different question, and technical depth is an explicit threshold rather than the default next destination.
01
ANSWER
What’s the result?
02
EVIDENCE
What affected this answer?
03
DETAILED
EXPLANATION
Why was this region inferred?
04
RELEVANT-PATH
LINEAGE
How did this transformation feed the result?
05
OPTIONAL
FULL LINEAGE
Complete data pipeline with query context
My Redesign — one continuous workspace
These are not seven independent page concepts. They are states of one workspace with deliberately changing levels of depth.
01
ASK
Establish the conversational home base.
The user starts with a familiar query model and clear connected-data context.
02
PROCESSING
Communicate meaningful progress.
Routine activity stays compact while a material anomaly is surfaced without turning backend execution into the whole experience.
03
RESULT
Answer and follow-up share one task space.
The analytical artifact stays in the conversational workspace and the composer remains directly available for refinement.
04
EVIDENCE
Inspect what materially affected the answer.
The side panel appears contextually while the result stays visible.
05
EXPLANATION
Deepen a specific issue.
Region Inference explains what was missing, what information was used, what transformation occurred, and what the 94% confidence applies to.
06
RELEVANT LINEAGE
Trace only the path relevant to the selected transformation.
Technical depth grows from the exact issue being questioned instead of immediately exposing the entire enterprise graph.
07
FULL LINEAGE
Cross the threshold into technical inspection deliberately.
The full canvas preserves query context, the selected Region Inference node, and an explicit route back to the result.
Explore the Redesign here!
Click through the redesigned flow to see how Preql moves from question to answer to deeper verification without breaking context.
Reflection >_
My first solution equated transparency with making more of the system visible. The critique pushed me to think differently: transparency only helps when users can stay oriented and understand why each piece of information matters. In the redesign, I focused less on exposing the machinery and more on preserving context—showing progress while the system works, evidence when the result arrives, and deeper reasoning only when the user asks for it.
Next step: test, test, test
If this were a real product, my next step would be to test the redesigned flow with business and data users—especially whether the transition from result → evidence → explanation → lineage feels genuinely progressive, and where different users decide they have seen enough to trust the answer.