❋

Linkurious  | January-June 2025

Designing a trustworthy AI capability for investigations

Entity Resolution

About Linkurious

Linkurious is a software platform that helps organizations investigate complex networks of people, companies, accounts, and transactions. It turns connected data into interactive graphs, making it easier to detect fraud, financial crime, cybersecurity threats, and other suspicious activities.

The challenge

In real investigations, the same individual often appears under multiple identities across datasets. Investigators have to manually connect records and verify assumptions, which increases cognitive load, slows the work down, and raises the risk of error - all under time pressure.

To address this, Linkurious introduced Entity Resolution, an AI-powered capability that infers when multiple records likely refer to the same real-world entity, even when data is incomplete or inconsistent. It was a strategic capability to remain competitive in fraud and risk investigation space.

We decided not to build it from scratch, but selected an external partner who offered an advanced solution. It was the first time Linkurious collaborated with an external provider, and the first AI-based tool in our product.

Project overview

This project introduced AI-powered Entity Resolution into a B2B graph investigation platform to help investigators identify records that likely represent the same person or organization across different data sources.

My role

As the Product Designer, I led end-to-end research and design of the first AI capability in the product. I worked closely with a PM, in-house team and an external partner based in California.

I owned UX strategy for trust, risk, and human-in-the-loop decision-making and shipped a production-ready MVP that is now used by fraud investigators in real-life situations.

Results

30%

faster investigations

60%

beta conversion

DISCOVERY

Technical exploration and alignment

With all teams involved, we aligned on technical constraints for the integration of the Linkurious platform, the graph library (OGMA) and the external partner software (Senzig).

I examined a lot with our partner software to gain first-hand experience and did a updated my knowledge of AI, LLMs and algorithms.

Benchmark

I did extensive research on the topic and current market-ready solutions. While “best practices” did not really exist yet, I was able to better understand the market trends and current competitor offer.

User interviews

This was the most vital part of my discovery. I chose my interviewees carefully, using this methodology to find the most suitable people:

Pre-selection of clients: with the help of0 our CSM, I identified companies that had expressed needs that new feature was going to cover.
Comparing datasets: I checked which of those companies had the largest databases. This allowed me to prioritize contacting clients that were most likely to collaborate.
Analyzing user data in Kibana: I targeted organizations with the most users performing actions that suggested the need for data deduplication.

I tailored questions that would help me understand main pain-point around Entity Resolution and user expectations around it, as well as how our clients currently deal with this issue.

I run all the interviews, and analyzed the results and presented findings to my team.

Main learnings:

Surprisingly, almost none of our clients used AI in their investigative work, and they expressed deep distrust of AI in general. Their main concerns were data privacy and the fear of black-box, probabilistic results. Investigators were afraid of being held responsible for inaccurate AI predictions. If we wanted to achieve strong adoption, we had to address these concerns immediately.
Amongst others, there were two main personas involved in the process of setting up datasets and investigations. While their responsibilities were distinct, their decisions directly influenced the quality of the output. I identified a significant risk of silent errors and responsibility shifting that could affect the future of the project if the workflow between these personas was not carefully designed.
Integrating an external solution into our software introduced many technical limitations that I had to keep in mind throughout the design process.

Core challenge: two user contexts, two types of risk

Admin - configuration risk owner

Responsible for mapping the organization’s data model to the Entity Resolution algorithm and enabling it for the team.

Because configuration happens infrequently and its impact is only visible later during investigations, errors at this stage can silently affect result quality and undermine trust.

In some organizations, the same person later acts as an investigator, increasing the importance of clear guardrails and validation during setup.

Investigator - decision risk owner

Analyzes AI-generated entity groupings inside the graph to identify suspicious behavior and decide how to proceed.

Investigators cannot modify the configuration and must rely on outputs they did not set up themselves. This makes clarity, confidence signals, and validation mechanisms critical for adoption.

IDEATION - GENERATING IDEAS

User Journey Workshop

After sharing all my findings and deliverables, I organized a workshop with Product Manager and CTO to define the main steps of the User Journey for the two main personas.

Our back-end developers were still building the API between Linkurious platform and out partner’s system, so we were aware that things might change, and the journey would not be final, but it would help us conceptualize the flow.

This exercise gave us a general view of what kinds of screens might be needed and helped us identify which ones were likely the most important. It also allowed us to identify technical risks and potential issues for the architecture.

Workshop board in progress.

Brainstorming

Next, I invited the whole team to help me ideate on a few key screens that I identified.

I briefed them on the project and shared my findings. Then, I asked them to sketch their screen ideas using the Crazy 8’s method. Next, I facilitated a brainstorming session where we generated even more ideas, and also discussed how else can we use Entity Resolution in our software.

This workshop allowed the team to better understand the work coming, while also provided me with many promising ideas to explore now, and some exciting concepts for possible future iterations.

User Story Mapping

At this point, we had too many ideas to pursue. To make us move ahead, I facilitated a User Story Mapping session, where together with my Product Manager we decided ruthelessly edited the scope.

Based on the need, value and feasibility we decided which features would get into the MVP, which ones were likely fot iteration 1 & 2, and what should be pushed to the backlog for now.

Now we were all able to plan our work.

Workshop board transferred to Miro.

DESIGN PROCESS

Design decisions

User interviews showed that while clients were aware of Entity Resolution as a concept, they struggled to predict how probabilistic matching would affect their workflows. Trust was the primary concern: users wanted to know when results could be relied on, how errors could be detected, and how AI outputs could be validated rather than blindly accepted. To address this, I made a few important rules for the design:

Prioritize configuration clarity over automation.
While higher levels of automation were technically possible, they would introduce a high risk of silent errors. For the MVP, I chose to expose configuration steps explicitly (with guardrails and contextual guidance), so that administrators could understand how their data model connected to the algorithm and verify the setup before enabling it for investigations.
Separate the admin configuration experience from the investigation experience.
It allowed each flow to be optimized for its specific risk: reducing the risk of misconfiguration on one side, and supporting confident decision-making on the other.

These decisions aligned with regulatory expectations around auditability, accountability, and human oversight.

Iterating & testing

I went through multiple iterations of wireframes and then high-fidelity mockups. One of the reasons was of course adjusting to testing results. I also had to make multiple corrections as new constrains were being discovered by the technical team.

Interactive prototype

After many iterations & internal testing rounds, I prepared an interactive prototype in Figma to test the MVP.

Using this prototype, I ran two rounds of User Testing with our clients, and adjusted the final design to the feedback I got.

Recording of the interactive Figma prototype in action - entity mapping settings.

Live reveal

Close to the end of the testing phase, I had the opportunity to present the prototype live in London during our yearly client conference and roadmap presentation.

Most of the attendees saw the feature for the very first time, and I gathered a lot of thoughtful insights. Some of the most valuable tweaks were integrated into the final design immediately. I also compiled a list of potential enhancements to be considered in later stages of the project's development.

DELIVERY

Developer handoff

I organized a live handoff session, during which I presented the final solution to the developers and answered all of their questions. The materials I handed off included:

an interactive prototype
a detailed, annotated design file
documentation for more complex areas
an edge case matrix

I was also available throughout the implementation phase to answer questions and make last-minute adjustments when new constraints were discovered.

Design System update

I updated our Design System with new components created during this project.
I also enriched our Storybook Design System documentation with usage guidelines and best practices for applying these components correctly.

Visual QA

Once the development phase was complete, I reviewed all the coded flows to ensure everything looked and behaved as intended.

To do this, I rely on my custom Visual Validation Matrix - a checklist I created to systematically validate every aspect of the final product and make sure nothing is missed.

FINAL DESIGN HIGHLIGHTS

Intent: Reducing the risk of silent misconfiguration of AI

Entity Resolution quality depends on how data is mapped and configured. Because configuration happens infrequently and errors are not immediately visible, a single mistake at setup could silently compromise all downstream investigations.

I needed to reduce the likelihood of incorrect configuration and make setup consequences legible before the feature was enabled for investigators. I prioritized safety and understanding over speed, acknowledging that configuration was a high-impact moment in the user journey.

Explicit data mapping instead of automation
Rather than mapping data in the background, the manual configuration makes all relationships explicit, reducing the risk of incorrect assumptions when connecting graph-based data to a tabular AI model.

Inline guidance and constraints
Contextual hints and required fields help admins make informed decisions without needing deep knowledge of the underlying algorithm.

Immediate feedback on configuration quality
The accuracy indicator surfaces the impact of configuration choices early, allowing admins to validate and iterate before enabling the feature for investigators.

Intent: Making probabilistic AI results transparent for investigators

Investigators rely on Entity Resolution outputs to guide real decisions, despite not having configured the system themselves. If results appeared opaque or arbitrary, trust would erode quickly.

I supported investigator judgment by embedding AI results into existing graph workflows, rather than presenting them as isolated outputs. The goal was not to replace investigator expertise, but to enhance it.

AI results presented as groupings in graph, not final result
Entity Resolution outputs appear as visual clusters in the graph - where investigators spend the most time. User can continue investigation them the best they see fit.

Investigator control over AI behavior
Grouping thresholds and resolution settings allow investigators to adjust how conservative or permissive the AI should be, depending on the investigation context.

Contextual validation through the graph
By seeing grouped entities alongside their relationships, investigators can validate AI suggestions against known connections and patterns.

❋