i-refact
Revolutionising data exchange for control and simplicity.
When the founders of i-refact, Rene Haasdijk and Erik Jansen, approached me, I immediately recognised it as the kind of challenge I am drawn to: complex, ambitious, and in a sector new to me.
The initial proposition was not straightforward. Based on their experience, they had identified challenges in data exchange and developed early ideas for possible solutions. My role was to help shape these ideas into a concrete product vision and validate them through structured research and design.
It remains one of the most rewarding projects I have had the privilege to contribute to.I pushed myself to explore uncharted territory, often re-framing the problem definition to uncover more fundamental opportunities. This ultimately led to a transformative solution. I learned immensely through design sessions, experimentation, iteration, and occasional failure, and engaged in some of the most rigorous product design thinking alongside the founders, subject matter experts, architects, and clients.
Role:
Lead – UX research, design, prototyping, design system, visual design
Client:
i-Refact, s’hertogenbosch
Date:
1.Jan.2023 – Present
Initial Steps: Are We Thinking in the Right Direction?
The client, working with commercial banks and financial institutions, felt that a structured way to collect data from external partners was needed. They observed that the existing data collection processes relied on email chains, spreadsheets, and manual follow-ups, creating compliance risks and placing a heavy burden on both internal staff and the external partner organizations submitting data. There was no dedicated product, no shared language, and no feedback loop. Because this was a 0-to-1 product, there was no prior research to build on. My first task was to establish who to talk to and what we needed to learn before any design could begin.
At the outset, the founders posed a fundamental question: Are we approaching the problem in the right way? Is this a real problem? Before investing in development, they wanted to ensure that their assumptions about data exchange challenges were valid and that the proposed direction addressed real user needs. This is exactly the kind of ambiguous, early-stage situation where strong product thinking matters! It’s all about shaping the problem definition and direction before proceeding to product conception and interface and interaction design.
Discovery Mode
Internal Discovery
The founders initially approached the problem from a solution perspective. My first step was to reframe their statements into user-centered problem hypotheses to make them testable through research.
“Mid-sized regulated enterprises struggle to securely exchange structured data with external partners due to fragmented tools and compliance barriers.”
“Data product teams struggle with unforeseen data quality issues when consuming external datasets, leading to operational disruption and reputational risk.”
“Misalignment in semantic interpretation between data providers and consumers leads to misuse of data and reduced trust in automation outputs.”
” Unexpected structural changes in exchanged datasets frequently break downstream pipelines and require reactive engineering fixes.”
” Limited visibility into upstream transformation logic makes it difficult for data product owners to trace and resolve quality issues.”
* Reformulated few examples of initial statements from the founders
The main challenges in reformulating the statements were keeping them short and clear while ensuring they remained testable. It was also important to avoid making them solution-oriented and instead focus on the problem itself. Additionally, the statements needed to target only one or two core user groups, avoiding the inclusion of multiple segments that could make them less precise and harder to evaluate.