新项目最容易犯的错，是过早进入视觉。团队兴奋地讨论配色与插画风格，却在两个月后发现核心流程走不通，不得不推倒重来。我们的做法是先把「体验骨架」钉死，再谈表面。
问题一：用户带着什么任务进来？
不是「用户是谁」，而是「他此刻想完成什么、以什么为完成信号」。把任务写成一句可验证的话，例如「在 3 分钟内找到并导出上个月的报表」。这句话会成为后续所有取舍的标尺。
问题二：最短路径有几步？
画出从进入到完成的每一步，标出所有分支、等待与回退。多数产品的第一次优化，不是增加功能，而是删掉两三个并非必要的确认步骤。
问题三：异常状态长什么样？
空数据、加载中、权限不足、网络失败、超长文本、极端数值——这些状态决定了产品在真实世界里的可靠性，却常常在上线前才被想起。我们在原型阶段就把它们画完整。
一个只画了理想路径的原型，不叫原型，叫愿望。
骨架先行，视觉后至
当结构、路径与状态都被确认，视觉设计就不再是猜测，而是在为一套已经成立的秩序找到合适的语气。返工率会显著下降，团队协作也会顺畅得多。