Talk transcript

Kia ora koutou!

I'm Sneha Pulapaka.

Thank you, everyone, for joining me today. And thank you, Siena, for a lovely introduction.

I would like to actually begin with a question to this room. I'm sure there's a lot of product people here in the audience. And I want to start with a simple question. I want you to sit with it for a moment.

When was the last time you saw a data product or dashboard or a KPI or a number on a slide and really thought, can I trust this? Do I know who the owner is? Do I know when it was last refreshed? Do I know when it was double checked?

So if you've hesitated even for a moment, let me assure you, you are not alone. And this is what we are here going to talk about. And I would like to call this an invisible design.

So my name is Sneha Pulapaka. I have been working as an Insights Analyst and Product Owner. And I have spent 16 years across industries like pharma, clinical trial consulting, government, public health, and wellness.

In every sector that I've worked in, or every organisation that I have worked with, I have sort of seen a similar pattern. They've got exceptional data or infrastructure, IT infrastructure. They've got the best tools that they can use for data governance. But quietly, there are spaces where people won't trust the numbers or the data, or who is building the spreadsheets, or whether we need to call someone to check on the numbers.

So that is something. If something is not right, they don't know whether we can still trust the system. And today, I just want to talk about what is that missing bit.

So I would like to call it "Invisible design", like I said. And I want to leave you with three things. Make it visible. Create a safe space for people to ask questions. And the most important bit is mapping the journey, not just from iteration to the end, but actually asking whether the user at the end is really going to trust that data.

How many of you have been to Japan? Anyone who's travelled to Japan?

Oh my god. Awesome!

I love that country. I've been there in 2024. I went on a solo trip. It's my first solo trip to another country. I love the train system. And what I really find interesting about the system is that it's always on time. Not even a typhoon can stop the trains.

Everything is very streamlined. And that's the beauty of the system, because once you start having notifications and, if there's a delay or something, people are informed. So then it becomes easier to trust. So that's the trust we're trying to talk about.

And imagine that same system that you would want to create for your data product, for example. And how you would think about where the data comes from. Does it really tell me the story? Well, that's the analytical part of it. But do I even trust the numbers in the beginning? Is there a decision that I can make on the number? Or does it just kind of arrive like the train does in Japan, for example?

So this is what we're going to talk about. How are we going to design this for regulated industries?

And so I also want to borrow from our keynote speaker this morning, Norie, where she mentioned and emphasised that for innovation, it's really important to look at how it's not just the tool or the system that you're building, but it's actually the human behind it, and how important that is.

So if you are a product owner, a data analyst, business analyst, or a stakeholder, or even a developer, you might understand that when you are looking at a dashboard, knowing when it was last refreshed, for example, helps you not make a bad decision. I know there's one missing feature, but can I trust it? Those kinds of questions.

I want to specifically now talk about regulated industries that I've worked with. And what do we know about these industries?

They are definitely policy heavy, policy driven. They've got large volumes of data to deal with, right? And obviously, over time, we do notice that these organisations or industries would acquire technical debt, and that's something we cannot unsee.

And yes, these organisations or industries take governance really seriously. They do define roles. You've got your escalation pathways in place. You run compliance checks and audits and everything else. You tick all the boxes.

But still there are situations, like in data meetings, where you would end up with a question: do we really know where the number is coming from?

Or just 30 seconds after someone has shared a number, there's another person saying, "Oh, I think that's wrong, and I have another number."

So you can kind of see that it might be like a Post-it note situation because we need to confirm who's the data owner, or who's actually defined that KPI, who owns it, who's the steward, or who's even allowed the other person, who may not have authority, to look at that dashboard. So that's a custodian issue.

A lot of things can happen here. And regulated industries are the best place to actually understand invisible design.

Now, I'm sure some of you might find this scenario familiar. I'll give you a moment to just go through it.

So if we just add the three layers that I was talking about earlier, in this scenario, the advisor is requesting information, of course, but this still shows or signals that they don't trust the data because the advisor might not have been familiar with how the data people work or how the data team works.

It also could be that the advisor role, the person in the advisor role, their work scope is not put across to the other teams as well. So it could be a gap. And the signals in here are missed. So it's a signal issue. It's not a data issue.

So it's about how we are capturing those signals at different intersections.

So moving on, I'm sure everyone has a traditional dashboard with KPIs showing different metrics. But does it rely on memory or does it rely on a system of trust? That is what we're trying to look at.

If the person in the earlier scenario felt like they might have informed the system about going on annual leave, would that really suffice? No, probably it would need more than that. It would need more of a design lens.

So if I come back to my points about making trust visible, trust could have been made visible in all these scenarios through not only visual cues, but also making sure that people are on the same page about how the end user is going to use the dashboard and act on it.

So if we want to reflect, these are the five things I actually look at when I help teams across permit systems, because I work in mining and petroleum, and during audits of permit systems where permits are approved under certain regulatory policies.

So there are a couple of things that we keep in mind within large organisations.

So I would say, yes, is there awareness in the situations that we just discussed earlier? Were there enough resources? Yes, there were enough resources, but people still use data in spreadsheets. So there is the same data being circulated in two different forms.

And then, is there ownership? Yes, there was ownership, but people didn't know how to reach out to the person because the person wasn't available, or it was just a sticky note.

Was there business alignment? Definitely not, because the end user doesn't trust the data enough, so they wouldn't know if they can go ahead and say, yes, this is safe to use. And if it was publicly released information, then it would be a really big issue.

So were there any pathways? They didn't know how to go back and check. So that's another issue.

Feedback, I think, is the most important part because a lot of data governance tools that are implemented in organisations, yes, we've got everything. You may name a few like Informatica or Collibra and any others people might use. But does it tell you whether you can trust the data enough? That's the real question.

So what does it look like if we really invite this invisible design lens?

Yes, you would have the last refreshed date, for example. You would also maybe include who owns the data, for example, and that has context to the data lineage. And it is part of the user-centric approach because we've kept in mind who the end user is and how they're going to use it and how they're going to act on it.

Because in regulated industries, a single number could mean funding might be disapproved, or it could be a pharmaceutical drug that's going to come out. If there's no proper labelling on it, then definitely that's going to create a big issue.

So what practices could we use? Very quick, very easy, simple practices.

And I call it "A Decide Framework" because it was easy for me to remember and help my team as well.

I want you to focus on the green column because that is what we are trying to emphasise on.

Why have a clear, shared meaning of the metrics? That means I understand the number.

Assigning clear accountability or authority. I know who to go to.

Create traceability, of course.

Make data logic transparent. I see how this was created.

Invite questioning. Yes, that's very important. I think questioning might be taken in a very negative way, but I think it's more about making a safe space for people to ask questions. It's okay if it doesn't look right. I know I can ask the question.

Designing the pathways. We know there are escalation pathways, but do we know what happens next? Yes, I know what happens next. So that's assurance.

And yes, embedding these feedback loops. I think that is definitely going to help create or improve the experience.

So this is, again, something that I want to share. Whatever journey you are in, in these steps:

What do you ask for? Does the data exist? What decision does it support?

You need to define it first.

Name the owners, stewards, or whoever.

No dependency. That is a non-negotiable.

Define any critical rules.

And yes, you automate and document it.

But it's also about building capability here.

And where did this come from? That breaks into how do we map this journey I was talking to you about earlier.

So key things are obviously make it visual, create a safe space for people to ask questions about how data governance is handled in their organisation.

And the last one would be making sure that you map the journey, not just when you release the product, but also make sure you gather information after the product is released and understand how people are using it.

Because there are a lot of places where you can lose information on how it is being viewed or perceived, or whether it's being trusted. Because we're talking about trust here.

So I'm going to leave you with this: your data governance framework, in any organisation you work with, can be technically perfect.

But if ownership is unclear, or if you have not created a safe space for asking those questions, and if people cannot see how it works or how it is visually available to them, then it is definitely a design issue. It's not a data issue.

I would like you to think about it with the analogy of a pharmaceutical drug going into the market. You wouldn't say to a patient, "Hey, we just prepared this last Tuesday. Here you go. You can just have it and consume it now."

It comes with a label. It comes with a patient information insert. It comes with all those regulatory requirements.

So would you really put your name on a label like that?

So that's the question I want to leave with you all to think about.

And with that, thank you so much for being here and attentively listening to my talk.

I'm Sneha Pulapaka. I also work in spaces that sit at the intersection of systems thinking, data, and creativity.

So without any further ado, I would like to leave.

Thank you so much!