How to Design UX for AI Products Built on Unstructured Enterprise Data: UI/UX Designer Kateryna Orlova Explains

Enterprise products have traditionally been built around predefined information architecture: filters, tables, reports, and a fixed set of metrics. Generative AI is changing that model. Increasingly, users aren’t interacting with a report that was designed in advance. They’re interacting with a system that interprets a request, determines what data needs to be gathered, and decides how that information should be presented.

For UX designers, this creates an entirely new class of challenges. In traditional products, much of the work involved designing a predictable path from a user action to a specific outcome. In AI-powered products, there’s an additional layer of uncertainty because the result may depend on the context of the request, the structure of the data, and the model’s interpretation.

That becomes especially noticeable in systems that work with large volumes of unstructured enterprise data.

We discussed these challenges with UI/UX designer Kateryna Orlova, whose work sits at the intersection of enterprise UX, AI features, and design systems. She contributes to the development of the U.S.-based Yourco platform, including Frontline Intelligence, a product designed to work with unstructured data from operational communications.

In addition to her product work, Orlova is active in the professional design community. She is a member of AIGA, the User Experience Professionals Association, AITEX, and The One Club for Creativity, and she publishes both academic and professional articles. In 2025, she served as a judge at the AITEX Good for Tech Hackathon, and her work was recognized at the international ECDMA Global Awards.

We spoke with Orlova about what changes for designers when they can’t anticipate every user request or system output in advance, and how UX design itself needs to evolve in AI-powered products.

From a UX perspective, what fundamentally separates an AI interface from a traditional enterprise product?

In a traditional enterprise product, the designer defines much of the space in which the user can operate ahead of time.

There’s a product structure, a set of objects, filters, pages, states, and a defined navigation logic. Even when the system is complex, the user can usually anticipate what will happen after each action.

In an AI interface, part of that structure becomes dynamic. A user can ask a question that the designer never explicitly anticipated as a standalone use case.

For example: “How many employees reported being sick last month?”, “Have there been any reports of emergencies recently?”, or “Which locations experience certain problems most often?”

We faced this type of challenge while working on Frontline Intelligence. The system analyzes unstructured operational communications, and there’s no practical way to define every possible question users may want to ask about that data in advance.

That changes the design approach itself. You can’t create a separate report for every possible scenario. Instead, you have to design the framework for the interaction: what the system can understand, how the response is generated, what limitations the user can see, how the user can refine a request, and how the result can be verified.

So the object of design isn’t just the sequence of actions a user takes in the interface. It also includes the behavior of the system itself.

Does that mean the traditional user-flow model is no longer enough?

Yes, although the user still has an entry point, available interactions, system states, errors, ways to go back, and a next step.

What changes is the level of nonlinearity. The same type of request can lead to very different outputs depending on the data.

For me as a designer, that creates a separate problem to solve. AI can surface a large amount of information, but the user doesn’t need the entire dataset. You have to decide what should appear first, where a visualization or comparison is useful, and where a short direct answer is enough. 

One request may call for a specific number. Another may require a comparison across several time periods. A third may be better represented as a list of events. In some cases, the answer itself won’t be sufficiently informative without additional context or access to the underlying source data.

One of the biggest UX challenges with AI is that the output can be unpredictable. How do you design around that?

I think the first step is recognizing that you can’t eliminate that uncertainty completely.

The design goal therefore shifts from fully controlling the outcome to managing the user’s expectations.

It’s important to separate the underlying data from the model’s interpretation of that data. Users should be able to understand what the system’s answer is based on and, when necessary, return to the original information, especially when the result may influence a business or management decision.

What happens when a UX solution conflicts with the product’s technical architecture?

Then you go back to the user’s actual problem.

For me, the goal isn’t to defend a particular mockup at all costs. The goal is to preserve the core user need.

When the original idea turns out to be too technically complex, takes too long to implement, or doesn’t fit the product’s current architecture, we work through the constraint with the engineering team and look for another approach. That might mean changing the flow, simplifying the interaction, or proposing a solution that’s easier to build while still solving the same user problem.

Product work always involves balancing user experience, business goals, timelines, and technical constraints. Sometimes a simpler solution ends up working better than the original concept.

How does the designer’s role become more complicated when the product starts serving large enterprise customers?

In 2026, Yourco raised $6 million from High Alpha to further develop the product and support its growth. For a designer, company growth primarily means an increase in both the volume and complexity of the work.

When a product is used by a large organization, the requirements change. You have to account for a large number of locations, departments, groups, roles, permission levels, and data structures.

Large organizations also already have their own processes and systems. They aren’t going to rebuild everything around a new product. The product has to fit into the environment that already exists.

That makes collaboration across sales, product, design, and engineering especially important. Each team has a different part of the context, and the designer’s role is to bring that context together into a solution that works for the user without breaking the overall logic of the product.

When the workload grows, how do you decide what to prioritize?

I work across several areas at the same time, including the company’s core product, enterprise solutions, AI features, and the design system. In addition to product work, I also contribute to the website, marketing materials, and the company’s visual communication. That makes prioritization a major part of my job.

The highest priority usually goes to work that customers need, supports the launch of a new feature, helps close an important contract, or is blocking engineering.

But you can’t focus only on urgent tasks. There’s also foundational work whose value becomes visible later. When the product and team are growing quickly, you can’t design every new interface from scratch. That’s where the design system becomes especially important.

It allows us to design and build new features faster over time, maintain consistency across the product, and avoid accumulating unnecessary visual and technical debt.

If you had to reduce all of this to a few principles, how should designers approach AI for unstructured enterprise data?

I’d highlight three main principles.

The first is to design around the user’s task, not around what the AI can do. Not every possible request needs to become a predefined use case, but the designer needs to understand what result the user actually needs and what they’re going to do with that information next.

The second is to make the result verifiable. Users should understand where the system is showing source data and where it’s presenting an interpretation of that data. They should also be able to return to the original source when necessary.

The third is to preserve predictability in the interface. AI gives the product flexibility, but that flexibility shouldn’t make the experience harder to understand. If a conventional interface can solve the task faster and more clearly, there’s no reason to use AI just for the sake of using AI.

For me, the quality of an AI interface isn’t defined by the number of AI features it includes. It’s defined by how clearly and controllably those features fit into the user’s workflow.

The designer’s core challenge is finding the balance between the flexibility of AI and the predictability of the product. The system needs enough freedom to handle different types of requests, while the user still needs clear and understandable rules for interacting with it.