Balsamiq：从同事的一句抱怨开始

故事的起点

Peldi 在 2008 年的创业自述中写到，一位产品经理知道界面应该怎样工作，却没有时间学习复杂的设计软件。他由此寻找更简单的原型工具，后来着手制作 Balsamiq Mockups。初期开发安排在本职工作之外，产品也曾围绕 Confluence 插件构思。今天的公司介绍仍将独立经营与自筹资金列为自身特点。

这是一篇公开资料整理，不是对创始人的采访；下面是拾路的编辑观察，不代表公司给出的创业方法。

先观察一件反复发生的小事

这个切口值得琢磨：用户并非没有想法，而是表达想法的过程太费力。对准备做小产品的人来说，可以先列出身边反复出现的“我只是想……”：只是想给同伴说明页面，只是想比较两个方案，只是想让别人看懂流程。随后问清楚，当事人目前怎样解决、多久遇到一次、哪一步最耽误时间。

这种观察比先列功能更接近需求。功能可以很多，但用户决定试用时，往往只希望眼前的一个麻烦消失。第一次演示也可以围绕一个完整的小任务：开始时是什么状态，操作后拿到了什么结果，结果能否直接交给下一个人。

给第一版设一道边界

我们的建议是把第一版写成一段可以现场验证的承诺。例如，让没有设计经验的人把某个页面关系表达清楚。随后把不帮助完成这段承诺的想法暂存起来。暂存不是放弃，而是让有限的时间集中在最容易判断的价值上。

同时要认真记录支持成本。一个功能若总要作者在旁解释，可能还没有完成；一个产品如果只能在自己的电脑上顺利运行，也还不能证明陌生人能够独立使用。邀请几位真实用户完成同一个任务，比问“你觉得怎么样”更容易得到具体反馈。

可以带走的一个练习

选一个熟悉场景，写下用户、触发时刻、现有做法和期望结果，再做一个可交付的小样。观察对方是否主动再次使用，以及是否愿意把结果分享给别人。不要用别人的公司经历承诺自己的收入；这个故事更适合帮助我们缩小问题、建立耐心，并承认工作与生活的约束也是产品决策的一部分。