Highlights
31% faster UX workflow speed
35% reduction in rework
20% increase in component reuse in 9 months
27% fewer late-cycle fixes
WCAG 2.1 AA accessibility foundation
$360K to $615K estimated annual operational value
Overview
IncidentIQ is a K–12 workflow and service management platform used by districts to manage IT help desks, assets, facilities, HR workflows, and other operational systems.
When I joined, the product had grown across six modules. Each module had its own patterns, its own workflow needs, and its own delivery pressure. Designers were embedded across engineering pods, which helped teams move quickly, but it also created fragmentation across the product.
The design system existed, but it was not operating as product infrastructure yet.
It needed structure.
It needed governance.
It needed accessibility standards.
It needed engineering alignment.
It needed adoption tracking.
Leadership needed a clearer way to see the value.
The goal was not to make a cleaner component library.
The goal was to build a system designers could use, engineers could build from, QA could validate, and leadership could measure.
The problem
The core issue was fragmentation.
Across six product modules, similar problems were being solved in different ways. Navigation patterns varied. Form patterns varied. Tables, filters, actions, empty states, and workflow screens were not always consistent.
That inconsistency created drag.
Designers had to make more decisions than they should have. Engineers had to interpret patterns more often than they should have. QA had fewer shared standards to validate against. Leadership could see the work happening, but not always the measurable impact.
The product was active, live, and scaling. So the system had to improve while delivery kept moving.
What we were seeing
Six modules with different UI patterns.
Designers embedded across engineering pods.
A fragmented system across the product.
Inconsistent experiences between modules.
Limited visibility into component reuse.
Rework happening across teams.
Accessibility handled too late in the process.
No clear way to show design system ROI to leadership.
Resources were limited, so the system had to earn investment in phases.
Strategic Approach
I reframed the design system as delivery infrastructure.
That meant treating the design system as more than a library of components. It needed to function like a product with users, priorities, a roadmap, governance, adoption, and measurable outcomes.
The users of the system were designers, engineers, QA, product managers, and indirectly, every district employee using the product.
I built the strategy around three phases.
Phase 1, foundations
Phase 1 created the base system.
This included core components, layout rules, typography, spacing, color foundations, naming conventions, and early adoption tracking.
The goal was to create a usable foundation before expanding into more complex product patterns.
Key work included:
Core component library
Component naming conventions
Component taxonomy
Reusable foundation styles
Baseline adoption tracking
Documentation structure
Initial accessibility standards
Phase 2, scale and accessibility
Phase 2 focused on deeper system maturity.
This included navigation, forms, shared patterns, accessibility standards, documentation, and stronger engineering integration.
The system needed to support more than visual consistency. It had to support implementation, accessibility, and delivery.
Key work included:
Advanced component patterns
Form systems
Navigation patterns
Accessibility requirements
WCAG 2.1 AA alignment
Engineering documentation
Component ownership
Prioritized Phase 2 backlog
Effort sizing and ownership mapping
Phase 3, workflow patterns
Phase 3 moved the system beyond components.
This phase focused on reusable workflow structures across modules. The goal was to reduce repeated design decisions and create scalable patterns for common product flows.
Key work included:
Workflow templates
List-detail patterns
Admin configuration patterns
Reusable page structures
Cross-module pattern alignment
Adoption metrics
Delivery quality tracking
UX/QA validation workflows
Component architecture
The component layer focused on reusable UI and interaction patterns.
I organized the system around components that carried the most product and delivery weight.
Complex components
Admin configuration screens
Each component needed usage rules, variants, states, accessibility guidance, and enough documentation for teams to use it consistently.
The important part was not only building the components.
How the system was built
The system was built around four connected layers:
Foundations
Components
Documentation
Measurement
Each layer had a purpose:
Foundations created consistency.
Components created reusable UI.
Documentation made the system usable.
Metrics showed whether it was working.
Foundations
The foundation layer covered the basic rules teams needed before components could scale.
This included color, typography, spacing, layout, icons, status colors, and responsive behavior.
The work was not only about creating styles. It was about creating rules that could survive across modules and teams.
Foundations
Components
Documentation
Measurement
Each layer had a purpose:
Foundations created consistency.
Components created reusable UI.
Documentation made the system usable.
Metrics showed whether it was working.
Color
Color needed to support product hierarchy, status, feedback, and accessibility.
Accessibility feedback from Level Access made this more specific. Color pairs needed to be documented based on whether they met contrast requirements, including 4.5:1 for text and 3:1 for large text, graphical objects, and interface components. The review also called out the need to test color use across different application backgrounds, including images and gradients.
That feedback shaped how color guidance needed to work inside the system.
The system needed to answer:
Which color pairs are safe?
Which colors support text?
Which colors support status?
Which colors work on different backgrounds?
Where do we need stronger contrast?
Where should designers avoid certain combinations?
Typography
Typography needed to support dense operational workflows.
The system had to account for hierarchy, readability, line spacing, and accessibility scaling.
Level Access specifically recommended pressure testing designs at 200% text size and creating tokens or guidance for 200% text behavior, including line spacing concerns.
That moved typography from a visual choice into a system rule.
Breakpoints
Responsive behavior mattered because dense SaaS workflows still needed to hold up under zoom and constrained viewport conditions.
Level Access recommended testing foundational and complex designs at 320px width to represent a 1280px desktop experience at 400% zoom.
That became an important accessibility and responsive design consideration.
The system needed to support:
Desktop workflows
Constrained layouts
Zoom behavior
Responsive collapse rules
Readable forms and tables
Interaction clarity at smaller widths
Naming and taxonomy
One of the first system problems was findability.
If designers could not find the right component, they would make a new one. If engineers could not understand the intent, they would rebuild it. If similar components had unclear names, the system would fragment again.
I standardized naming conventions and taxonomy so the system could be searched, understood, and adopted across teams.
The naming work focused on:
Clear component names
Consistent grouping
Predictable variant naming
Reusable pattern categories
Shared language across design and engineering
Documentation that explained when to use each pattern
This made the system easier to navigate and easier to govern.
State and variant model
States were treated as part of the system, not one-off screen decisions.
That included:
This mattered because a component that only works in its default state is not a real system component.
Operational software lives in edge cases:
Missing data
Lost permissions
Error submission
Loading and latency states
Dense, high-cognitive-load workflows
Clear recovery paths
The system needed to support those realities.
Accessibility as system infrastructure
IncidentIQ served K–12 districts, which made accessibility especially important. Accessibility was not only a usability issue. It was tied to district readiness, customer retention, legal risk, and long-term market opportunity.
Accessibility became one of the most important parts of the system.
Level Access partnership
I partnered with Level Access to audit accessibility issues and translate findings into practical system updates.
The feedback covered foundations, components, interaction states, screen reader behavior, keyboard behavior, contrast, zoom behavior, and form requirements.
Some of the strongest feedback areas included:
Documenting contrast-safe color pairs.
Testing text at 200%.
Testing complex layouts at 320px width for 400% zoom.
Creating alt text guidance for icons.
Designing focus states for all interactive elements.
Avoiding placeholder-only fields.
Making sure error states include text.
Defining keyboard and screen reader behavior for drawers, modals, date pickers, selects, switches, and timelines.
Adding visible labels where needed.
Ensuring progress indicators had text equivalents.
This feedback was valuable because it was specific.
It showed where vague accessibility notes were not enough.
Component-level accessibility rules
Accessibility requirements were brought into the system through component guidance.
Examples:
Interactive icons needed focus, hover, inactive, and selected states.
Buttons needed stronger hover and focus treatment.
Split buttons needed keyboard and screen reader behavior.
Checkboxes and radios needed visible labels.
Search fields needed visible labels and a separate action.
Select triggers needed error text, target-size review, and keyboard guidance.
Switches needed visible labels and clear on/off states.
Text fields needed contrast checks and text-based error messages.
Drawers and modals needed focus management and screen reader context.
Progress bars needed sufficient contrast and text values.
This became part of how components were defined, reviewed, and documented.
ADA Title II impact assessment
I also created an ADA Title II Compliance Impact Assessment.
The goal was to connect accessibility to customer and business risk.
The assessment looked at:
Large district compliance deadlines
Mid-sized district compliance deadlines
Portfolio exposure
Potential customer risk
Contract risk
Legal and reputational risk
Market expansion opportunity
Sales awareness
Customer readiness
This helped leadership see accessibility as more than remediation:
It was a customer retention issue.
A legal risk issue.
A market opportunity.
And a design system priority.
Documentation model
Documentation became the handoff layer between design, engineering, QA, and product.
The system documentation included:
Component anatomy
Usage rules
Variants
States
Accessibility notes
Do and don’t examples
Implementation guidance
Contribution rules
Design validation criteria
Definition of Ready and Definition of Done support
The goal was to make the system usable without requiring every decision to go through me.
Documentation needed to answer:
When should this component be used?
When should it not be used?
What states are required?
What accessibility rules apply?
What does engineering need to know?
What should QA validate?
What counts as an exception?
This helped reduce ambiguity and made system decisions easier to repeat.
Governance and adoption
The system needed a governance model because the product was moving: new work continued, teams still had deadlines, designers needed flexibility, and engineers needed practical implementation paths. Governance couldn’t become a blocker—it had to make the right path easier.
The governance work included:
Contribution rules
Component ownership
Prioritization standards
Documentation standards
Design system backlog refinement
Phase 2 component ownership
Effort values
Adoption tracking
Engineering alignment
Leadership visibility
The system needed clear answers for common questions:
When do we use an existing pattern?
When do we extend a component?
When do we create something new?
Who reviews the change?
Who owns the decision?
How does the update get documented?
How do we know if teams adopt it?
Adoption model
Adoption was measured by looking at where teams used the system and where they worked around it.
When a workaround repeated, I treated it as a system gap.
That could mean:
A missing pattern.
A component that was too rigid.
Unclear documentation.
A state that was not defined.
A product workflow that had moved faster than the system.
An implementation path that needed engineering input.
The fix was not to police teams harder.
The fix was to improve the system.
Engineering alignment
Design system work was embedded in engineering workflows, with UX involved in tactical meetings, sprint planning, dependency discussions, and development cycles. This mattered because design system decisions affected delivery: if a component wasn’t ready, engineers needed visibility; if a pattern changed, QA needed to validate it; if accessibility requirements shifted, product teams needed to plan; and if rework continued, leadership needed to understand why. I worked to move UX and design system conversations earlier in the process, which included:
UX representation in engineering tactical meetings
Design dependencies surfaced before development
Design system updates prioritized in development cycles
UX backlog refinement
Design validation before handoff
Definition of Ready and Definition of Done checklists
UX/QA validation checkpoints
Reusable documentation in Confluence and Notion
This helped connect design system work to delivery planning.
UX and QA validation
The system needed a quality layer.
I created a UX/QA integration process to catch design misalignment before and during development.
This included:
Design validation checklists
UX/QA tracking metrics
Acceptance criteria before development
Design-related defect tracking
Validation checkpoints in QA
Definition of Ready and Definition of Done support
Accessibility review expectations
The goal was to reduce late-stage churn.
Instead of finding system gaps after code was written, UX and QA had clearer standards to validate against earlier.
This helped reduce design-related defects and improved release confidence.
Metrics framework
This was the biggest differentiator.
The design system became measurable.
I built UX metrics dashboards and scorecards to track adoption, efficiency, backlog impact, component reuse, workflow speed, rework, and delivery quality.
The goal was to move UX from anecdotal value to measurable value.
Metrics tracked
Component reuse
Design system adoption
Rework
Workflow speed
Cycle time
Backlog movement
Ticket completion rates
Delivery quality
Late-cycle fixes
UX workload
Team contribution rates
Accessibility readiness
UX/QA alignment
Leadership response and approval timing
Why it mattered
Before the metrics framework, UX value was hard to explain.
The team was producing work, but leadership did not have a clear view of how that work improved delivery.
The scorecard changed that.
It gave leadership a way to see:
Where design reduced rework
Where component reuse improved speed
Where UX was creating delivery predictability
Where accessibility work reduced risk
Where design system investment was paying off
Metrics turned the system into a business conversation
DesignOps and operating structure
The design system sat inside a broader operating model.
I built and improved processes around:
UX intake
Backlog refinement
Sprint alignment
Quarterly roadmap planning
UX/PM research syncs
Research repositories
Persona documentation
Leadership reporting
Team performance scorecards
UX career pathing
Mentorship
Meeting cadences
Design validation workflows
This mattered because a design system does not succeed in isolation.
It needs the surrounding process to support it.
The operating structure helped teams understand:
What work mattered.
What needed prioritization.
What was blocked.
What needed engineering support.
What leadership needed to approve.
What impact UX was having.
This created more transparency and accountability across UX, product, and engineering.
Research as a system input
Research also fed into the design system.
I built a UX/PM Research Framework to standardize how research was planned, documented, and connected to product decisions.
That included:
Persona templates
Research methods
Research repositories
Usability findings
Product alignment sessions
Reusable documentation in Confluence and Figma
The goal was to make research reusable across teams.
This supported the design system because patterns needed to reflect real users and workflows, not only interface preferences.
In a platform with multiple user types and modules, reusable research helped teams make more consistent decisions.
“We moved from isolated outputs to a connected UX system. Brandon’s focus on predictive metrics helped us align faster and iterate smarter.”
Product Designer
Product Designer, Incident IQ
“We moved from isolated outputs to a connected UX system. Brandon’s focus on predictive metrics helped us align faster and iterate smarter.”
Product Designer
Product Designer, Incident IQ
“We moved from isolated outputs to a connected UX system. Brandon’s focus on predictive metrics helped us align faster and iterate smarter.”
Product Designer
Product Designer, Incident IQ
The Impact
The result was a design system that operated beyond visual consistency.
It created structure across modules.
It improved adoption.
It increased component reuse.
It reduced rework.
It made accessibility repeatable.
It brought UX into delivery conversations.
It gave leadership a way to measure design value.
Results
31% faster UX workflow speed
35% reduction in rework
20% increase in component reuse in 9 months
27% fewer late-cycle fixes
WCAG 2.1 AA accessibility foundation
$360K to $615K estimated annual operational value
The system gave product teams a shared structure.
The metrics made the value visible.
Together, they moved UX from a service function into delivery infrastructure.
Role
Director of UX, reporting to the VP of Engineering and CTO.
Led UX strategy, design systems, accessibility, and research operations across the platform.
Directed a cross-functional team spanning design, research, and content. Built the company’s first UX performance framework and DesignOps infrastructure.
Partnered with engineering and product leadership to align UX outcomes with delivery metrics, ensuring consistency, predictability, and measurable ROI.
