Getting Feedback & Iterating
The scariest and most valuable thing you can do is watch someone use your project.
Not "hey, what do you think?" over text. Actually watch them. In person, or on a screen share. Watch where they click. Watch where they hesitate. Watch where they get confused.
You will learn more from 5 minutes of watching a real person use your thing than from 5 hours of staring at the code.
What to watch for
- Where do they look first? This tells you about visual hierarchy.
- Where do they click first? This tells you about affordances (what looks clickable).
- Where do they hesitate? This tells you about confusing UI.
- What do they say out loud? "Oh, I thought this would..." is pure gold.
- What do they NOT do? Features they ignore might as well not exist.
How to survive it
It's painful to watch someone struggle with something you built. Your instinct will be to explain: "Oh, you're supposed to click there." Resist. If you have to explain, the design is failing. Note what confused them and fix it later.
Don't ask "do you like it?" Ask "can you show me how you'd use this to [do the thing it's for]?" Then be quiet and watch.
The Five-Minute User Test
Disconnect exercise
Pick a project you've built. Send the link to someone who hasn't seen it — a friend, family member, colleague. Sit with them (in person or screen share) and say: 'I built this. Can you try it out? I won't explain anything — I just want to see how it feels to use it for the first time.' Then watch. Don't help. Don't explain. Take notes on: where they hesitated, what confused them, what they said out loud, and whether they could accomplish the main task without guidance.
Saved locally in your browser.
Iteration after launch
Shipping isn't the end. It's a phase transition.
Before shipping, you're working from imagination: "I think users will want X." After shipping, you're working from reality: "Users actually do Y."
What to pay attention to
Do people come back? If someone uses your thing once and never returns, that tells you something. Maybe it's a one-time tool (fine), or maybe it's not compelling enough to return to (less fine).
What do people actually use? If you built five features and everyone uses two of them, the other three might be clutter. Consider removing them. Subtraction is a feature.
What do people complain about? Complaints are requests in disguise. "This is confusing" means "I want to understand this but can't." "This is slow" means "I value this enough to be frustrated by the speed."
Knowing when to stop
Not every project needs to be maintained forever. Some projects are complete. Some served their purpose and can be archived. Some taught you what you needed to learn and don't need more investment.
It's okay to stop. Ship it, learn from it, move on. The next project will be better because this one existed.
Build Session
Take an existing project and ship it properly. Choose something you've built that works but isn't polished. Add: error states, loading states, an empty state, mobile fixes, and a clear landing experience for first-time visitors. Deploy and send the link to at least one person.
~45 min
Chapter 4 of 4