Expert Talks with Katerina Sotiriou: From Prototype to Research and Iteration

We’re back with another Expert Talks, and this time we are getting practical about what happens after you have a prototype in your hands to test with.

After collaborating with Katerina Sotiriou on our recent Lean UX guide, we wanted to keep the conversation going. So we asked her to take us through the full research cycle: when to start testing, what to pay attention to, how to react when users prove an assumption wrong, and where Useberry fits along the way.

Let’s get into it:

Getting from prototype to research

When do you think a prototype is “ready enough” to put in front of users?

For me, a prototype is “ready” as soon as it reaches the right level of fidelity needed to answer the specific question we have at that moment. Personally, I prefer to test as early as possible using low-fidelity prototypes. A lo-fi prototype is ready when it captures the core concept and basic user flow, so it only needs to be clear and functional enough to get useful feedback without over-investing in visual details.

Later in the process, a high-fidelity prototype becomes more useful when we want to test the realistic feel of the product, including visual design, typography, layouts, and key interactions. Prototype testing isn’t something I see as a one-time event at the end of a project. It should continue throughout the design lifecycle, and catching structural issues during the lo-fi stage makes them much easier to address before changes become more complex and costly.

If you could test only one flow in an early-stage product, how would you choose which one matters most?

I would choose the Core Value Flow without hesitation, meaning the primary journey that directly solves the user’s main problem. In an early-stage product, I wouldn’t spend the limited testing time on secondary features like profile editing or settings. I would go back to the core problem defined during research and ask: what single task, if it fails, makes this product useless? That could be completing a booking, sending a message, or creating a first project.

It also comes down to how quickly the user reaches their “Aha!” moment, the point where they understand the product’s core value. My philosophy is simple: if the main path from point A to point B isn’t clear and effortless, adding more features won’t fix the experience.

Running the test

What does a simple first usability test look like for someone who has never run one before?

Once you have a completed prototype, whether it’s low fidelity or high fidelity, it’s time to put the design in front of users. The purpose isn’t to present the work or explain why the decisions make sense. You want to observe how real users interact with it, identify pain points, and understand whether the assumptions behind the design actually hold up.

I usually think about a structured usability study in four phases.

1. Plan the study

Start by defining the context behind the research, what you want to learn, and the questions you need the study to answer. Decide which measures matter, such as task completion or time on task, whether the study should be moderated or unmoderated, who the participants should be, and what tasks or questions they’ll receive. Having those pieces clear before testing starts makes the results much easier to interpret later.

2. Conduct the research

Put the prototype in front of participants and guide them through the core tasks you want to evaluate. Pay attention to reactions, comments, hesitation, friction points, and both verbal and non-verbal cues. The way you communicate matters as well, so the language in your tasks and questions should stay clear, inclusive, and neutral enough that you aren’t leading participants toward the answer you expect.

3. Analyze and synthesize

Once the sessions are complete, bring the qualitative and quantitative findings into one place and start looking for patterns. Affinity diagramming can help group related observations and surface recurring themes. From there, turn the findings into practical design insights that the team can actually act on.

4. Share insights and iterate

Research findings should feed directly back into the design cycle. Share the patterns and recommendations with the people involved, refine the prototype, and test again where needed before moving further into development. I don’t really see these four stages as a straight line. They form an iterative cycle that keeps the design connected to real user needs throughout the process.

Once a test is live, which signals do you pay attention to first: completion, time, clicks, recordings, comments, or something else?

Once the data starts coming in, my priority is to avoid getting lost in the numbers and focus first on actual user behavior. I want to understand how people navigate, where they hesitate, and what seems to be happening behind those decisions. Recordings and participant feedback are especially useful because they reveal things like hesitation, skipped steps, expectations, confusion, and how someone is interpreting the interface while using it.

After that, I cross-reference those observations with quantitative signals such as task completion, clicks, heatmaps, and time on task. These can help show whether the patterns you noticed during observation are appearing elsewhere in the study too. For me, the two sides work together: behavior helps explain why something happened, while the metrics help show how consistently that behavior appeared.

Learning and iterating

How do you tell the difference between a genuine usability problem and one participant simply behaving differently?

It’s very common for someone to interact with a prototype in a way you didn’t expect. The important question is whether that behavior points to a structural design problem or whether you’re looking at an isolated preference, habit, or unusual path. I normally consider four things: frequency, severity, alignment with users’ mental models, and how the qualitative observations compare with the quantitative data.

If the same friction appears across several participants, that gives you a stronger pattern to investigate. Severity matters too. Someone taking a different route and still completing the task successfully may simply be showing an individual preference, while a blocker that causes errors or prevents completion deserves attention even if it appears less frequently.

I also look at whether the behavior suggests a mismatch with the wider audience’s mental model, for example confusing copy, a hidden CTA, or unexpected information architecture. Finally, I cross-reference those observations with measures like task completion or time on task. Looking at the signals together makes it easier to separate meaningful usability problems from the noise that naturally appears in research.

If users struggle with something you were confident would work, how do you decide what to change in the next iteration?

This is one of the most common and valuable moments in UX research. When a solution I felt confident about fails during testing, I don’t want to react by making arbitrary changes. I start by going back to the evidence and understanding the root cause.

First, I ask whether the issue is about discoverability, comprehension, or the position of an action within the flow. Did users miss the CTA because of the visual hierarchy? Did the copy or icon conflict with their mental model? Was the action appearing at the wrong point in the journey? Then I return to the recordings, feedback, affinity diagram, and insights to understand what the user was actually trying to accomplish when the friction happened.

From there, I turn the finding into a new testable hypothesis. For example: “We believe that rephrasing the CTA copy and moving it above the fold will make the next step clearer and increase task completion.” Then I make a targeted iteration and re-test it. I avoid redesigning the whole screen at once because changing too many variables makes it difficult to know which adjustment actually made the difference.

When user behavior surprises us, it gives us a chance to put designer bias aside and let real feedback guide the next version.

Useberry and the workflow

Where do you see a tool like Useberry fitting into the design process, especially for people who are still learning UX?

For people who are just starting out in UX design, there’s often a misconception that usability testing is complicated, time-consuming, expensive, or something you only do at the very end of a project. For me, Useberry helps change that perspective because it makes testing something you can bring into the everyday design workflow much earlier.

You don’t need to wait until you have a polished, high-fidelity prototype. At an early stage, you can test a low-fidelity prototype to check whether the basic flow and structure make sense. If you’re working on information architecture, you can also run methods such as card sorting to understand how users naturally group and relate information. Later, once the design is more developed, you can connect an interactive Figma prototype and test more complete user flows and interactions.

Another important part for people who are still learning UX is getting comfortable with different kinds of research evidence. Useberry brings together things like heatmaps, clicks, user flows, recordings, open-ended feedback, and task results, so you can start connecting what people do with the feedback they give you.

Most importantly, I think it helps build an iterative mindset. It makes “test early, test often” much easier to put into practice, because you stop feeling like the design has to be finished before real users can see it. You learn to test, make a change, and test again, with actual user behavior informing the decisions instead of relying only on your own assumptions.

From your experience, what do you find most useful about testing a prototype in Useberry rather than relying only on internal feedback or presenting the design to others?

Internal feedback from teammates, PMs, and stakeholders is essential for alignment, but it also comes with limitations. Everyone involved already has some familiarity with the product, and discussions can easily be influenced by personal preferences, assumptions, or internal context that real users simply don’t have.

For me, the biggest difference when testing a prototype in Useberry is that we move from “what we think the user will do” to “what the user actually does.” Instead of relying only on opinions about how a design should work, we can look at behavioral evidence such as task completion, heatmaps, clicks, and the paths people take through the prototype.

There’s also something very useful about letting participants interact with the prototype independently during an unmoderated usability test. When you present a design yourself, it’s very easy to guide someone without realizing it, even with something as simple as saying, “Here is where you would click to sign up.” When participants work through it on their own, hesitation, misinterpretations, and friction become much easier to spot.

And finally, it helps with stakeholder alignment. Instead of spending a meeting debating which layout or piece of copy feels better, you can bring actual user behavior into the conversation. A heatmap, task result, or recording can make the problem much easier to discuss and give the team something concrete to base the next decision on.

A few lighter ones

What is one UX research habit you wish you had picked up much earlier?

Testing way too early, even when the concept still feels messy.

Early in my UX journey, I had the natural temptation to make prototypes look as polished as possible before showing them to anyone. That meant tweaking spacing, refining typography, and perfecting visual details before I had validated the foundation. The more time you invest in polishing a high-fidelity interface, the harder it becomes emotionally to discard or rethink it when testing reveals a problem.

Testing on paper or with rough wireframes makes it much easier to scrap an idea and pivot. It also keeps the focus on navigation, structure, and mental models rather than colors or styling. And it saves time and energy because you can validate the core experience before spending weeks refining a UI that might be built on the wrong foundation.

Learning to embrace the “imperfect” and letting early research influence the design is probably the UX habit I wish I had adopted from day one.

Putting on both the researcher and designer hat, what is more dangerous: falling in love with your design or falling in love with your hypothesis?

Falling in love with your hypothesis, by far.

Every designer has felt the trap of getting attached to a polished UI. We spend hours refining a layout or component and naturally become reluctant to throw it away. But that attachment usually stays at the level of a screen or interaction, and testing can eventually force us to confront the fact that it needs to change.

Falling in love with a hypothesis goes deeper because it affects how you interpret the research itself. If you become too convinced that the underlying assumption is correct, you can start asking leading questions, ignoring friction, or cherry-picking findings that support what you already believe. Falling in love with a design can mean building the wrong screen. Falling in love with a hypothesis can mean building an entire product around a problem that nobody actually has.

That’s why I think the healthier mindset is to stay committed to the user’s problem while keeping the hypothesis, concept, and design flexible.

Keep testing before things feel finished

Katerina’s answers come back to a simple but crucial UX research principal: research is most useful while there is still time to change the design. Testing early, focusing on the core flow, and being willing to challenge your own hypothesis can make the research cycle much more useful before decisions become expensive to reverse.

Thanks to Katerina Sotiriou for joining us for another Expert Talk and sharing such a practical look at moving from prototype to research and iteration.