Enterprise UX · Product redesign · 2024
Redesigning a low-code data intelligence platform
An enterprise data platform whose only way in was a force graph, redesigned in two phases: first for the technical users who built on it, then as a governed product business users could operate.
Jump to the redesign
Drag to compare. Same data, same moment, before and after the redesign.
Time on task
Less time on CRUD and browsing across data constructs
Adoption
Engineering teams adopted the platform
Reach
Developers building on it
01Context
The platform and my role
The platform let internal teams bring fragmented enterprise data into one shared layer, model it, and act on it. The capability was strong. The experience was almost unusable.
Who did what
I owned
Design manager
How data moves through the platform
02Problem
Three ways the old tool failed
The old tool exposed the underlying data model almost directly. Every task started from the graph.
01
The graph was the only way in
Finding a dataset meant navigating dense clusters, with the same metadata repeated on every node.
02
Create and edit floated over the data
Forms opened as pop-ups on top of the graph, with no shared structure across constructs.
03
Actions had no fixed place
View, link, edit, and delete orbited each node, and nothing told the user where they were in the data universe.
03Research
What I studied, and what it changed
I grounded the redesign in desk research across modern data platforms: four architecture paradigms, eleven technologies, seven vendor deep-dives, and three product walkthroughs. Each block ends with the design decision it produced.
Research 1 of 5
Architecture landscape
SaaS
Self-service
Did
Mapped five data architectures, split vendors into SaaS and self-service, and studied two ownership lenses.
Found
The market was converging on four ideas. Self-service, not managed SaaS, fit a low-code developer without a platform team.
Changed
An object-centric, governed workspace, with ownership and cataloging as tabs on every object.
Research 2 of 5
Benchmarking
Did
Studied 11 technologies, deep-dived 7 vendors, walked 3 products end to end, and condensed the Databricks 16-step playbook.
Found
Every playbook ran the same sequence: define, catalog, configure, govern, monitor.
Changed
That sequence became the operating model: browse, select, inspect, act, govern.
Research 3 of 5
Personas
Of practitioner time goes to cleaning and organising data.
Source: CrowdFlower data science report, via Forbes.
Did
Modelled eight practitioner roles by tooling and technical depth.
Found
Two practical groups, and about 60% of practitioner time went to cleaning data.
Changed
Two served groups, one per phase, centred on schema and live samples.
Research 4 of 5
Card sort
Did
Organised about seventy data-domain terms into capability areas through an open card sort.
Found
Nine areas. Management, governance, and security had no home in the old interface.
Changed
Cataloging, schema, connections, and access became first-class parts of every object. Governance became the core of Phase 2.
Research 5 of 5
Operating model
12 roles accountable across the steps
Did
Mapped 12 roles against a 16-step implementation process.
Found
Every step had an accountable role.
Changed
Work was modelled around objects, with the responsible people visible on them.
04Operating model
Five verbs, five regions
Every task, on every construct, follows the same five steps. Each step got a fixed region in the workspace.
Govern lives on the object itself, as owners, permissions, and policies. Phase 2 built it out.
Phase 1
Usability for technical users
The first round redesigned interaction and UX for low-code developers. The platform's capability stayed. The way into it changed.
Find, inspect, create, and edit any data construct without navigating the graph.
05Views
The graph became one view of five
The graph stayed, as one of five views reading the same data. I executed most of the graph visualisation design.
Graph, map, and table read the same object. The floating table lets a user check rows without leaving the graph.
06Object detail
One page for every object
Everything a user needs to judge a data object sits on one page, organised under tabs.
07CRUD pattern
One pattern across seven constructs
Create, inspect, edit, and manage work the same way on every construct. This pattern is where the 70% reduction in CRUD and browsing time came from.
| Construct | Pattern coverage |
|---|---|
| Ingest Jobs | Create, edit, and view for data intake |
| Entity Models | Detail page with schema, privileges, connections, and data sample |
| Dynamic Contexts | Context definition and relationship visibility |
| Analytics Queries | Query detail and creation, tied to data context |
| Target Groups | Group and cohort management, tied to context and engagement |
| Experience Visualizations | Visualisations saved as reusable enrichments over data |
| Omni-channel Engagements | Channel selection and action configuration |
Phase 2
Productising the platform
The second round turned the internal tool into a product. It added governance and access control, accessibility, and flows for business users alongside developers.
Let business users find and trust data, and let owners control who uses it, without leaving the workspace.
08Governance
Access control lives on the object
Permissions, access requests, and roles are handled where the data is, not in a separate console.
Permissions
Access requests
Role matrix
09Business users
A path for business users
Business users needed to answer two questions without navigating like a database administrator: what data do we have, and can I use it?
10Outcome
What shipped
Most of the experience shipped over 4 to 5 months and became the internal tool teams use to build low-code apps. Some items stayed in the engineering backlog.
One pattern, seven constructs
Create, inspect, edit, and govern work the same way everywhere.
The graph as a view
Hierarchy, tabs, tables, and maps became the way in.
Governance in the workflow
Access, requests, and roles are handled on the object.