The Data Catalog is where it all begins.
Ataccama ONE is an enterprise data governance platform. The Data Catalog is where data stewards, analysts, and consultants discover what data the organization owns. Before they can govern data, they need to import its metadata, schema, types, structure, from a connected database.
It's a high-frequency action performed by the same handful of people, over and over. It was also one of the most fragmented flows in the product.
Six clicks. One source at a time. Zero visibility.
To import metadata, a user had to leave the catalog, navigate to a source, open its Connections tab, expand a tree, select tables, and click Import. The flow was technically possible, but forced users into mental bookkeeping the product should have done for them.
From source-by-source to one canonical entry point.
Six steps to a single import
- Leave the Data Catalog
- Navigate to Sources
- Open a specific source
- Open Connections tab
- Expand a connection
- Select tables, click Import
One modal, every source
"Import asset" button opens a modal rooted at Source level. One session can span the entire catalog.
A single modal triggered from the catalog listing.
Rooted at Source level so one session can span multiple sources. Lazy-loaded children with indeterminate-state checkboxes for partial selection. A real-language selection summary that counts only the leaves that actually import.
Each decision rebuilt an assumption the old flow was making.
Tree starts at Source, not Connection
Rooting the tree at the system level meant a single import session could span the entire catalog.
Lazy-loaded children with indeterminate checkboxes
Enterprise tenants have thousands of tables. The tree fetches children only on expand, with a spinner-in-chevron loading state.
Selection summary in real language
"X tables from Y connections from Z sources", counts only the leaves that actually import, qualified by their parents.
Always-visible primary action
SplitButton + Cancel always visible. The modal exists for importing, the primary action shouldn't hide.
Every "small" UI decision was implicitly making a load-bearing assumption about how customers use the product.
From the design crit retrospective
Four passes, and a crit session that reshaped half the design.
Current-state mapping
Walked through the existing flow as a user. Documented the six-click sequence. Identified that the existing ConnectionBrowseTree could be the foundation, but its root level was wrong for the new flow.
First draft modal
Designed in Figma with Flamingo primitives. Built five states: Initial, Browsing, Selected, Show Selected Only, Loading.
Cross-functional design crit
Five reviewers across design and frontend. Ten pieces of feedback. Selection-counter language, toolbar placement, modal density, and pagination model all changed.
Final design and handoff
Refined typography, density, paginator scope. Wrote a full handoff doc enumerating every element, state, interaction, components used, and open engineering questions.
Three principles I took into the next project.
Clarify the unit of measurement
"Items" is ambiguous when one item could be one connection or one table, and they don't equal each other.
Progressive disclosure + pagination = complexity explosion
Pick one. Combining them creates an interaction model engineers can't ship and users can't predict.
For bulk actions, ask: what's the worst case?
This modal can spawn thousands of background jobs. Safeguards belong in the UI, not bolted on after.
