Hierarchy Builder
Role
Lead UX Designer – Research, Information Architecture,
UI Design, Prototyping
Timeline
9 months
Background
Enterprise customers managed hierarchies across multiple tools. Data from D&B and local systems did not live in one view.
The Workbench had patterns for tables and lists, but no clear way to see deep trees, compare sources, or act in place. Teams spent time exporting, stitching, and checking by hand. Errors slipped through.
Problem Statement
There was no single, scannable view of a hierarchy. Missing children and orphan accounts were hard to spot. Users could not re-parent, add orphans, or purchase missing records without leaving context. Large trees caused performance issues and made orientation difficult. Any solution also had to stay consistent with Workbench patterns so users did not relearn basics.
Goals
Create a side-by-side view of D&B vs. local hierarchies. Make gaps obvious without alarmist colors. Keep users oriented at scale. Enable fixes in place: purchase missing accounts, add orphans, re-parent, and clone trees. Reuse Workbench filters, search, and tokens for familiarity. Ship a view-only beta to validate layout and performance, then expand to full edit.
Process
Setup
Input was the PRD and direct asks from the CEO and PM.
I began by analyzing the existing production applications, customer support case records, and recorded product-demonstration sessions. Then created guardrails:
Show the truth side-by-side.
Never hide what changed.
Keep the filter/search bar the same as other apps.
Reduce clicks for the common path: find → compare → fix → confirm.
Folder-like style felt plain at first.
But it matched Workbench patterns.
Rows lined up.
Indentation told depth.
Icons carried meaning.
Virtualized lists worked well.
Tree layout
To design the hierarchy view, two layout paths were explored: a topology-style layout and a folder-style layout.
Topology style looked alive.
Lines curved. Nodes floated.
It impressed in small demos.
It failed with real data.
Long names overlapped.
Depth and breadth were hard to scan.
Keyboard nav and a11y were messy.
Early beta
The beta shipped with read-only trees. The goal was to validate the layout, the compare model, and the ability to handle large data loads. Search, filtering, and deep-hierarchy scrolling were supported, but editing was not yet available.
Final Design
Compare Model
Layout
Left: D&B
Middle: Local Hierarchy 1
Right: Local Hierarchy 2 (optional)
Details rail: fixed on the far right
Counts: anchored at the bottom of each panel
Rationale
The layout matches the workflow. One local tree is set as the focus. The D&B panel compares against this focused local tree only. An optional second local tree can be shown for context, but D&B “missing” indicators and counts always reference the focused local tree. Fixed rails maintain orientation during scroll. Panel-bottom totals ground each column.
Edit Feature
The beta launched in read-only mode to establish reliability. Editing came next, added in a way that preserved the flow users already trusted.
Purchase missing accounts
Missing nodes can be selected and added to a cart, which shows a running count. At checkout, the request is submitted to D&B. This batching approach follows familiar cart patterns, making data purchase easy to understand.
Add orphan accounts
Clone trees
Entire local hierarchies can be copied for planning variants. Dialog shows source, new name, and optional filters.
Orphan records without a parent appear in a tray at the bottom of each local tree. Users can review them in one place, choose the right spot, and place them without losing focus. The tray makes placement clear before anything is committed.
Re-parent accounts
Rows can be dragged under a new parent, with ghost lines and valid-drop icons guiding the move. Data rules show inline before the drop, reducing context switches and confirming the target visually.
Hardest problems and solutions
Deep trees and performance
Problem: Large hierarchies were slow to load and hard to scan.
Solution: Row virtualization, lazy child fetch, “Show more” anchors every ~10 nodes, and sticky headers kept performance fast while maintaining context.
Unknown vs truly missing
Problem: Users could not distinguish between nodes hidden by filters and nodes missing from the data.
Solution: Panel bottoms showed “Available for purchase” in D&B and “Count” in Local, keeping totals accurate and transparent.
Orientation across panels
Problem: users lost place when comparing multiple trees.
Solution: persistent details rail for selected node, panel-bottom totals, and consistent scroll rhythm across columns.
Ambiguity vs error
Problem: Using red to mark uncertain nodes created blame and noise, making users think errors existed where they didn’t.
Solution: Neutral circles with plain labels replaced warning colors, reducing confusion and tension.
Context while editing
Problem: Moving nodes in large trees was stressful and error-prone.
Solution: Hover previews, ghost lines, and a “Back to hierarchy” escape in the details panel reduced risk and gave users confidence while editing.
Outcome
Users can view the full corporate tree and quickly identify gaps. They can resolve issues directly within the interface, which reduced support tickets. Onboarding also became faster since the controls align with familiar Workbench patterns.