A prototype should answer one question
Choose the uncertainty, build only what the test needs, and write down what the result does and doesn't prove.
Thoughts on design, development, and building products.
Choose the uncertainty, build only what the test needs, and write down what the result does and doesn't prove.
Where it helps me build, what context I give it, and what I check before the code ships.
The design decisions that become visible when you build and use the interface yourself.
What I pay attention to before committing months to a product: the problem, the first release, pricing, and finding customers.
Choose the uncertainty, build only what the test needs, and write down what the result does and doesn't prove.
Date ranges, saved filters, and empty states decide how much work someone has to do before the product is useful.
Where it helps me build, what context I give it, and what I check before the code ships.
The design decisions that become visible when you build and use the interface yourself.
What I pay attention to before committing months to a product: the problem, the first release, pricing, and finding customers.
How I cut scope without cutting the parts that make a first release usable.
Start with shared tokens and a few well-defined components, then expand when the product gives you a reason.
Sharing unfinished work is useful when there's a specific decision someone can help you make.
How I turn a vague feeling that something is off into a decision I can explain and test.
Early customer conversations help you decide what to build and where to look for the next customer.
Written decisions protect focused time, provided the team knows when to respond and when to call.