Solving Problems With Systems That Scale

Typical Problems Design Teams Face

When I join a design team, I typically encounter similar issues:

• Execution without strategic influence

• Reactive delivery over proactive problem solving

• Creativity without the ability to translate it to real value

• Opinion-driven decisions instead of evidence-led direction

• Fragmented quality and siloed collaboration

• Under-leveraged management level lacking authority or autonomy

My Approach: Diagnose First, Then Deploy Systems

Instead of jumping in to solve each problem immediately, I take the time to look for underlying patterns.

I start by observing and listening, understanding how work is conducted and received. This diagnosis tells me which problems are real versus perceived, what already works, and which gaps need to be filled.

To solve these common patterns, I’ve come up with repeatable systems. But I implement only what's needed. If something is already working, I don't change it to match my playbook.

Translating Design Into Business Value

When design isn't understood by stakeholders, I break down how design decisions (layout, scale, color, and visuals vs text) lead to measurable business outcomes.

Community-Based Design Reviews

Traditional reviews produce shallow feedback. I organize reviews by “community” (user journey or product area) so feedback comes from designers who understand the context.

A New Approach to Design Team Retros

Traditional retros treat all feedback equally, creating unfocused action. I separate work from wellbeing and prioritize needs by urgency.

Now/Next/Later Discovery Planning

When design time isn't accounted for in delivery-focused roadmaps, I make discovery work visible by showing what's in development now, in discovery next, and exploration later.

Post-Stakeholder Review Cycle

When executive feedback is vague and misunderstood, I encourage designers to align with PMs on what they heard, then confirm with stakeholders before executing.

Design Brief

To prevent work starting without clarity on scope and constraints, I use Design Briefs that define the problem, hypothesis, dependencies, constraints, and success metrics upfront.