大部分产品团队的通病在于，他们往往按照自己臆想中用户意愿开发产品，而置目标用户的实际需求于不顾。基于上世纪 90 年代设计 Windows 和 OS2 机器的亲身经验，我总结出这样一条产品哲学，“设计服务于菜鸟，高级设置留给技术大牛。“

很多的技术专家往往以自己为中心搞产品设计，而产品发布数月后又在非目标用户中对其测试——如果有测试这回事儿的话。如果你从没组织过货真价实的用 户测试——在不加任何说明的情况下让用户完成一些简单的任务，你会对测试结果大吃一惊，本以为稀松平常的任务新用户却极难上手。

这种情况我深有体会。

当电脑由“绿色屏幕”切换至 Windows 时，我们，一群年轻、有学识的技术发烧友们很快就领会了其中要领。但这对客户服务代表们就没有那么乐观了，他们往往对键盘快捷键熟稔于心，却显然不愿意接 受新事物。我们花费了不知多少个晚上和周末为公务员们讲解新系统的操作方法，目的就是为了让他们告别那个老掉牙的绿屏电脑。

最早的用户测试结果十分糟糕。那些客服代表们根本不想接受拖放、点击鼠标这种操控方式。电脑简直成了他们工作上的魔鬼，而他们只想通过敲入键盘指令高效完成工作，五花八门的鼠标操作于他们而言可说害人不浅。
我们生活在一个充满选择的世界中，但矛盾的是，我们往往讨厌丰富的选择，人们大多受不了复杂的事物。

想想你去饭店吃饭的经历吧，老板的出发点在于尽可能地让你选择中意的菜肴，“拜托，不能提供一些精品选项么？”越是不常上门的顾客越会这样想。你既 不了解菜单上到底有哪些菜品，也没有时间细细琢摸。所以一般你会问服务员，“有什么推荐的？”或者直接点特色菜作罢。对菜单熟稔于心的老板、主厨和服务员 也在犯嘀咕，” 多大点事儿，点自己喜欢的就可以了！”

这个比喻只是为说明新顾客只是想在一个尽可能简化的菜单上吃到最好的东西，并在不劳神的情况下获得快乐的体验，仅此而已。

十多年来，Windows 系统中应用的设计一日不比不日，技术专家们总是被告知在产品中塞进尽可能多的功能。 我们都能造出迷你型芝士工厂了。

“设计服务的是菜鸟们，高级配置的乐趣留给技术大牛。“

我的产品哲学很简单。设计服务的对象是非技术专家群体——“菜鸟们”。尽可能少的选项，以缩小用户选择的范围，把产品最精髓的功能呈现给他们。像为自己的母亲设计产品那样去思考。

看看数据你就会明白，绝大多数人并不是产品的活跃用户，因此你不能假设他们能轻易就上手，如果他们不知所以，可能再也不会用这个产品了。

我理解你想开发出功能强大产品的苦心，希望在产品中看到你觉得好的产品。坦白讲呢，这个工作应该放在新品发布后，然后根据超级用户的反馈进行新功能扩充。

还有一件事情须说明。据说，超级用户总是能够把产品的功能摸得一清二楚，即便它们隐藏地很深。不妨预留一个按钮给他们手动操作的空间，以体验产品更复杂、更牛的功能。

但一定要确保高级功能的隐蔽，免得某个菜鸟不小心碰上搞得一头雾水。还有不要对我言听计从。实实在在地做用户测试，确保参与测试的用户不是你从自己生活圈里随便拉来的。你主观臆断的所谓“基础功能”很可能还是有些难为人。

在 2005 年我们在 Koral 开发新产品时就是带着这种产品思维操作的。当时我们刚被 Salesforce 收购，他们请我们设计一些方案做用户测试， 我们把讨论会摄录了下来，并设定了一些基本的测试办法：

* 上传文件到我们的系统
* 创建一个新的文件夹
* 将文件移动至新的文件夹
* 将文件发送给朋友
* 等等

结果十分沮丧，我们认为原本自然、简单、傻瓜式的任务基础用户还是不明就里，所以，除非是在为旧金山的技术大牛们开发产品，我们都要三思而后行。

我合作过的有些团队全力支持“精益创业运动”中提到的用户测试模式，他们往往通过阶段性的用户反馈一步步更新迭代产品。

所以当你做新产品预估时，确保尽可能地考虑到所有的假设。在加入新的功能时，问问自己是否应该放弃一些东西。

切记很多时候“少即是多”。

不要以自己为中心开发产品，也不要盲从某个朋友的看法，“要是你怎样怎样就好了…”

当然也不要被你的 VC 牵着鼻子走，他们往往没有任何设计经验。
我的意思是说，基础设计当以基础新用户为中心。
不管我怎样向合作团队提类似以上的建议，我还是会得到一个反馈，“不过，我们只是需要…”，这几乎成了他们增加新功能的借口。

认真做用户测试。找到真正的用户需求。在移动互联网的世界，我想你更明白MVP（最简可行产品）的重要性，人们都喜欢简洁易用的产品。

原文来自：36氪