How I Think About Design Problems
Over 3+ years working on healthcare platforms, government design systems, and cross-functional AI teams, I've distilled my design approach into 35 core questions across 4 pillars.
Why This Framework?
During my work on the Healthcare Prescription Platform, I realized every design decision — from making the exemption field mandatory to designing the dashboard layout — mapped to a fundamental question about user needs, constraints, or outcomes.
When I moved to designing a Ministry Design System for bilingual government services, the same patterns emerged: How do you prioritize accessibility over aesthetics? How do you push back on stakeholder requests that don't solve user problems? How do you document decisions for distributed teams?
This framework is the result of synthesizing those patterns into 35 questions that capture how I approach design problems. It's not theory — it's the actual mental models I use when shipping real products.
The Four Pillars
Each pillar represents a dimension of design thinking. Click through to see how I've applied these principles in real projects.
UX Fundamentals & Research
How I identify problems worth solving, validate assumptions without direct user access, and turn observations into actionable insights.
See in action: Ministry Digital TransformationProduct Design & Execution
Constraint-driven design in practice — from GDPR compliance to building component systems that scale.
See in action: Healthcare PlatformCollaboration & Constraints
Real-world stakeholder management, cross-functional teamwork, and designing under technical, regulatory, and business constraints.
See in action: Healthcare PlatformUX Depth & Senior Judgement
Post-launch improvements, designing for failure states, and measuring success beyond vanity metrics.
See in action: Ministry Digital SystemCore Questions I Ask
These are the 10 most critical questions that shape how I approach every design problem — with real examples from my work.
How do you decide which problem is worth solving?
I use impact × feasibility mapping. On the Healthcare Platform, we had dozens of pharmacy pain points, but I prioritized the exemption capture flow first because it affected 40% of orders and was technically achievable within our sprint timeline.
Healthcare Platform: Mandatory exemption field eliminated 40% of manual call-backs — high impact, medium effort, clear ROI.
How do you turn raw observations into actionable insights?
I cluster observations using affinity mapping, then ask 'so what?' for each theme. An observation becomes an insight when it reveals a behavioral pattern that suggests a specific design opportunity.
Ministry Design System: Clustered 23 stakeholder complaints about component inconsistency → Insight: Teams needed pre-built, accessible patterns, not just visual guidelines.
Walk me through a case where constraints shaped the solution.
On the Healthcare Platform, GDPR constraints actually improved the UX. The requirement for explicit data consent led us to design a progressive step-by-step flow that also reduced cognitive load — turning regulatory constraints into UX features.
GDPR mandatory consent → Designed multi-step order flow with clear data handling explanation → Better UX + compliance.
How do you design empty, loading, and failure states that reduce anxiety?
Empty states guide next actions ('Start your first order'). Loading states are progressive (step indicators, not just spinners). Failure states explain what happened, what was lost, and provide recovery steps — never just 'Error 500.'
How do you handle conflicting feedback from PM, Engineering, and Business?
I reframe every piece of feedback as a user outcome. When a PM wanted a bulk action feature, I asked 'What user problem does batch processing solve?' — turns out, the real need was faster individual edits, not batch operations.
Tell me about a time engineering said no — what did you do?
Engineering pushed back on real-time search for the Healthcare dashboard due to database load. Instead of arguing, I asked 'What would make this possible?' We redesigned it as debounced search with cached results — better performance, better UX.
How do you document design decisions so future teams understand them?
Every major decision gets a decision record: context, options considered, chosen approach, and explicitly — what we chose NOT to do and why. On the Ministry project, documenting 'why we didn't support IE11' saved 6 months of future debates.
How do you push back when stakeholders want changes without clarity?
I ask three questions: (1) What problem does this solve? (2) How will we measure success? (3) What happens if we don't make this change? These turn subjective requests into structured conversations.
How do you measure UX success beyond NPS?
I track behavioral metrics: task completion rate, time-on-task, error frequency, and support ticket volume. On Healthcare Platform, we measured 'orders completed without call-backs' — a more meaningful metric than satisfaction scores.
Healthcare: 40% reduction in call-backs = measurable UX improvement beyond NPS.
What makes a product feel trustworthy, not just usable?
Consistency, transparency, and predictability. Every interaction should behave as expected. Show users what's happening with their data (especially in healthcare). And never surprise them — especially with destructive actions.
Additional Questions (Click to Expand)
This Framework in Practice
Healthcare Platform
Constraint-driven design, stakeholder alignment, measuring behavioral metrics
Ministry Design System
Research synthesis, accessibility prioritization, cross-team collaboration
All Case Studies
See all projects where this framework guided design decisions
The Reframe Technique
How I turn subjective stakeholder requests into structured design questions
Want to see these principles in action?
Every project in my portfolio demonstrates at least 2-3 of these pillars. See how this framework shaped real design decisions on the Healthcare Platform, Ministry Design System, and more.