My process adapts to constraints but typically follows:

1. Understand: Research, stakeholder interviews, define problem
2. Explore: Ideation, sketches, competitive analysis
3. Design: Wireframes, prototypes, visual design
4. Test: User testing, iterate based on feedback
5. Deliver: Specs, handoff, support implementation

Key: Know when to move fast and when to go deep based on risk and uncertainty.

I start by understanding the business goal, then dig into user needs. I ask: Who is the user? What's their current experience? What outcome do we want? I create problem statements like "How might we help [user] achieve [goal] without [pain point]?" Avoid jumping to solutions too early.

I consider: User impact, business value, technical feasibility, and effort.

Frameworks I use: Impact/effort matrix, MoSCoW (must/should/could/won't), user story mapping. I collaborate with PM and engineering to align on priorities.

Structure your answer: Context (what was the challenge), Process (how you approached it), Solution (what you designed), Results (metrics, user feedback). Focus on your contribution and decision-making, not just the final UI.

First, I try to understand the underlying concern—often feedback points to a real issue even if the suggested solution isn't right. I present my reasoning with data or design principles. If we still disagree, I propose testing both approaches. Ultimately, I'm collaborative—good ideas can come from anywhere.

They're usually aligned long-term—happy users drive business success. When there's tension, I look for creative solutions that serve both. I advocate for users while understanding business constraints. I present trade-offs clearly so stakeholders can make informed decisions.

• Empty states (no data, first-time user)
• Error states (what can go wrong)
• Loading states
• Extremely long/short content
• Permissions denied
• Offline/slow connection

UX: The entire experience—research, information architecture, flows, usability. How it works.

UI: The visual interface—typography, color, spacing, components. How it looks.

In practice, they overlap significantly. I focus on both because beautiful UI with poor UX fails, and great UX with poor UI undermines credibility.

Dribbble/Behance for inspiration (critically), follow design leaders on Twitter/LinkedIn, read case studies, use products critically, attend conferences/meetups. But I distinguish trends from fundamentals—good design principles are timeless.

1. Define success metrics upfront
2. Research: user interviews, competitive analysis
3. Map user journey and identify pain points
4. Sketch multiple approaches quickly
5. Create low-fi wireframes to test flow
6. Refine with high-fi designs
7. Prototype and test with users
8. Iterate based on feedback

• Figma: Primary tool—collaboration, prototyping, design systems
• FigJam/Miro: Workshops, user flows, brainstorming
• Maze/UserTesting: Unmoderated research
• Notion: Documentation, specs

Tools matter less than process. I adapt to team standards.

• Quantitative: Task success rate, time on task, conversion, NPS, retention
• Qualitative: User feedback, usability test observations
• I define metrics before designing so we know what success looks like

Generative (discovery): User interviews, contextual inquiry, diary studies

Evaluative (validation): Usability testing, A/B testing, surveys

Method depends on question: "What should we build?" vs "Does this work?"

• Prepare a discussion guide with open-ended questions
• Build rapport first, then dig deeper
• Ask about behavior, not hypotheticals ("Tell me about last time you...")
• Follow up with "why?" and "can you show me?"
• Avoid leading questions
• Take notes and record (with permission)

Affinity mapping to cluster observations, identify patterns, create personas or journey maps, prioritize insights by impact and frequency. Document key findings with quotes. Share with team through presentations or Notion docs.

5-7 users find ~80% of usability issues (Nielsen). For quicker iteration, even 3 users reveal major problems. More users for quantitative confidence. Quality of participants matters more than quantity—recruit users who match your target audience.

Personas are research-based archetypes representing key user segments.

Good personas: Based on real research, focus on goals/behaviors/pain points, used to guide decisions. Bad personas: Made-up demographics, unused after creation.

Understand the context—different users have different needs. Look for underlying patterns. Consider user segments differently. Sometimes users say one thing but do another—behavior data helps. You can't design for everyone, so focus on your primary users.

Journey map: End-to-end experience including emotions, touchpoints, pain points. Broader view.

User flow: Specific path through an interface to complete a task. More detailed, focused on screens/interactions.

1. Define test objectives and tasks
2. Recruit representative users
3. Prepare prototype and test script
4. Encourage thinking aloud
5. Observe without helping (hard!)
6. Note where users struggle
7. Debrief and synthesize findings

Surveys: Quantitative data, larger sample, specific questions, validating hypotheses

Interviews: Deep understanding, exploring "why", generative research, nuanced topics

Frame research as risk reduction—it's cheaper to discover problems early. Show past examples where research prevented costly mistakes. Start small with guerrilla testing. Connect findings to business metrics. Invite stakeholders to observe sessions—seeing is believing.

• Consistent, reusable components
• Clear documentation and usage guidelines
• Flexible enough for edge cases
• Versioned and maintained
• Adopted by team—not just created
• Aligned with code implementation

Design system with shared components, design tokens (colors, spacing, typography), regular design reviews, documentation, Figma libraries with auto-updates, collaboration with other designers.

• Size: Larger elements draw attention first
• Color: Contrast highlights important elements
• Position: Top-left gets attention (in LTR languages)
• Whitespace: Isolation emphasizes elements
• Typography: Weight, style differentiate content

Start with brand colors. Ensure sufficient contrast (WCAG AA). Limit palette to 3-5 colors. Consider emotional associations. Test with color blindness simulators. Use color consistently for meaning (red = error, green = success).

Design that adapts to different screen sizes and devices using fluid grids, flexible images, and media queries.

Approach: Mobile-first (design for small screens first, enhance for larger), define breakpoints, consider touch vs cursor interactions.

• Limit to 2-3 font families max
• Establish clear type scale (consistent size increments)
• Ensure readability (line height, line length)
• Use weight and size for hierarchy
• Test at different sizes and devices

• Organized Figma files with clear naming
• Spec out spacing, sizes, interactions
• Document edge cases and states
• Review together, answer questions
• Stay available during implementation
• Review built product against designs

Wireframes: Low-fidelity, structure/layout only, no visual design

Mockups: High-fidelity static designs with visual detail

Prototypes: Interactive, simulates real experience, for testing

• Color contrast (4.5:1 for text, 3:1 for large text)
• Don't rely on color alone for meaning
• Keyboard navigation support
• Clear focus states
• Alt text for images
• Proper heading hierarchy
• Touch targets min 44x44px
• Test with screen readers

• Allow for text expansion (German ~30% longer)
• Avoid text in images
• Consider RTL languages (flip layouts)
• Use universal icons where possible
• Date/time/currency formats vary

Structure: Describe the request, explain your concern (backed by data/principles), how you communicated, what you proposed instead, outcome. Show you can be diplomatic while advocating for good design.

Involve them early (constraints shape design). Understand technical limitations. Be flexible on implementation details while protecting UX. Provide clear specs but stay collaborative. Value their expertise—they often have good UX ideas too.

• Start with problem and goals, not solutions
• Explain your reasoning and trade-offs
• Show the journey, not just final screens
• Anticipate questions and concerns
• Use data and user quotes to support decisions
• Be open to feedback