Data Validations

Team

1 Product Designer, 1 Tech Lead, small internal team

Hired to analyze data. They ended up auditing files.

First, the context: I was a designer at a data consultancy, and HDI, an insurer, was our client. The end user of the project was HDI's Analytics team.

And that team had a problem. An Analytics team should spend its time analyzing data, this one spent more time fixing data than looking at it. They were responsible for building dashboards from market data, but part of their routine was handling public vendor data: thousands of files, full of errors, corrected one by one, every day, by hand. The analytical work, the very reason the team existed, took a back seat.

Goal: simplify and automate this data-handling process.

The problem wasn't the product. It was me not understanding the problem.

My biggest challenge on this project was not a design one. It was that I did not have the technical background to understand, on my own, the pain of the people I was there to help.

In the meetings and interviews with the technical team, I got lost. They talked about pipelines, validations, error scenarios, and I could not map where each pain happened in the process. A designer who does not understand the problem does not design the solution; they design a pretty guess.

So, instead of pretending I understood, I built a system to work around it.

The solution was an exchange, not a rescue.

I brought a tech lead in for active participation throughout the whole Discovery. But not as a crutch, as a partner in a two-way exchange:

• She translated the technical side for me. Every pain reported, every step of the process, every why, she turned it into something I could map.
• I taught her how to research. In the parts of the workshops I could not run on my own (for lack of domain knowledge), I taught her research methods, how to ask less biased questions, how to facilitate without leading the answer. That way she covered what I could not reach, without contaminating the findings.
• And we closed together. At the end of each round, we ran a debrief: I took what had come out and translated it back into simple language, making the problem statements evident for the rest of the team.

The result of this dynamic did not stay inside the project, I come back to that later.

I thought it was one pipeline. It was three.

I entered the project with a comfortable hypothesis: the validation pipeline was direct, linear, a single thing. Automating seemed like a matter of mapping the steps.

I was wrong.

In reality, there were three different pipelines, and, in the middle of them, several mapped scenarios that automation simply could not resolve. These were cases that had to, necessarily, defer to a human decision. Finding that out early changed the entire design of the solution: it was not enough to automate and make the manual work disappear; I had to design for where the human steps in when the machine cannot cope.

Before designing a screen, I documented what no one had documented.

This team worked with these validations every day, so they already knew, in practice, which steps mattered most for clean data. The problem? None of it was written down anywhere.

I started with a workshop, in three moves:

Mapping the types of validation,to understand the scope and give the tech lead what she needed to study automation scenarios.

Voting on the highest-priority validations,to make roadmap prioritization easier.

A 5W1H exercise on each validation,to measure impact and align the team on what came first.

She built the pipeline. I translated it for laypeople.

With the map in hand, the split was clear: the tech lead ran the automations, the technical pipeline of the solution. I took care of translating all that technical logic into a value-delivery language and designed the screens, in a way the business team could understand too, not just the technical team.

Not everything could be automated. And that became part of the design.

Remember the scenarios that required a human decision? They defined the solution. Even automating error detection, correcting some of them would always need people, and specific cases required specific handling. Without planning for that, too much data would simply be discarded from the analyses.

That is why I designed an interface for a validation funnel: errors that are easy to spot, with clear handling whenever a human adjustment was needed. Automation handled the volume; design handled the exception.

The delivery

• Block-flagging pages, one for each type of validation, showing exactly which file got stuck and why.
• Validation history, a central, analytical view to track progress and spot error patterns over time.

The result that outlasted the project

The flow was validated and the manual, exhausting process gave way to a clear funnel, with the human stepping in only where it is really needed.

But the bigger impact did not fit inside the project, nor did it stop at HDI. The research + technical-translation dynamic I created with the tech lead worked so well that it became a reference for the TaaS model of the consultancy I worked at. Today there is a design and development stage in the onboarding of the consultancy's projects, and I co-led that initiative together with the tech lead and a manager of ours.

What I take from this project

• Not understanding the technical problem is no excuse not to lead, it is an invitation to collaborate better. Instead of hiding my limitation, I turned it into a system: I taught research, the tech lead translated the technical side. Both sides came out stronger.
• Reality is almost always more complex than the hypothesis. I thought it was one pipeline, it was three, and what automation could not solve was as important to design as what it could.
• Good process scales beyond the project. The biggest result here was not a screen, it was a way of working that the whole consultancy started to use.

Let's talk?

Open to new projects, partnerships and conversations about product and design.