入行较晚，最近才知道palm。通过晓生的博客的启发http://daichuanqing.com/index.php/archives/3042简单评测Palm Veer，我去搜集了palm的资料，幸运地找到设计师电台Anyway.FM 两期干货满满的解读。
palm，掌心。敬畏这样的团队，设计理念始终如一「palm」，创造着属于未来的产品。
《Zen of Palm》看到这个文档，几乎要留下泪来。天呐 这个团队也太……
用三个禅语，解读产品设计
谜语#1：大猩猩要怎么学习才会飞？
在手持移动端设备还处于萌芽阶段的90年代期，几乎所有厂商都不知道一个在掌上运行的电脑到底要怎么做才能满足用户的实际需求。苹果的掌上电脑 Newton MassagePad 就是一个一斤重的砖头，HP 将一个续航只有几个小时的砖头大小的电脑和一个步话机集成到一个公文包当中，而微软则三番两次地试图将Windows 精简为一个小屏幕可用的操作系统，苦于硬件设备并没有雏形，操作系统的设计也没有头绪，直到Palm Pilot 出现。
受限于技术和当时移动端芯片的性能，掌上电脑（PDA）注定和桌面端/笔记本电脑有着巨大的性能差距，而手持设备是一个全新的领域，交互方式注定是不同于以往的，所有人都在尝试和探索。这时候的PC就是那只会飞的鹰，那么只能在地上奔跑、在树上攀爬的大猩猩注定是没法“学会”飞翔的。
猩猩和鹰注定是两个不同的物种，猩猩应该做好猩猩该做的事情。
在PC上，功能越多越好，它不会受限于电池容量、复杂程度，相反在几乎没有用户基础的移动端设备上，复杂的操作和繁复的功能会成为阻挠用户的障碍，过于先锋的功能可能会成为电池杀手，不成熟的交互则会让用户在使用过程中充满沮丧的情绪，而PC和手持设备的使用场景、操作密度以及时长都有着巨大的差异，不论从哪个角度上看，这都明显是两个物种。
怎么让大猩猩学会飞翔
基于用户的设计
当猩猩决定做好自己的时候，一切就逐渐明朗了。围绕着用户的需求和体验来设计一个PDA，不再是一堆功能和特性的堆砌了。
硬件上，它要能尽可能小而轻便（至少要能放入上衣口袋）。在系统上，它的交互要尽量快捷方便，便于快速记录和操作，这样才符合它快速操作，简练交互的设定。定位上，它是PC的重要补充，相互依托，互相成就，两者并非对抗关系。当然，它同样追求性能，但是它将芯片性能置换为另外一种东西：完成任务的效率。将GTD（Get Things Done）的概念作为移动端交互的核心，也是Palm 系列设备让人着迷的一点。
这样一来，它的设计思路就很明晰了：
·轻便，手掌握持，可放入上衣口袋
·响应快速，即开即用
·触摸交互，使用触控笔输入（贴合当前用户习惯）
·围绕用户常用功能和习惯进行设计
·采用轻量级的系统和软件
·联通PC，互相补充
·打通常用功能，高效完成事务（GTD）
谜语#2：怎样将大山装到茶杯里面去？
佛经里面常常能看到类似的机锋。这个谜语早在Palm团队组件之初就有了，它是 Palm OS的开发者 Rob Haitani 的“禅解之谜”中最著名的一则。作为一个日裔美国人，Rob 曾经供职于Sony，对于产品设计有着一套自己的理论，而他喜欢将它们以这种禅理机锋的方式表达出来。
彼时，不论是以Sony为代表的日系产品，还是欣欣向荣的硅谷，在产品设计上常常陷入“多就是好”的误区。初代的Palm 产品能够快速取得成功，很大程度上是因为它在尺寸、响应速度、易用性、功耗、效率和价值上达到了其他产品所无法企及的平衡性与高度，加上它与家用PC的简易同步机制，让它快速地打开了市场，深入人心。Palm 将这种在功能和体验上所达到的平衡点称为“Sweet Point”，姑且称之为“甜蜜点”。
那么回到之前的问题，如何将大山装到茶杯当中去呢？依然抱有“多即是好”概念的人往往会回答“先将山缩小”，Rob 则常常会给出提示：“为什么要将一整座山都塞到茶杯中去呢？”
实际的产品研发当中往往是如此，多如层峦的问题，高如山峰的障碍。领导着Palm OS研发团队的Rob 对于“简化”的哲学极度着迷。
“少即是多，避免添油加醋，极力简化步骤，简单好过复杂。”
在产品刚刚问世的95年，这种简化之道很实用。当产品迭代到3.0之后，这种简化的思想在产品升级和功能膨胀过程中体现出极大的价值。
“采纳多数人的意见看起来是很好的解决方式，但是我并不喜欢，我也不想花时间在办公室中争执。……所以我们做了模型之后，让用户在Mac上测试，结果他们常常感到疑惑。此时，我的‘简单哲学’又该上场了。我们询问用户的感受，观察他们的操作，筛选常用的核心功能。”
80/20法则
产品的发展大多是向着完满、系统的方向进化，Palm的硬件和软件也不可避免地开始完善功能。用户的需求是不断发展、完善的，如何抓住用户的核心需求并不是空想出来的，而Zen of Palm给出的答案则是80/20法则：用户花费80%的时间和精力试图去解决的问题，构成了产品的核心需求，剩下的20%可以放弃。
抓住核心，同样需要做好简化。在提出新功能的时候，Rob的团队往往是遵循这样的简化方式：
·定义问题
·发现最简单的解决方案
·去掉不相关的东西
而功能往往是服务于用户的需求，只有真正便捷的解决方案才是用户想要的东西，所以他们会遵循这样的规则来完善解决方案：
·尽量减少杂乱的设计
·减少完成常用任务的步骤数
·隐藏破坏性的、可能带来风险的功能，比如删除按键
·谨慎增加复杂的功能
实际上，说到这里，第二个谜语的答案也就呼之欲出了：山中的石头和泥土是没有价值的，只需要把山中的钻石都找出来放到茶杯中就好了，泥土和石头都扔掉。
谜语#3：铁匠怎样才能学会打造完美的马蹄铁？
有了构思，梳理思路，完成设计，工作并没有完成。你需要验证你所设计的产品的品质，这样是用户测试的功能所在。
现如今的用户测试已经有比较完善的体系，不过Zen of Palm 所提供的思路也并不过时。
产品的设计和完善离不开设计师和工程师，而设计师和工程师的视角始终是比较固化的，所谓“我站在用户的角度”多数时候也是一个假命题，不同的身份所带来的认知偏差是固有的，能弱化而难以消除，而用户测试所带来的结果往往能够相对真实地反映用户的实际感受和产品的真实问题。
对于数字产品，许多微小的问题都会给用户造成明显的不适，所以用户测试的反馈能够相当真实的反映问题。基本的用户测试可以在设计阶段就着手准备，早期的测试更偏向模拟，粗糙一点甚至可以用手绘的原型进行简单模拟，有条件的团队可以使用HTML/CSS来写成网页，甚至可以使用AI、C++等不同的方式来呈现。除了完整的应用和系统测试之外，可以挑选特定的环节、特定的单个界面进行选择性测试，甚至可以进行目标用户和非目标用户的对比测试。
不过，不论是进行哪个阶段的用户测试，测试人员应当始终记住一些基本的标准：
·应用是否帮助用户达成某个目标，完成某个任务？
·用户能否根据应用的名称，界面中元素来判断应用的实际用途？
·你的应用中那些诱人的功能是否都能完美的执行？是否需要借助重设计来完成？
·用户要完整的完成某个任务需要多长时间？
·用户需要多久才能搞清楚并记住完成某个任务所需要的步骤和细节？
在进行用户测试的时候，不仅需要听取用户的实际反馈，同时也要观察用户的真实反应。
那么，一个铁匠要如何打造完美的马蹄铁呢？答案很有意思：从马的嘴里获取答案。
这其实是一个双关的回答，它包含两重含义：一方面需要马告诉铁匠它的需求和感受，另一方面，需要铁匠观察马的牙口来判断马的年龄、健康状况，在观察中判断。
用户有时候给出的答案并不完整，有许多细节并不会直接标识出来，甚至他自己都不清楚，这个时候需要测试者来发现，探索和总结。
20年前的三个谜语，为你揭示产品设计的禅理https://www.uisdc.com/zen-of-palm-three-riddles
Anyway.FM：最近蛮喜欢这两个设计师，上下班路上都在听。有很多调侃，很多设计师视角的东西，互联网早年的考古也很有趣，可以让我理解遗留的事物、演化的原因。他们俩的产品观念很好啊，是优秀的设计师～ 吃我一波安利
网友评论