Platform scale
Highlights
Six Grid implementations consolidated into one, reducing implementation count by 83%
Validated across Tickets, Assets, Parts, and Rooms
Shared behavior separated from product-specific logic
Legacy implementations retired from design and code
One trackable system for ongoing iteration
The problem
Incident IQ supported data-heavy operational workflows across Tickets, Assets, Parts, Rooms, and other product modules. Grids were the primary working surface in each context, and separate teams had implemented them around their immediate needs.
The overlap was clear: columns, rows, search, filtering, sorting, selection, and pagination. So was the variation: data schema, content density, permissions, actions, status, and workflow conditions.
By the time I began the project, six implementations were carrying similar behavior in different ways. The same foundational interaction model had to be designed, implemented, tested, and maintained multiple times.
The question was not whether to create a shared component. It was what the shared system should own and what each product needed to control.
My role
I led the work as Director of UX while remaining the hands-on systems designer. I audited the existing implementations, defined the architecture and component boundaries, designed the shared states and configuration model, and worked with Product and Engineering to align the Figma system with the implementation.
I also defined the accessibility requirements and the decision framework used to evaluate new requests.
Finding the shared system
Two implementations made the problem easy to see. Location Types and Event Types used the same underlying grid structure, but their schemas, content, role visibility, and workflow behavior were different.
The same structure supported different schemas, role visibility, and row content.
I expanded that comparison across the existing grids, grouped the recurring and variable requirements, and organized the findings into three layers:
A shared foundation for structure and interaction
A configurable layer for product data and workflow behavior
System requirements spanning accessibility, engineering, governance, and adoption
The audit also became the alignment tool. Instead of debating whether every Grid was unique, I could show Product and Engineering which behaviors repeated and which requirements came from product logic.
The audit led to a shared Grid foundation for layout, row behavior, selection, sorting, and pagination, with product-level configuration for columns, cell content, filters, actions, and empty states.
Choosing composition over a monolith
I evaluated three directions:
Continue building specialized grids. This gave each product immediate control but preserved duplicate implementation and inconsistent behavior.
Put every requirement into one configurable component. This centralized the system but would create an expanding set of props, exceptions, and test cases.
Build a composable architecture. Shared behavior could live in the foundation while product-specific content and workflow logic remained replaceable.
I led the team toward the composable model.
I defined the parent Grid to own cross-product behavior. Rows handled interaction and navigation. Cells carried content and workflow-specific meaning. That separation allowed the system to support legitimate differences without rebuilding the Grid for every product.
Defining the component boundaries
The architecture separated responsibility by layer:
Grid: layout, sorting, filtering, pagination, selection, bulk actions, and shared behavior
Row: hover and selected states, row actions, permissions, expansion, and navigation
Cells: reusable detail, status, header, filter, and action patterns
This gave Product, Design, and Engineering the same model for deciding where a requirement belonged.
Testing the architecture across products
I tested the same architecture against Ticket, Asset, Part, and Room workflows. Each context used the shared Grid behavior while defining its own schema, columns, cell content, and available actions.
The type property selected the product context. Shared properties such as filters and selected controlled system behavior. An empty result remained a state of the Grid rather than another product context.
Prop
Type
Default
Figma status
type
“tickets” | “parts” | “assets” | “rooms”
tickets
available
filters
“true” | “false”
true
available
selected
“true” | “false”
false
available
One shared foundation supporting four different product contexts.
Keeping configuration explicit
The technical challenge was only half of the problem. A component capable of supporting every module could still fail if designers could not understand how to configure it or if the Figma model drifted from the engineering model.
I kept the parent component’s configuration surface deliberately limited. Teams could select the product context and control shared behaviors without creating another Grid implementation. I worked with Engineering to keep the component boundaries and configuration logic aligned between Figma and code.
More specialized content stayed inside composed rows, cells, and actions instead of becoming business logic in the parent component.
Filters enabled
Filters disabled
Filters enabled
Empty state
Stress-testing dense ticket content
Tickets were the most demanding context because a single row could contain dense content and multiple workflow conditions.
I used the Ticket Details Matrix to compare combinations of primary information, supporting metadata, status, alerts, and workflow conditions against one row architecture. Three craft decisions were central:
Information hierarchy: The ticket title remained the scanning anchor. The ID, update time, and supporting metadata occupied a quieter secondary level, while overdue and other exceptional conditions received a stronger signal.
Selection: A selected row gained a clear state and revealed bulk actions without changing the underlying column structure.
Empty results: The row region changed to an empty state while the surrounding Grid context remained stable.
Condition
Default State
Hover / Selected
Nested Content
Keyboard Focus
Keyboard Focus
Keyboard Focus
Keyboard Focus
The resulting row model supported default, hover, and selected states consistently. Product-specific conditions, such as a resolved ticket, remained part of the Ticket implementation rather than becoming universal Grid behavior.
Building accessibility into the architecture
I defined accessibility as system behavior, not a final review step.
I specified keyboard navigation, focus management, sort announcements, selection announcements, screen-reader compatibility, and consistent interaction states. Engineering could then implement those behaviors in the shared foundation rather than rebuilding them from product to product.
Connecting component intent to implementation
I connected Grid states to the broader design system’s semantic-variable layer. Primitive values mapped to semantic roles and component states so Design and Engineering could work from shared intent instead of selecting raw values independently.
The semantic layer made state behavior easier to inspect, document, implement, and maintain across Figma and production code.
Semantic tokens connected interaction states, status, hierarchy, and structure to consistent visual behavior.
Establishing a decision model
A shared component would not prevent teams from introducing new variants. We also needed a decision process for new requirements.
Every request followed the same sequence:
Reuse an existing pattern
Extend an existing pattern
Create something new only when the workflow introduced genuinely different behavior
The model gave Product and Engineering a shared way to distinguish a real product requirement from another duplicate solution.
Production use
Shared sorting, filtering, selection, bulk actions, row content, status, assignment, and pagination working within one production workflow.
The reusable architecture reduced duplicate solutions and established a more consistent foundation for data-heavy workflows. It also became a model for evaluating future component requests across the design system.
Outcomes
The project produced five direct outcomes:
Six independent implementations were consolidated into one shared Grid system, eliminating five separate implementations—an 83% reduction in implementation count.
The shared architecture was validated across four distinct product contexts: Tickets, Assets, Parts, and Rooms.
Legacy implementations were retired from design and code.
The component could be tracked as one system across the codebase, making adoption and divergence visible.
When a team detached or extended part of the system, that evidence became an input for improving the shared component instead of allowing another implementation to spread unnoticed.
The Grid also established explicit component, interaction, accessibility, and implementation boundaries, along with a shared decision model for reuse, extension, and new component creation.
Reflection
The implementations looked different at the surface, but the audit revealed that most of the variation lived in product content and workflow rules. The underlying structure and interaction model were largely shared.
The central design decision was therefore the boundary between shared infrastructure and product logic. That became a repeatable way to evaluate future cross-product components: identify the stable behavior first, isolate the variable product logic, and design the interface between them.
