Paulina Pruszkowska is a product and UX designer based in Miami, Florida. In this self-interview, I explore how I use AI, what it needs to understand about a design problem, and why producing a convincing interface is only part of the work.
A prototype can look complete while leaving important questions unanswered. What happens if a payment fails? Which information is verified? Can someone change their mind? Those are the kinds of questions I bring to AI-assisted design, especially when working through account journeys and complex workflows.
Research context: This discussion draws on the abstract of Roger Jiao’s 2026 paper, From ‘data-driven’ to ‘data-informed’ design — grounding AI for design in knowledge, context and decisions. The paper addresses engineering design. The digital product examples and practical recommendations below are my interpretation, rather than findings from a UX study.
What interested you about this paper?
The distinction between having data and knowing what to do with it. Jiao’s abstract argues that design decisions require knowledge, constraints, and context alongside data. It also proposes evaluating AI support through the quality of the decisions it helps make.
My connection to product UX is practical: an analytics signal or generated screen can be useful without explaining the whole problem. I still need to understand the user’s goal, the product’s rules, and the consequences of choosing one direction over another.
How do you use AI in product design?
I use it to explore ideas, try content variations, and build prototypes. It can help me turn an early thought into something I can inspect, discuss, and revise. I also experiment with personal projects to understand how different tools behave beyond a polished demonstration.
I treat the output as a draft. I review the structure, language, interactions, and assumptions before deciding what is useful. If a tool fills in a missing requirement, that assumption needs to be visible so it can be checked.
My working principle: a convincing screen still needs a clear explanation of how it works.
What does context mean in an actual workflow?
Consider an account balance. The number on the screen is only one part of the situation. A customer might have wallet credit, an upcoming renewal, a pending plan change, or a payment that has not completed.
An AI-generated interface could display a balance clearly while leaving the customer uncertain about whether they need to act. To review that design, I would ask what the amount represents, when it applies, and what happens after the person selects the main action.
This is an illustrative example, rather than a measured outcome from a specific project. It shows how information about the product changes the design decisions we need to make.
What has enterprise UX taught you about reviewing AI output?
At Verizon Value Brands, I worked on account and billing journeys, including wallet balances, adding funds, Auto Pay, plan changes, and privacy requests. That work involved collaboration with engineering, accessibility, research, legal, and business teams.
Those experiences shaped what I look for when reviewing a flow: conditions, dependencies, timing, and recovery. A routine path can be straightforward while the surrounding states remain complicated. I want to know how a design handles an unsuccessful action, missing information, or a change that takes effect later.
My HTML and CSS background also helps me think about implementation. A layout needs to accommodate different screen sizes, content lengths, and interaction states once it becomes a working product.
What information would you give an AI tool before asking for a design?
I would start with the task and the decision we are trying to support. Then I would provide the relevant rules, known user needs, and constraints. If something is unknown, I would identify it rather than ask the tool to quietly invent an answer.
How would you assess whether the result is useful?
I would review it against the original task. Can someone understand their situation? Are the available actions clear? Does the interface explain what will happen next? Are important limitations visible where they matter?
For a prototype, I would include realistic content and states before asking people to use it. Observing how someone completes a task can reveal questions that a visual review misses. The appropriate validation depends on the product, the uncertainty, and the consequences of a mistake.
Where do design systems fit into AI-assisted work?
They give the work a more specific starting point. Existing components and patterns can inform layout, language, and behavior. In Figma, I work with reusable components and variables to support consistency across experiences.
I would still review whether a pattern fits the situation. A familiar confirmation component may need different content for a payment, a privacy request, or a plan change. Reuse helps, but the meaning of the action still needs attention.
What are you exploring next?
I’m interested in conversational interfaces and workflows where people can inspect, edit, and approve AI-supported work. I want to understand how an interface can communicate what information was used, what remains uncertain, and which actions still need a person’s decision.
On UX Designer Pro, I write about product updates, interface decisions, and emerging technology. Writing helps me examine the details and develop a clearer view of what I would test or change.
About Paulina Pruszkowska
I’m a product and UX designer based in Miami, Florida,
collaborating remotely with clients and teams across the
United States. My background includes enterprise account
experiences, e-commerce, websites, and design systems.
Explore my
professional experience and resume
.
Source and reading note
Jiao, Roger (2026). From ‘data-driven’ to ‘data-informed’ design — grounding AI for design in knowledge, context and decisions. Journal of Engineering Design, 37(5), 1753–1775. Published online February 24, 2026.
This article references the paper’s publicly available abstract. The Q&A is a self-interview presenting my product design perspective; it is not an interview with the researcher or a report of experimental UX results.
