Sometimes, research feels only valuable when it results in a great prototype, which was tested and then developed to bring impact to the users.
But sometimes success can look very different.
UX Research also helps to prevent something from being built.
The key is that research results in actions and informs decisions
- whichever way the decisions may go.
Before diving deeper, I want to provide some general information to set the scene.
The bigger picture
HDI is a global insurance company with several carriers and branches across the globe.
As much as I love international companies, this structure does not make it easy to simplify and standardise processes.
However, this is one of the key goals of the lighthouse strategy called the Insurance Core Platform (ICP). It consists of three main applications and multiple dependencies to other teams and products. I am working on the contract management system and due to our structure and many dependencies, I work across multiple Agile Release Trains (ARTs).
Even though we are a big team, I am only one of three UX Designers, of which two Designers focus on UI Design.
Working on this global initiative, I seek opportunities to support decisions with research. Insights are only truly valuable when they shape decisions.
The earlier the research, the better?!
Having worked on a concept of how to measure the impact of UX, I learned that each adjustment made in the code is significantly more expensive. Especially compared to identifying it earlier through e.g. prototypes.
In short: The earlier we validate key hypotheses, the cheaper and less risky changes become, thus de-risking software development.
Coming back to simplifying and standardising processes internationally:
How might we de-risk ICP by identifying opportunities for streamlining processes and user flows through user research?
To explain our approach, I will begin by offering insights into how we identified the opportunity, followed by the Pitch to build a case on why we need to dig deeper. The third section is about the process of validating the user request leading to the final decision. Lastly we zoom in on reflections: key challenges, how I overcame them and which takeaways I learned from the overall experience.
1. Identify
Planning
In Q3 2025 we had our ICP kick-off meeting in Athens, Greece. At this point, it was already known that we will be rolling out ICP in early 2026 for multiple lines of business. From our team perspective, a Business Analyst and I decided to use this opportunity to conduct research.
Our goals were fourfold:
- Start building a relationship of trust: Sharing honest opinions, impressions and letting them know we are here to learn from and with them to make their daily work-routines better.
- Analyse the existence of key requirements: Are there any „must“-topics e.g. from legal we need to be aware of and implement before roll-out?
- Workflow differences compared to other users: At this point, we already knew that role descriptions vary deeply to other branches, partly due to the size of the Greek office. The smaller the branch, the more responsibilities belong to fewer people, meaning people tend to have a bigger scope of responsibilities - much like in start-ups!
- Identify further pain points: Based on the knowledge we collected, we wanted to identify areas we can already address without having to adjust the roadmap, as this is very difficult to achieve and needs lots of alignment. This mostly focuses on topics with the least dependencies to other teams.
Research on location
We had two days together of which we could use about half a day for user research. I had prepared an interview guideline consisting of several sections as well as a mindmap to visualise the most important questions and their relationships to each other. In addition our Business Analyst had prepared a run-through of the end-to-end flow.
With these preparations, we were ready to get started!
Pretty soon, we started talking to a colleague from Finance, who told us about approval processes they have in place right now. With the new software, these processes are not supported (and may not be needed any longer). During the interview and also afterwards, she shared her opinions and showed us how and why she followed this workflow.
With this first understanding, we decided it was something we should look deeper into - because of the critical change in processes and because it was important to her and we wanted to show that her opinion mattered.
2. Pitch
Since ICP aims to standardize processes, it is difficult to build a “local solution“ for a certain pain point. At this time, it was still unclear if the pain would result in a local solution or work towards global standardisation, so I decided that we needed to identify other users from other countries to find out if they share the same need.
In addition we made sure the result would align with the target architecture designed by business and solution architecture.
As an Experience Designer, I understand that in order to build a solution to a problem, it is not enough for one user to have this problem - it also needs to scale.
At the same time, I worry about user needs being ignored, because it may be too time consuming or complicated to go through the entire process of alignment. (Which is what almost happened in our case). Instead, I initiated a discussion and offered to validate this user need for approval processes. I pitched to conduct a survey which I wanted to send out to several countries (countries, who already use ICP, will use ICP or have different circumstances and thus a valuable additional opinion).
My Product Owners agreed that we should validate the need with other countries before developing something we think they need - so then I proceeded.
3. Validation
I built the survey and focused on finding out about existing approval processes, then drilling down to certain departments and interactions between different roles. Sadly, due to legal restrictions, I was not able to send out the survey to our international colleagues.
With this change in methodology and more dependencies to other colleagues, I realised it may take more time than expected to validate the need, so we decided to start two parallel streams:
- 1st Stream: Validating the need
- 2nd Stream: Exploring possible solutions with minimal effort by aligning with Devs and building low-fidelity mock-ups.
I organised a slot in our international committee focusing on the operations capability. The audience consisted of operations managers from different lines of business and countries. Luckily, many of our current and future countries were present.
Based on past research, our initial hypothesis was:
No other countries share the need for this specific approval process. If we were to still implement a concept, it would result in a local solution.
Before the session, I sent out material for them to look over and review with their subordinates doing the operative job. I facilitated our session and firstly focused on their own approval processes before asking them about the specific use case. This way, I wanted to make sure they were not biased.
Our Business Analyst joined for the session and took notes. We found out that none of them had similar approval processes in place. In fact, they labeled them as “inefficient“ if everyone had to adapt them.
They didn‘t just not have similar processes in place, but also disapproved of making them part of future processes.
Throughout our validation, we held bi-weekly meetings with our Greek colleagues and updated them along the way.
4. Decision
After the committee meeting came to an end, we quickly reconvened with our POs to come to a mutual decision to not pursue the implementation of this approval process further.
In our next bi-weekly, I recapped how we came to this decision and sent out another explanation mail to the colleagues directly impacted by this.
It was important to me to not just communicate the result but explain the ‘why‘ behind it, so that our colleagues know we took them seriously, validated and concluded to a decision. We didn‘t blindly reject building a possible solution.
This way, we saved time and money in development and prevented a high level of frustration in the team that comes up when something is built but not used.
Finding out that something doesn‘t need to be built is also a success, even though it may feel a little less satisfying. It’s a good thing to avoid building something that won’t get used. 😊
Reflections
Facing challenges in corporate ambiguity
- Initial quantitative research was not actionable
When I first planned to send out the survey, I was looking forward to growing further in this area. When our data security colleagues made clear that I was not allowed to send out a survey through the committee - but only to our users and colleagues directly - I knew I couldn‘t move forward with this approach. It would have taken valuable weeks to collect all the email addresses of colleagues across the globe.
I compromised: I moved forward with the validation through the committee, whilst at the same time laying the groundwork to build a user pool we could use for the next time it was needed.
Staying flexible about the research is always important - it‘s not about falling in love with a certain method, but rather focusing on what the goal is and then deciding which routes to take. - Making our Greek colleagues part of the validation journey
We first identified the need for certain approval processes on our visit to the Greek branch. The validation happened with a committee, which Greece is not a part of.
Making this process transparent to our colleagues was very important to ensure we are taking them seriously and truly validate their need.
Once the decision was made not to pursue this further, I wasn‘t sure on whether I should update our colleagues as the researcher, or if it better comes from the PO, who actually does the prioritization. In the end, I presented and explained the case.
When standardising processes on a global level, it is important for users to feel like they are part of the process and not just a small wheel in a big corporate machine.
Takeaways
- Proactively offer research to support POs and PMs
When I made the case to dig deeper, I offered different approaches to collect data in order to make an informed decision within a realistic timeframe. This proactive approach enables POs and PMs to immediately notice the positive impact of UX Research in their daily lives.
Even if the research is not as holistic as I would have liked, it is highly valuable to de-risk the prioritization process and thus software development (and definitely better than to just build something because someone said it’s important).
Once they notice how UX Research can help, the result is them actively including you when they are in need of more information. This is exactly the kind of relationship I am aiming to foster.
By offering research-driven approaches to support decision-making, we build trust in UX and ensure decisions are insight-based and hypotheses have been tested.
In my opinion, this is the biggest impact we can have on a project: Making sure the facts it is based on are facts - not invalidated hypotheses. - Take what you can get and roll with it
Of course it would be great to do a multi-day research study. And sometimes this is actually possible.
However, whenever branch visits are planned by management with researchers piggy-bagging to get exposure to the users, research is obviously not the sole purpose of the visit.
With this in mind, it‘s easier to work with ever-changing schedules and research slots.
In our case, I initially planned with one day of research. Two days before this slot was reduced to 3 hours.
It‘s important to be flexible and always have a prioritisation to ensure that the most important topics can get covered. Also, always pre-plan which parts could be done remotely as a follow-up and what is best done in person.
If the worst case happens: Keep in mind that building a trustful relationship is often the most important thing on a visit (if your users are also your colleagues 😉).
So don‘t stress, stay focused and make some time to laugh and make jokes! This often builds a great base for a follow up session. - Timely Validation
In this case, the research itself shouldn’t take a long time! Management wants to make quick decisions, so research needs to stay efficient whilst generating insights.
To ensure insights will be generated on time, it‘s essential to frequently check-in and update each other on the status quo. As a researcher, I often have options laid out to make it easier for the POs to understand the different research approaches and their consequences.
I believe this correlates with the UX maturity of the company:
The lower the maturity, the more one needs to proactively offer support, thus showcasing the benefits of UX Research. The higher the maturity, the more does management already know about how UX can be used, thus involving the UX Researcher when needed and often providing more time to conduct the research itself. - User vs. Management
In this case, we decided to validate our hypotheses with a committee consisting of operations managers from several different countries and lines of business.
Due to two reasons, we decided this would be a good way forward:
- Most of the managers used to be portfolio managers, who operatively did the work, so often they still know the processes.
- If they don‘t know the processes, we know they align with their subordinates to get their perspective. Often times they send their feedback to us prior to the session. So even though management is not our user, we still get their perspective.
In an ideal world, there would have been enough time for holistic research, alignment with other users from other countries (not ‘just‘ management!) and based on this - a final decision.
But being part of a strategy like ICP means being aware of dependencies and being able to manage them.
In complex environments like this, we generate impact not just by what we build - but also by what we decide not to build.
No Comments.