真实有用
从具体问题开始。做完之后，使用者应该少走一步、少等一会，或者终于能完成原本卡住的事情。
METHODOLOGY / HOW I BUILD
我怎么把一个念头，
做成能用的东西。
方法很简单，也经常被现实打乱。先找到一个真实问题，做出最小的完整路径，然后尽快交给人使用。
这套做法来自一次次动手、返工和发布。它还会继续变化。尽早发布
我更愿意先交出一个能跑通的小版本。真实使用会很快暴露哪些地方值得继续投入。
允许重做
方向不对就回头，结构不合适就重写。保留问题本身，不把已经投入的时间当成继续做错事的理由。
PROCESS / 01—05
一条反复使用的构建路径
顺序并不神圣。遇到问题时，我会退回前一步，重新确认判断。
先把问题说清楚
我会先写下一个具体场景，谁在什么时候遇到了什么麻烦。说不清场景，功能通常也做不清楚。
砍到可以发布
第一版只保留解决核心问题所需的部分。范围越小，越容易尽快交给真实用户判断。
跑通完整路径
页面好看还不够。我会从入口一路走到结果，确认用户能够理解、操作，也能在失败时找到下一步。
早点拿到反馈
产品进入可用状态后就开始观察。真实使用中的停顿、误解和重复操作，比功能设想更有价值。
留下决定，再继续改
每轮迭代都记录为什么这样改。有效的部分继续打磨，走不通的方向及时停掉。
BEFORE SHIPPING
发布之前，我会再问四遍。
这四个问题不能保证产品一定成功，但能拦住不少自我感动和无效复杂度。
现在有人会遇到这个问题吗？
先找到具体的人和场景，不用想象中的需求替代真实困扰。
第一版能完成一件事吗？
功能可以少，但从开始到结果必须走得通。
用户需要猜下一步吗？
按钮、状态和错误提示都应该让人知道发生了什么。
一个人能继续维护吗？
控制依赖与复杂度，给后续更新留下足够空间。
BUILD → SHIP → LEARN