How I design for conversion
Most tested ideas do not move the metric they were built to move. That is the argument for small changes, fast, with the question written down first.
Find where people give up
Before anything gets designed, I want the step where people leave. Not the page that looks worst, the step that loses the most money. Those are rarely the same, and designers tend to be drawn to the first one.
That means looking at the funnel by stage, on the device where the traffic actually is, and asking what a visitor can tell at each step without tapping anything.
Write the hypothesis before opening Figma
A hypothesis names the change, the expected effect, and the reason. If we change X, then Y will improve, because Z about how people behave here.
The "because" is the part that earns its keep. It is what makes a losing test informative, because a loss tells you the belief about behavior was wrong, which is worth more than a win you cannot explain.
Change one thing at a time
A variant that changes the copy, the layout, and the interaction will sometimes win, and will never tell you why. I isolate along one vector so the result is readable, which is the discipline I learned designing A/B tests for hotel search.
Name the metric, and the one that must not fall
Every test gets a primary metric and at least one guardrail. Conversion can rise while returns rise faster. Signups can rise while activation falls. A result without a guardrail is a number, not a finding.
Rank the backlog honestly
Ideas get scored on reach, expected impact, confidence, and effort. Cheap tests that teach something fast beat expensive tests with a better story, because the point is learning rate, not any single win.
Why some of this work has no screens
A lot of my experience sits inside enterprise and client work covered by agreements that do not let me publish the interfaces: teller transactions, dealership service tools, an internal sales platform, hotel search variants. I can describe the problem, the reasoning, and the structure of the work, and in several cases I cannot show you the pixels.
Rather than pad a portfolio with redesigns nobody asked for, I publish teardowns of live, public storefronts. They show the part of the work that is actually hard, which is deciding what to test next and why.