ROLE
Principal Designer, Design Systems
SKILLS
Component Architecture & API Design Interaction & State Design Accessibility & Keyboard Interaction Specification & Engineering Handoff Design Tokens & Theming Brand Integration
INTRODUCTION
Rebuilding a shared tree component
PGForsta's products each had their own tree: Report Structure in dashboards, the survey outline in authoring, File Manager, and Hierarchy Management. As the sole designer on PGForsta's design system, I set out to replace them with one tree component, styled in the new Forsta brand that followed the merger of Forsta and Press Ganey. I took it through a full spec, but I left PGForsta before it was pulled from the engineering backlog, so it never shipped.
UNDERSTANDING THE PROBLEM
Same component, different behaviors
I started by putting the four trees side by side and listing what each one had to do. Analysts used Report Structure to move between dashboard pages. Survey authors used the survey outline to select questions for bulk actions, and File Manager to organize the images and files their surveys used. Admins used Hierarchy Management to edit organizational structures nested many levels deep.
Under the surface, all four used the same basic row. What changes was how that row looked and behaved.
I also worked through the WAI-ARIA tree pattern to understand how a tree should behave for keyboard and screen-reader users, since none of the four had a documented keyboard model to build from.
THE CHALLENGE
Flexible enough, strict enough
One component had to handle four different jobs without turning into a pile of options, and stay consistent enough that users didn't have to relearn it in each product. A few tensions made that harder than it sounds:
Flexibility versus consistency. File Manager needed different actions per item, Hierarchy Management needed deep nesting, and the survey outline needed bulk selection. Every product-specific need was a pull toward a one-off.
Existing habits. Some trees relied on Ctrl- and Shift-click for mulit-select, and on right-click, double-click, and drag for editing. People knew those patterns, but keyboard and touch users couldn't reach them.
Detail without overload. Engineers needed every state and interaction defined, but a spec too dense to read gets skimmed and misbuilt.
THE APPROACH
Answering questions before they're asked
I build specs from discovery, not from my own assumptions. For the tree, that meant the audit of how each product used and styled the component, the gaps it exposed (selection that looked like hover, missing states, no keyboard model), and the WAI-ARIA tree pattern as an outside standard. Each finding became something the spec had to answer.
Most gaps between design and build come from things the design didn't say. So I annotate anything that could be read two ways, and I look at where questions and rework tend to come up, then close those gaps first.
What engineers get
Each part of the spec answers a question an engineer would otherwise have to ask:
Deliverable | Answers |
|---|---|
Anatomy | What are the parts, which are required, and how does each one behave? |
Sizing & Spacing | How big is each part, how is it spaced, and what changes with density and screen size? |
Component API | What does it take in, what does it emit, and which settings belong to the component versus its parts? |
States | What does every state and combination look like, and which tokens and contrast ratios are behind them? |
Accessibility & Interaction | How does it work for everyone, whatever input or assistive tech they use? |
Design Tokens | Where does each value come from, and how do modes like density and theme change it? |
Key Decisions
One row, with slots turned on as needed.
I designed one tree item with seven slots: drag handle, checkbox, indent, expand toggle, icon, label, and overflow menu. Each slot is 24px, and each use case turns on only the slot it needs. The checkbox sits before the indent, so checkboxes stay in one column at every level.
The tree sets the ceiling
Behavior that should be consistent lives on the tree: selection mode, checkboxes, cascade, density, emphasis, and whether it's editable. Items control their own data and can restrict those settings, but never extend them. A root folder can be locked in an editable tree, and Upload can appear only on folders, but no single row can switch selection modes.
The in-between states
Combinations cause the most bugs, so they're specified alongside the basics. A selected row with keyboard focus gets a white inner ring, because an accent ring disappears against the accent fill. Hover and selected never share a style, which was one of the old component's biggest problems.
THE RESULTS
A complete spec, ready to build
The tree didn't ship, so there's no adoption or usage data for it. What it produced was a complete spec, ready for development: anatomy, sizing, a component API, every state, accessibility and interaction behavior, and design tokens.
The same approach did ship elsewhere in the system. The component I specified this way helped grow adoption from a single pilot product to five product teams, with design iteration about 5x faster and component implementation about 10x faster.
BEYOND THE BUILD
What I'd validate next
The biggest thing I learned is that a thorough spec is a starting point, not proof. Several parts of this one were never tested, and if I picked it back up, these would come next:
Validate with each product's users. Survey authors and Hierarchy Management users especially, before engineering builds on my assumptions.
Test with screen readers. The ARIA mapping follows the pattern, but announcements may vary across NVDA, JAWS, and VoiceOver, and only testing shows what people actually hear.
Search within the tree. Survey and Hierarchy Management both had search, and the spec doesn't yet cover how results, highlighting, and auto-expanding parents should work.
Large trees. Lazy loading is accounted for, but long trees likely need virtualization, which changes how focus and scrolling behave.
Cascade edge cases. What a checked parent means when some of its children are disabled or locked still needs a rule.
Migration. Moving four existing trees onto one component needs a plan per product, not just a component.
Preparing for AI tools. Design and coding assistants increasingly build UI straight from a design system. The spec is already structured as props, states, and tokens, but publishing it as machine-readable documentation and linking the Figma component to code, with something like Code Connect, would let those tools use the tree correctly instead of guessing.