Raising the Product Design Quality Bar Across a Complex B2B Platform
Building a Product Design Quality Practice at Scale
I established a shared product-design quality practice across a complex payroll and HCM portfolio, combining critique, coaching, reusable standards, accessibility, and cross-functional quality checkpoints to help designers move faster without sacrificing usability or consistency.
Project Overview
Auris was developing a broad portfolio of interconnected payroll and HCM experiences across multiple teams, workflows, and user types. Designers were working at different levels of maturity, product teams had varied delivery practices, and quality was often evaluated late in the development cycle.
This created several risks:
Inconsistent interaction patterns across products
Design decisions made without a shared quality standard
Rework caused by late Product and Engineering alignment
Accessibility and edge cases being addressed inconsistently
Designers receiving tactical feedback without enough craft development
Delivery pressure favoring speed over experience coherence
The goal was not to add more process. It was to create a practical system for evaluating and improving design quality while preserving delivery velocity.
The challenge
As Director of Product Design, I led the development of the design-quality practice as a hands-on player-coach.
My responsibilities included:
Coaching and developing product designers
Reviewing interaction design, information architecture, workflows, and UI craft
Establishing critique and design-review practices
Defining quality standards and shared expectations
Aligning Product and Engineering around review points
Introducing accessibility and Design QA into delivery
Connecting recurring design issues to system-level improvements
Balancing immediate product needs with long-term experience consistency
My role + What I LED
Coaching and critique
I established recurring design critiques focused on the reasoning behind the work, not just surface-level feedback.
Designers were expected to explain:
The user problem being solved
The workflow and context
Evidence informing the design
Alternatives considered
Constraints and tradeoffs
Open questions and risks
How success would be evaluated
My role was not to redesign the work for the designer. I used questions, examples, and targeted feedback to strengthen their judgment and help them recognize quality independently.
Stage-based design reviews
I introduced review points at the moments when feedback was most useful:
Problem framing: Are we solving the right problem?
Workflow review: Does the experience support the real task?
Interaction review: Are behavior, states, and edge cases resolved?
Visual and system review: Is the work clear, consistent, and accessible?
Pre-development readiness: Is the design sufficiently complete for engineering?
Design QA: Does the implemented experience preserve the intended behavior and quality?
Shared standards
I documented practical expectations for:
Interaction patterns
Information hierarchy
Responsive behavior
Empty, error, loading, and permission states
Accessibility
Component use
Handoff readiness
Definition of done
Design QA
These standards created shared language across Design, Product, and Engineering.
System-level improvement
When critiques surfaced the same issue repeatedly, I treated it as a system problem rather than an individual performance problem.
Recurring needs were converted into:
New shared patterns
Updated design-system guidance
Component improvements
Accessibility standards
Workflow principles
Examples for future teams
This allowed individual design feedback to create organizational leverage.
The quality practice introduced
Rather r than evaluating designs primarily on visual polish, I introduced a broader quality framework.
Each experience was assessed across six dimensions:
1. User clarity
Is the purpose of the experience immediately understandable?
Are actions, system status, and next steps clear?
Does the interface reduce cognitive load?
2. Workflow effectiveness
Does the design reflect how users actually complete the task?
Are unnecessary steps, decisions, or interruptions removed?
Are complex processes broken into manageable stages?
3. Information architecture
Is content organized according to user mental models?
Are hierarchy, navigation, and relationships clear?
Can users find what they need without specialized product knowledge?
4. Interaction quality
Are patterns predictable and consistent?
Are system feedback, errors, loading states, and edge cases addressed?
Does the experience support both new and experienced users?
5. Accessibility and inclusion
Does the design meet WCAG-aligned expectations?
Are contrast, focus, labeling, keyboard behavior, and comprehension considered?
Does the experience work across different technical comfort levels?
6. System consistency
Does the design reuse established components and patterns?
Are deviations intentional and documented?
Should a recurring product need become a shared system pattern?
How I EVALUATED DESIGN CRAFT
The quality practice created:
>More consistent product experiences across teams
>Earlier identification of usability and implementation risks
>Stronger design reasoning and presentation skills
>Clearer expectations for designers and partners
>Better Product, Design, and Engineering alignment
>Greater reuse of shared patterns
>More systematic accessibility consideration
>Reduced dependence on late-stage subjective review
OUTCOMES
A complex enterprise workflow needed to support users with different roles, permissions, responsibilities, and technical experience.
The early concept technically supported the required actions but exposed too much system complexity at once. Navigation, terminology, progressive disclosure, error prevention, and system feedback were not yet strong enough.
During critique and iteration, I helped the team:
Reframe the experience around the user’s primary task
Simplify the information hierarchy
Separate frequent actions from advanced actions
Clarify status, ownership, and next steps
Identify missing edge and permission states
Replace one-off interactions with reusable patterns
Improve accessibility and comprehension
Align the solution with engineering constraints before handoff
The result was not simply a cleaner interface. It was a more understandable and scalable workflow that could be supported consistently across the product portfolio.
A REAL-LIFE example
I avoided treating every design decision as equally important.
We prioritized deeper review for experiences with:
High user frequency
Financial or compliance risk
Complex permissions
Significant support volume
Cross-product impact
New interaction patterns
Accessibility implications
High engineering cost to reverse
Lower-risk work used established patterns and lighter review.
This right-sized approach allowed the team to move quickly while focusing craft attention where design quality had the greatest customer and business impact.
