A concept for connecting product behaviour, support requests and sales conversations in Lenses SQL Studio — with evidence and human review built into the workflow.
Proposed evidence-to-review workflowThree source classes contribute different signals. The workflow prepares hypotheses; the product team evaluates their accuracy and priority.
Context
Lenses SQL Studio
Design scope
Product concept, analysis workflow and review logic
Artefacts
Architecture diagrams, presentation and technical specification
Status
Concept / pre-pilot
01 / Context
Understanding friction across disconnected sources.
Product events show what people do. Support requests and sales conversations can explain what they were trying to achieve, where they struggled and what they expected instead. The design challenge was to bring those signals together without turning an interpretation into a confirmed UX problem.
How could an AI-assisted workflow help a product team identify problems worth investigating — while preserving the evidence and the limits of each conclusion?
BEHAVIOURAL SIGNALS
What happened?
Journey steps, repeated actions, execution errors and aggregate usage patterns. These locate a possible difficulty, but do not explain its cause on their own.
SUPPORT CONTEXT
Where was help needed?
Requests reveal the task, obstacle and expected outcome in the customer’s own context. Similar questions can be grouped without losing their source references.
SALES CONTEXT
What blocks evaluation or adoption?
Approved conversation excerpts add questions and concerns that may not appear in product events. They provide a further perspective to assess alongside usage.
A concept with an implementation specification.
The work defines the proposed architecture, evidence structure, review decisions and pilot plan. Live source connections, a deployed workflow and measured improvements are not established. Lenses SQL Studio provides the product context; the scenario below is illustrative.
02 / Workflow
Keep the evidence connected from ingestion to review.
The proposed n8n architecture separates collection, analysis, review and error handling. Each source adapter feeds a shared evidence format, so source-specific changes do not require redesigning the entire workflow.
01 / COLLECTBring in approved signals
Import an agreed time window from each source, preserving its identifier and ingestion state.
02 / PREPAREMake evidence usable
Normalise records, redact sensitive content and remove duplicates before analysis.
03 / SYNTHESISEBuild a traceable hypothesis
Combine behavioural patterns and qualitative themes by product area, journey step and time.
04 / REVIEWLet the team decide
Present the observation, evidence, limitations and proposed priority for assessment.
Logical architectureA readable redraw of the workflow described in the final specification. It separates source evidence, interpretation, validation and the review decision.Explore the proposed n8n implementation
UX-01 · Ingestion. Scheduled or manual source sub-workflows → mapping and redaction → validation → upsert into a reference evidence store. Each adapter maintains its own cursor.
UX-02 · Analysis. Aggregate behaviour using defined metrics, extract themes through a bounded LLM chain, group related signals, synthesise findings and parse structured output. Code validates the schema and evidence references before saving.
UX-03 · Review. An authenticated form or internal application records the reviewer’s verdict, final priority and rationale while retaining the original proposal.
UX-90 · Errors. A separate error workflow records execution and source state, notifies an operator and supports limited retries without duplicating imported records.
n8n is the proposed orchestrator. PostgreSQL is a reference storage option; source systems, model provider, hosting and retention still require agreement.
03 / Design decisions
Make useful automation inspectable and bounded.
The core decisions concern what the model may infer, what the interface must explain and where the product team retains control.
01
Ground every finding in evidence.
Each hypothesis carries source identifiers, a time window, product area, journey step and limitations. A validation layer checks references before the finding reaches review. This gives the reviewer a route from the summary back to the signals behind it.
Interpretation boundary. Similar themes and behaviours can support a hypothesis. Their co-occurrence does not establish a cause or prove that the same people generated both signals.
02
Separate priority from confidence.
Priority describes the possible impact on the user’s task. Confidence describes the quality and completeness of the supporting evidence. A well-supported minor issue is different from a potentially critical issue that still needs confirmation.
A reviewable proposal. P1, P2 and P3 provide a draft rubric. “Insufficient evidence” is a review status rather than another severity level.
03
Use a defined workflow for the MVP.
The specification proposes a Basic LLM Chain with structured output and deterministic validation. Extraction and synthesis are known steps; autonomous tool selection would add freedom without serving the initial task.
Scope choice. If later research requires active retrieval, a tool-using agent could be considered with an approved tool list, read-only access and logged calls.
04
Turn feedback into controlled updates.
The team can confirm, correct, reject, mark a duplicate or request more evidence. Reviews preserve the original model output and the final decision. Approved examples can then inform versioned prompts, grouping rules and priority criteria.
Change control. Revised examples and rules are checked offline before another analysis run. Automatic retraining after each review is outside the MVP.
04 / Illustrative scenario
A diagnostic count without a clear next step.
In the Lenses SQL Studio example, an engineer runs a query, sees problematic records and moves between results, execution statistics and record details. The concept asks whether usage patterns and customer questions might together point to a gap in diagnostic guidance.
Synthetic example for explaining the proposed output. It is not a recorded finding, a completed analysis or a finished review interface.
ILLUSTRATIVE FINDING · RESULTS / DIAGNOSTICS
Users may need clearer guidance after a problematic-record count.
Needs evidence review
Behavioural observation
Repeated query runs and movement between results, the editor and execution statistics could signal difficulty interpreting an unexpected result.
Customer context
A support request or approved conversation excerpt could contain a question about how to locate and diagnose the affected records.
Hypothesis
The count may reveal that something needs attention without explaining the next useful action.
Evidence required
Accessible source references, an agreed time window, metric definitions and the context of each excerpt. No source IDs or counts are invented here.
Impact and priority
Potential impact: extra diagnostic effort. P2 could be considered if recurring friction and an available workaround are confirmed; a blocked key task would need reassessment.
Confidence and limitations
Not established for this example. Repeated runs may be expected technical investigation, and the supporting signals may concern different users.
ConfirmCorrectRejectDuplicateRequest evidence
The reviewer checks whether the signals concern the same task, evaluates alternative explanations and decides whether to investigate or prioritise a change.
P1 · High impact
A key task is blocked or there is substantial operational impact. The proposed finding needs prompt review.
P2 · Repeated friction
An important step requires repeated extra work, although a workaround is available.
P3 · Limited impact
A local or occasional difficulty has a small effect on the task outcome.
05 / Concept evolution
From an alerting diagram to a reviewable process.
The early diagrams explored collection, analysis, aggregation and a feedback loop. The final presentation and technical specification make the decision boundaries more explicit: three source classes, validation of evidence, separate confidence and priority, and controlled updates.
Early system architectureAn initial two-source exploration using Zoom transcriptions and PostHog data. The final specification describes source classes; actual source integrations remain to be agreed.
Early analysis flowThe initial diagram includes alerts and model retraining. The final MVP introduces a human review queue and versioned, tested updates to examples and rules rather than automatic retraining.
Early source-to-team sequenceAn early view of module interactions and team feedback. The final workflow adds explicit evidence validation and retained review decisions before findings can inform action.
Source material: concept presentation “Agent AI do oceny jakości UX” and technical specification “Dokumentacja techniczna agenta oceny jakości UX n8n”, version 1.0, 25 October 2026. The original diagrams are shown as exploratory artefacts; the updated architecture above reflects the final specification.
06 / Evaluation plan
Establish finding quality before expanding the workflow.
The next step is a limited pilot with agreed evidence and expert assessment. The plan measures whether findings are useful, traceable and appropriately prioritised. Pilot results have not yet been measured.
Start with known cases.
Use synthetic or anonymised inputs first, then an approved historical sample assessed independently by UX and product reviewers. Compare the workflow’s proposals with the reference assessments and inspect disagreements.
Run a read-only pilot.
Expose findings to a small review group. Agree the scope, reference set and acceptance thresholds before launch, then decide what to refine before adding sources or increasing volume.
Finding relevance
Measure confirmed findings, corrections, rejections, duplicates and insufficient-evidence cases. Examine missed known issues alongside false positives.
Priority agreement
Compare proposed priorities with reviewer decisions and record why they differ. Keep reviewer disagreement visible rather than treating every label as objective ground truth.
Evidence completeness
Check that each finding has valid, accessible references and a time window. Reject fabricated references and distinguish interpretation from observation.
Review usability
Observe whether reviewers can locate evidence, understand uncertainty and record a decision with a useful rationale.
Operational reliability
Verify duplicate-free re-imports, recovery after source failures, access controls and handling of instructions embedded in source content.
Conditions for moving forward.
Source access, event definitions, model and hosting choices, retention, reviewer authentication and the final priority rubric must be agreed before production data is used.
07 / Contribution & reflection
The output is a proposal people can interrogate.
The design work turns a broad idea for AI-supported UX monitoring into an explicit evidence and review workflow. Its value will depend on whether the team can verify the findings and use them to choose a useful next investigation.
What the work delivers
A product concept, system and sequence explorations, an n8n implementation specification, an evidence model, review decisions and a staged evaluation plan. Together they define what an initial implementation would need to demonstrate.
What I would develop next
A small working evidence pipeline and a review prototype. I would test how reviewers distinguish observations from interpretations, assess low-confidence high-impact issues and explain their final decisions before broadening the automation.