Symbiontra - An Enterprise Data Platform UX/UI Case Study

01Overview

Project overview: before, turning point, after

This is the story of how a company's data stopped being a maze only engineers could find their way through, and became something every team could find, trust and use on its own.

Before

Finding the right data meant asking around

Data was spread across teams and tools. Finding a dataset, checking whether it could be trusted, or seeing where a number came from meant filing a ticket and waiting for an engineer.

The turning point

Data needed a shop window, not a warehouse

The data existed. What was missing was a way to see it as something ready to use, with an owner, a label and a history.

After

One place to find, understand and use data

Symbiontra puts every data product in a searchable catalog, shows where it comes from and who relies on it, and lets anyone ask questions in SQL or plain English.

My design process

02Context

What is a Data Mesh?

Big companies have data everywhere: sales, supply, operations, finance. Traditionally one central data team looked after all of it. A Data Mesh flips that: each team looks after its own data and shares it with the rest of the company, like a product on a shelf.

Think of a Data Mesh as a farmers' market instead of one big supermarket. Each stall grows and sells its own produce, with a label saying who made it, what's in it and how fresh it is. Symbiontra is the market itself: the stalls, the signs and the rules everyone follows.

Core principles

Domain ownership

The team that creates the data looks after it, not a distant central team.

Data as a product

Every dataset comes with an owner, a version, a description and a quality score, like the label on a jar.

Self-serve platform

Teams can publish and use data on their own, without being infrastructure experts.

Federated governance

Shared rules keep everyone's data trustworthy, even though no single team owns it all.

Key terms

Data product: A dataset packaged for others to use, with an owner, a version and a description.
Domain: A business area, like Sales or Supply, that owns its own data.
Lineage: The family tree of a number: where it came from, and what depends on it.
Upstream / downstream: The sources a dataset is built from, and the reports and teams that rely on it.
SQL: The language engineers use to ask a database questions.
DPaaS: Data-Products-as-a-Service: getting the data you need on demand, like streaming a film instead of ordering a disc.

03User Persona

Designing for the owner of a data product

Daniel owns a dozen data products for his company's subsurface team. He knows his data better than anyone, yet he still can't answer simple questions about it without help. Here's how one simple question played out.

One question, before Symbiontra ≈ 3 days

Mon 9am
An analyst in another team asks a question.
“Which version of your well data should I use for the monthly report?”
Mon 10am
Daniel checks the data catalog.
It lists the tables, but not which version is current or who else uses it.
Mon 11am
He opens an engineering ticket.
The lineage diagram on the wiki is months out of date, so only an engineer can say what feeds the dataset.
Wed 2pm
The engineer replies.
An upstream source changed last week, and nobody downstream was told.
Wed 4pm
The analyst's numbers turn out to be wrong.
Two reports already shared with the business have to be redone.
Thu 10am
Finally answered.
Three days, three people and one ticket for a single question.

An illustrative scenario, pieced together from the frustrations people described in research.

User personas

Three roles came up around every data product. Daniel owns it. Ana, a data engineer, builds the pipelines behind it. Kofi, a business analyst, uses it to make decisions.

Daniel Brooks

Data Product Owner
Energy data provider · subsurface domain

OwnerPublisher

I own this data, but I still need an engineer to tell me who uses it and what feeds it.

Products owned: 12
Consumers: Several domains
Releases: Monthly
SQL comfort: Reads, rarely writes

Goals

See every product's lineage in one view
Answer data questions without writing SQL
Know who consumes each product
Publish without an engineering ticket

Frustrations

Lineage diagrams are out of date the day they're drawn
Each view of the data lives in a different tool
Quality issues are reported by consumers, not caught early
Simple questions wait in the engineering queue

Responsibilities

Publish and version data products
Keep quality and documentation current
Understand upstream and downstream impact
Support consumers in other domains

Traits

Technical skillMedium

Need for controlHigh

Trust in AIMedium

Daniel is the primary persona; Ana and Kofi are secondary.

What this meant for design

Each person needed a different view of the same data product: technical depth for Ana, plain clarity for Kofi, and a sense of ownership for Daniel. One product, three lenses.

04The Problem

Distributed data, centralised bottlenecks

On paper, every team owned its data. In practice, almost everything still had to go through one central engineering team.

The data was spread out, but the keys to it were not. Every question, every new dataset and every fix still waited in the same engineering queue.

Challenge → business impact

The problemWhat it cost the business

Scattered tools and pipelinesDifferent teams built the same thing twice, and got different answers.

No shared rulesNobody was sure which data to trust, and compliance became a risk.

Everything through engineeringTeams waited in a queue just to publish or open their own data.

Hidden lineageWhen a source changed, reports further down broke without anyone noticing.

Tools built only for engineersBusiness users couldn't help themselves to data they owned.

Problem statement

How might we let every team find, publish, trust and use data products through one platform, without waiting on a central team?

05Research & Discovery

Following data from producer to consumer

I followed data products from the people who create them to the people who use them, looking for every point where someone had to stop and ask an engineer.

Understanding the domain

How a data product is created, published and retired

Where data comes from, and what depends on it

Which team owns what

Rules, quality and trust signals

How people search and ask questions

Where AI could take the load off

Stakeholder interviews

Data Product OwnersOwn the data

Data EngineersBuild pipelines

Analysts & ScientistsUse the data

Business UsersMake decisions

Governance TeamsSet the rules

Key questions I asked

Finding data3 questions

How do you find out which data already exists?
How do you decide whether a dataset is good enough to use?
Who do you ask when something looks wrong?

Tracing changes2 questions

If a source changes, how do you know what breaks?
How do you trace a number back to where it came from?

Publishing2 questions

What does it take to publish a new data product today?
Which steps need an engineer?

Rules and trust2 questions

How are quality and usage tracked across teams?
Who decides who can see what, and which version is current?

What we found

The same frustrations came up from every side of the data. Paraphrased from the interviews:

“I can't tell which datasets exist, or which version to trust.”

“Only the engineers know where this data really comes from.”

“Every new question means writing SQL, or asking someone who can.”

“To understand one dataset, I jump between several tools.”

“I only hear about quality problems when someone complains.”

“We can't publish anything without the central team.”

Key insight

The Data Mesh was a good idea about how teams should work, but nobody had built the screen for it. People needed one place where every data product could be found, understood, traced and questioned.

06Competitor Analysis

Plenty of data tools. No Data Mesh experience.

I looked at everything teams were already using to work with data. Each tool handled one step well, and none of them connected the steps around the idea of a data product.

Approach	Good at	What's missing	Verdict
Data catalogsDiscovery	Listing and describing datasets.	Exploring, querying or running them.	Partial
Central data teamTicket queue	Reliable expertise.	Speed. Every request waits in the same queue.	Bottleneck
SQL & notebook toolsExploration	Powerful questions, for people who can code.	Anything a business owner can use.	Narrow
Custom pipelines & scriptsDIY	Flexibility.	Documentation, stability, and visibility for the people using the data.	Fragile
SymbiontraThis project	The whole journey: find, explore, trace and query a data product in one place.	No split between business and engineering. Both use the same screens.	Opportunity

Opportunity

Put the data product, not the table or the pipeline, at the centre of the experience, and build every tool around it.

07Design Decisions

Why it works the way it does

Each big decision came straight from research. Here's what we noticed, what we could have done, and what we chose.

The catalog is the front door

We noticed: people don't think in databases and tables. They think “I need the sales forecast”. So everyone starts from a searchable catalog of data products, each card showing who publishes it, which version it is and how usable it is.

Instead ofA database and table browser

We choseProduct cards with trust signals

One product, many lenses

We noticed: understanding one dataset meant opening several tools. So every product gets a lens bar, like switching between map, satellite and traffic views of the same place. Structure, pipelines, data, history, lineage, stats and quality are all one click away.

Instead ofA separate tool for every task

We choseA lens bar on every product

Lineage as live columns

We noticed: lineage lived in engineers' heads and in diagrams that were out of date the day they were drawn. So where the data comes from, the product itself, and who uses it sit side by side, and the impact of a change is visible at a glance.

Instead ofStatic lineage diagrams

We choseAn interactive “where from, where to” view

SQL and AI next to the data

We noticed: every question meant writing SQL, or waiting for someone who could. So a query board and an AI chat sit right beside the data. Engineers write SQL, business users ask in plain English, and both work in the same place.

Instead ofA separate SQL editor

We choseQuery board + AI chat in a side panel

See the whole value chain

We noticed: nobody could see how products, teams and organisations connected across the company. So a network graph shows the whole chain, a bit like an airline route map, with product details in a side panel. Light and dark themes support both presentations and long analysis sessions.

Instead ofLists of products and domains

We choseA network graph of the data value chain

The hardest part

Engineers needed depth; business users needed clarity. The challenge was serving both on the same screens, without quietly building two separate products.

08The Solution

One platform for the data product lifecycle

Symbiontra gives every data product a home: a place where business and engineering teams alike can find it, understand it, trace it and question it.

The same question, with Symbiontra ≈ 10 minutes

9:00 am
The analyst needs the well data for the monthly report.
This time, he doesn't need to ask anyone.
9:02 am
He searches the catalog himself.
The product card shows the current version, who publishes it and how usable it is.
9:04 am
The lineage view flags last week's upstream change.
He sees it before it reaches his report, not after.
9:08 am
He asks the AI chat a follow-up in plain English.
Right beside the data, with no SQL needed.
9:10 am
The report is built on the right data.
Daniel never had to open a ticket.

Key features

01 · Discover

A catalog of trustworthy data products

Browse data products the way you'd browse an online shop. Every card shows who publishes it, which version it is and how usable it is. Open one to see its details, its metrics, and what it depends on.

Fixes“I can't tell which datasets exist, or which version to trust.”

02 · Explore

Every lens on one product

The Datagraph explorer shows a product's structure and fields. Split views put details side by side, and a table view shows how the values in each column are spread.

Fixes“To understand one dataset, I jump between several tools.”

03 · Trace

Lineage you can follow

Lineography lays out where each product's data comes from and who uses it. The network graph zooms out to show how everything connects across teams.

FixesReports breaking silently when a source changes

04 · Query

Ask in SQL or in plain language

A query board and an AI chat sit beside the data, so engineers can write SQL and business users can simply ask, in the same place.

Fixes“Every new question means writing SQL, or asking someone who can.”

Product screens

09Impact

What the design set out to change

Symbiontra was designed to change who can work with data, and how much they have to ask for help. These are the outcomes it was built around.

Data work anyone can follow

Complex, technical data work shown through visual, product-centred views that business users can understand.

Shared ground for business & engineering

Both groups find, trace and question the same data products in the same place, instead of passing tickets back and forth.

Rules that scale with shared ownership

Company-wide governance and transparency, while each team keeps ownership of its own data.

Remember Daniel? “I own this data, but I still need an engineer to tell me who uses it and what feeds it.” Symbiontra was designed so he never has to ask.

10Reflection

What this project taught me

Symbiontra gave a Data Mesh something it usually lacks: one shared place to work. Organising everything around the data product, and giving every product the same set of lenses, made complex data feel navigable for business and engineering teams alike.

Lesson 01

Pick one centre of gravity

Making the data product the main thing on screen simplified every other navigation decision.

Lesson 02

Depth without walls

Engineers kept all their detail; business users got friendlier views of the same data. Nobody needed a separate tool.

Lesson 03

Show relationships, don't list them

Lineage and network views answered “what depends on this?” faster than any list could.

Want to see more product design work?

View web app designs Get in touch

Helping every team find and trust company data, without waiting on engineers

The challenge

The solution