How I Work
My approach is simple: understand the problem, design for clarity, build with constraints in mind, and measure what matters.
I don't follow a rigid process. Every project is different. But there are patterns in how I approach problems—especially when the goal is to turn something complex into something simple.
Understand & Research
What I do
- Talk to stakeholders — What are the business goals? What constraints exist? What's been tried before?
- Talk to users — What are they trying to accomplish? Where do they get stuck? What workarounds have they created?
- Audit the current experience — Click through existing flows, note friction points, identify where people drop off
- Review analytics — Where are users spending time? Where are they leaving? What paths are they taking?
- Identify assumptions — What does everyone believe is true that might not be?
What I deliver
- •Clear problem statement (not a feature request)
- •User pain points mapped to business impact
- •Constraints and requirements documented
- •Alignment on what success looks like
You can't design the right solution until you understand the right problem.
Define & Strategize
What I do
- Map user journeys — What are the steps from awareness to completion? Where's the friction?
- Prioritize problems — What will have the biggest impact? What's feasible given time and technical constraints?
- Set design principles — The 3-4 rules this solution needs to follow (e.g., "Clarity over features")
- Define success metrics — What will we measure? How will we know this worked?
- Identify technical constraints — What's realistic to build? What are the limitations?
What I deliver
- •User journey maps showing current vs. ideal state
- •Prioritized list of problems to solve
- •Design principles specific to this project
- •Success metrics defined upfront
Strategy before aesthetics. If you don't know why you're designing something, you can't design it well.
Ideate & Prototype
What I do
- Sketch multiple directions — Explore 2-3 different approaches on paper or in low-fi wireframes
- Focus on flow, not visuals — What's the sequence of steps? What information is needed when?
- Prototype key interactions — Build clickable prototypes to test the flow, not just show static screens
- Test internally first — Walk through the prototype with the team before showing users
- Refine based on feedback — Iterate quickly, adjusting flows before adding polish
What I deliver
- •Low-fidelity wireframes exploring multiple approaches
- •Clickable prototypes showing key flows
- •Rationale for design decisions
- •Identified edge cases and error states
Test the logic before you polish the pixels. A beautiful design that doesn't work is still broken.
Test & Iterate
What I do
- Run usability tests — Watch 3-5 people attempt key tasks. Where do they hesitate?
- Ask "why" relentlessly — When someone clicks the wrong thing, understand what they were thinking
- Identify patterns — If one person struggles, it might be them. If three struggle, it's the design
- Prioritize fixes — What's breaking the experience vs. what's just suboptimal?
- Iterate and re-test — Major changes get retested. Minor tweaks move forward
What I deliver
- •Usability test findings with specific recommendations
- •Updated prototypes addressing critical issues
- •Confidence that the design will work before development
Your users will tell you what's broken. Listen to them.
Design & Document
What I do
- Apply visual design — Typography, color, spacing, imagery—polished and on-brand
- Design for all states — Empty, loading, error, success states
- Build component libraries — Reusable components that scale across the product
- Create responsive layouts — Mobile, tablet, desktop at different viewport sizes
- Annotate for developers — Spacing values, color tokens, font sizes, breakpoints
What I deliver
- •High-fidelity mockups in Figma
- •Component library with variants and states
- •Developer handoff documentation
- •Responsive designs for multiple breakpoints
Beautiful design is useless if developers can't build it correctly.
Build & Collaborate
What I do
- Build front-end components — I often code the UI myself (React, Next.js, HTML/CSS)
- Work alongside developers — In Slack/standup answering questions and unblocking issues
- Adjust for technical reality — Sometimes the ideal design isn't feasible. I adjust without compromising UX
- Review in staging — QA the implementation to ensure it matches design and functions correctly
- Handle edge cases — What happens when the API fails? What if there's no data?
What I deliver
- •Production-ready code or detailed QA feedback
- •Solutions to technical blockers during development
- •Confidence that what ships matches what was designed
Design isn't done until it's shipped. Staying involved catches problems before they reach users.
Measure & Optimize
What I do
- Track key metrics — Did completion rates improve? Did drop-off decrease? Did support tickets go down?
- Gather user feedback — What are people saying? What's still confusing?
- Identify new friction points — What problems did this solution create? What did we miss?
- Iterate based on data — Small tweaks can have big impact. Adjust and re-measure
- Document learnings — What worked? What didn't? What would I do differently?
What I deliver
- •Post-launch analysis showing impact
- •Recommendations for iteration
- •Documented learnings for future projects
Design improves when you watch how people actually use it.
Tools I Use
Design
Figma, Pen & Paper, Whimsical
Development
React, Next.js, TypeScript, Tailwind CSS
Prototyping
Figma, CodeSandbox, Stackblitz
Testing
Maze, UserTesting, Guerrilla testing
Analytics
Google Analytics, Hotjar, PostHog
Collaboration
Slack, Linear, Notion, GitHub
What Makes My Process Different
I don't separate design and development
I design with implementation in mind and often build what I design. Fewer "can we actually build this?" conversations.
I prioritize clarity over trends
I'm not designing for awards. I'm solving real problems for real users. If it works, it works.
I design for decisions, not screens
Every screen is a decision point. My job is to make those decisions obvious and frictionless.
I iterate based on data, not opinions
I have opinions, but I trust data more. If users are struggling, I adjust—even if I love the original design.
I explain my thinking
Stakeholders and developers get context, not just deliverables. I explain why I made specific choices.
How We'd Work Together
If you hire me, here's what you can expect:
- →I ask a lot of questions upfront. I need to understand the problem, constraints, and goals before I design anything.
- →I show work in progress early. I don't disappear for two weeks. I share rough work, get feedback, and iterate.
- →I push back when something hurts the user. I'm collaborative, but if a requirement creates a bad experience, I'll explain why and propose alternatives.
- →I communicate clearly. I avoid jargon, explain tradeoffs, and make sure everyone understands what we're building and why.
- →I ship. I don't just design—I see things through to launch and measure their impact.
Let's Work Together
If this sounds like a good fit, let's talk.