Designing Trust: Data Governance for AI
Designing data product governance in SAP Business Data Cloud around the question people actually ask: “What needs me?”
Client
SAP
Service
UX Design
Role
Sr. UX Designer
Year
2026 – Present
Since April 2026 I’ve owned the design of the post-MVP phase of Data Product Governance in SAP Business Data Cloud: domains, scoped roles and a governed access-request workflow.
The insight that shaped it: people with governance duties don’t think in objects or org charts. They think in terms of “What needs me?”
I ran the work on a persistent AI workspace that turned recordings, decks and wikis into design-ready specs.
Notes like this one mark where AI changed the outcome.
Work Details
Context
SAP Business Data Cloud brings a company’s data together as data products. Data Product Governance adds a governed, auditable access layer on top: data owners and stewards decide who can use which data products, under what terms and for how long, and consumers discover them and request access.
The MVP, designed by a colleague, set up a single default domain and the core access-request and usage-agreement lifecycle. I picked up the work from there.
Problem Statement
Before governance, there was:
No organizational structure: no way to group data products by who owns them.
No formal agreement: nothing turned an approval into a traceable, auditable record.
No follow-through: no consistent way to act on an approval once it was granted.
The tension behind the hardest decisions: governance has to be strict enough to be trusted and audited, but light enough not to become a bottleneck where a steward has to approve everything. That matters more as companies point AI at their data, because an AI agent can’t tell trusted data from abandoned data unless ownership is clear.
My Role
I own the design of the post-MVP phase end to end: research, information architecture, interaction design and the prototype. I co-lead the overall project with my design lead and work with product managers, engineers and architects. The scope covers multi-domain support and the next stages of the access lifecycle.
How I Worked
Framing. I turned epics, wiki pages and stakeholder decks into design briefs, an information architecture and a UX tracker.
Role model. I studied how SAP Datasphere handles scoped roles, documented its pain points and proposed where Business Data Cloud should differ. Every assumption that conflicted with the real grant model, AI’s and ours, I corrected and logged.
AI cross-checked my role proposal against the technical source of truth I designated. That check surfaced the conflicts before they reached engineering.
Exploring directions. I explored two information-architecture directions, object-centric and domain-centric. Research with six customer organizations, two to three people from each, then retired both in favour of a third.
AI kept every direction alive as navigable history in one prototype, so the team could compare them side by side instead of from memory.
Prototyping. I directed an interactive Governance Design Portal, an AI-built SAP UI5 prototype covering several user stories.
Design reviews. I reviewed the designs against SAP Fiori and the live Figma files, checking for missing states and microcopy that drifted from house style.
Measurement. I kept “How do customers know governance is working?” as a standing question in every readout.
Design Approach
Key Decisions
Start from the work, not the catalog. Research showed that people with governance duties think in terms of “What needs me?”, not objects or org charts, so I organized the starting point around each role’s pending work. It beat both directions we explored first.
Make ungoverned data impossible to miss. Data with no clear owner is the real risk in a governed system, so I designed it to stay visible by default instead of sinking into a backlog.
Reuse a pattern people already know. Instead of inventing a new permission model, I built on the scoped-role pattern SAP Datasphere users already understand, adapted to how governance works here.
Different exits mean different things. Access can end for different reasons, and an audit trail has to tell them apart, so I kept those paths separate even where one action would have been simpler to build.
How AI Shaped This Work
A system, not prompts. Every correction became a durable rule, so the same mistake didn’t come back.
The workspace is a repository of briefs, scope docs and decision logs that Claude reads as context, plus a memory layer with the project’s hard rules.
Verification over trust. I treated AI output as a draft to check against the source, never an answer. When a wrong family of status names slipped in, I caught it and turned it into a rule.
Prototypes, not just specs. I prototyped with AI as well, directly in SAP UI5, so the team reviewed working prototypes instead of static screens.
AI built and iterated the UI5 prototypes with me, which sped up how fast I could try a concept, put it in front of the team and move on to the next one.
“Thanks for sharing, I really love these prototypes, they really help to get a clear picture.”
Product manager on the team, reviewing the UI5 prototypes
Results
Design-final for scoped roles and domain privileges in October 2026: an eight-screen final that replaced an earlier 21-screen revision.
Two information-architecture directions explored and retired by research with six customer organizations, two to three people from each.
The work is in elaboration with engineering and not live yet. Customer domains is on the public SAP roadmap for Q1 2027.
What I Learned
Governance design is vocabulary design. In an audited system, a wrong word is a wrong behavior, so I encoded the terms as rules that nobody, AI included, could drift from.
Don’t flatten options early. Keeping three directions live in one prototype let research, not opinion, pick the winner.
Measurement is the under-served question. How customers know governance is working stayed thin through two research rounds. Next time I’d make it a first-class design input from day one.
Status
Until this ships, I’m sharing the problem, my process and the decisions behind the design, but not the screens. To learn more, search for “Customer domains for the cockpit” in the SAP Road Map Explorer (roadmaps.sap.com).
