From Exploration to Optimization: UX Research Under Time Pressure

Awareness of the importance of the user’s voice in developing new features continues to grow. In practice, though, how much research teams can do, often depends on how much time product teams have available.

As a result, UX Researchers are sometimes brought in only to test solutions that have already been designed or even implemented. This leaves less room for researchers to influence the direction of the product in the first place.

In my experience, UX Research can add value at almost every stage of product development - from understanding what users actually need before we start building, through testing early ideas and prototypes, to learning from real behaviour after a product goes live.

But what happens when there’s simply no time for a full research project?

In this article, I’ll take you through the different stages at which we use UX Research at XTB, the methods that can help us make better product decisions, and how we adapt our approach to get useful insights quickly, when deadlines are tight.

When is the right time to do research?

When should UX Research come into the picture, and how do we approach it at XTB?

1. Before development starts: understanding user needs

Exploratory research
Research at this stage helps us avoid one of the most expensive mistakes a product team can make: building a feature that nobody needs or that fails to meet its business objectives because it isn’t useful enough.

So, what can we learn by researching early?

• We understand the context: We explore how users think about saving and investing and how these activities fit into their everyday lives. We learn whether they would consider using the solution we’re proposing and what conditions it would need to meet to be attractive to them. Most importantly, we get a better understanding of their needs, motivations and experiences, all of which shape how they perceive our products and solutions.
• We uncover barriers: We identify concerns, for example, fear of losing money or difficulties understanding how financial markets work, before the first design is created. This means we can address many of these barriers from the very beginning.
• We learn from competitors: We look at what works well elsewhere and what may frustrate customers, using methods such as benchmarking or desk research, including mystery shopping.

This early understanding gives product teams something valuable: a direction based not only on assumptions, but also on what users actually need.

2. After solutions have been proposed and designed: evaluation

Prototype testing

This is the moment when we ask: does it actually work?

We test whether our design assumptions survive contact with reality. And there’s a practical advantage to doing this before development begins: changing a prototype is much faster and less costly than changing a finished product.

What can we test at this stage?

• Usability of proposed solutions: Before developers write the first line of code, we check whether the new service will actually help customers achieve their goals. We test Figma prototypes using both quantitative methods and user interviews.
• Clarity of the information architecture: We check whether the paths leading to different features are logical and whether the amount of information is manageable for the user.
• Accessibility of the service: We want our interfaces to be inclusive and comply with relevant regulations from the earliest stages of design. We recently conducted our first interface research with people with disabilities and plan to continue this work.

And this is where research can make a particularly visible difference: problems are still relatively easy to fix because the product hasn’t been built yet.

3. After launch: optimization

Post-launch research

A digital product is a living thing. Once it’s launched, we can finally see how our hypotheses hold up when the product is used at scale.

Many studies conducted before launch are declarative or take place outside the context of real product usage. That’s useful, but it’s not the whole picture. The hypotheses that guide digital products need to be continuously tested and updated.

So, what does that look like in practice?

• We analyse customer behaviour: We monitor metrics to identify exactly where customers get stuck. This allows us to spot problems and optimize conversion in the app on an ongoing basis. We also segment our users so that we can better understand different groups over time.
• We test different variants in real time: In investment services, conversion is influenced by much more than the interface itself. Macroeconomic events, for example, can have a significant impact. That’s why we compare alternative interface versions through A/B testing.
• We monitor satisfaction and overall perception: We continuously track how users evaluate our app and its individual features throughout their lifecycle. We use metrics such as CES, CSAT and SUS. This helps us understand how updates and changes affect these indicators and whether users feel we’re moving in the right direction.
• We listen to what customers say online: We analyse reviews users leave in places such as app stores. Recurring comments and feedback often give us a ready-made list of areas that may need improvement.

In other words, UX Research doesn’t stop when a feature goes live. If anything, that’s when a new source of information becomes available: real behaviour at scale.

What if there’s no time for research?

There’s a common perception among stakeholders that research significantly slows down the development of new features. And if we only look at the development phase itself, that can certainly seem true.

But here’s the thing: launching a product or service is only the beginning of its life. It’s only after launch that we can really assess whether stakeholder expectations and business assumptions have been met.

From this perspective, research doesn’t necessarily make product development slower - it can help us save time and resources. By reducing the risk of expensive fixes after launch, research can bring us closer to achieving our business goals.

Does that mean we conduct UX Research at every single stage of product development?

Of course not

In a large organization, time is one of the biggest challenges for researchers and often one of the reasons decision-makers decide not to run research at all. Planning often happens without research specialists involved, while leaders need to balance the pace of development with stakeholder expectations.

Still, we want to support decision-making even when time is tight. The key is to choose research methods flexibly and find the right balance between the time required and the value we can get from the research.

Research results don’t have to take weeks to arrive, and not every research project needs to be planned a quarter in advance.

So, how can we use UX Research at different stages of development when time is limited?

• Exploration: The team is ready to start work on a new feature and the launch is planned for the next quarter? In this scenario, user interviews or ethnographic research may not be realistic. But we can often conduct desk research, analysing existing data and reports or competitive benchmarking within just a few days. We can also look for relevant examples from other industries and use them as inspiration.
• Evaluation: There’s no time for in-depth usability testing? There are many tools available that allow us to run quick quantitative tests with large groups of potential users, including Useberry, Maze, Userlytics and others. We can use five-second tests to evaluate first impressions or run unmoderated tests on a prototype. A/B tests on alternative prototype versions can also support quick design decisions. And if there’s no time to recruit research participants, even short hallway testing can be useful, simply asking colleagues who aren’t involved in the project for their feedback.
• Optimization: At this stage, product analytics is our starting point. With properly configured data collection, we can quickly identify where users encounter difficulties. It’s also worth introducing contextual questions within the app, for example using Survicate or similar tools, to collect user feedback on a specific topic quickly.

Choosing the right research method is only one part of the equation. We can also influence how quickly research findings reach the teams that need them.

Detailed analysis of qualitative research can take time, which is why we recently introduced Topline reports at XTB. These are condensed summaries of the most important observations prepared shortly after a study is completed. They allow teams to start working while they wait for the full research report.

A Topline report includes:

• answers to the most important research questions,
• the key observations identified before the detailed analysis, grouped into critical, medium and low-severity issues, positive and neutral observations, as well as opportunities and ideas,
• conclusions and recommendations based on the observations,
• research excerpts supporting the identified problems.

This approach allows us to get useful insights into the hands of product teams faster, without having to wait for every detail of the final report.

Selected UX Research methods

We’ve already mentioned quite a few research methods and the situations in which they can be useful. Let’s bring them together and look at which methods work at different stages of app development, along with their main advantages and limitations.

UX Research when time is limited

Our team’s wish is that the role of a UX Researcher at XTB would go beyond simply delivering reports. Above all, we see ourselves as partners to both business and technology teams.

Time constraints are part of everyday product development. But they don’t necessarily mean giving up on research. The key is flexibility: choosing the methods that can deliver the most value at a given point in time and adapting the depth of research to the decision that needs to be made.

By building a data-informed culture focused on user needs, we can make UX Research a practical part of product development, even when deadlines are tight. Ultimately, this helps us build products based not only on what we think users need, but also on what we learn from them along the way.

I hope some of these approaches prove useful in your own work. If you’re working in UX Research or product development and would like to exchange experiences or have any questions, feel free to reach out to me. And if you’d like to explore how we approach UX Research at XTB in more detail, take a look at the article of our UX Research Manager, Marek Trawiński: “Thinking Like our Clients: UX Research at XTB”.