最近在帮公司找 mobile app developer，跟不同的 developer 间有很多意见的交流，也从他们的开发经验里学到不少不同的逻辑跟观点。
“你们的 app 看起来还很阳春，不像 Facebook 那么完整”
“为何要像 Facebook 呢?为何要那样『完整』呢?”
这个问题涵盖了两个区块：
1. 观摩其他人的产品很常见，可是我们往往陷入一个“我觉得很好”的圈套里。我们每一个人充其量只能代表使用者的某一个类型跟面向，所以如果不去想想自己要开发的产品的定位跟本质，就很容易在“观摩”时，开发出其实并不是符合自己产品特性的服务。
例如，Pinterest 问世时，“瀑布流”(waterfall)的佈局蔚为风潮，很多网站纷纷把自己的浏览界面改得很像是 Pinterest，不过却产生了很多问题。
主要原因在于 Pinterest 的产品设计逻辑与其产品原创发想时的需求跟定位有关，许多需要使用者阅读的网站采用了同样的设计，却忽略了原始构想的“适性”(adaptive)的问题，试想一个以浏览视觉元素为主的设计，套用在以文字内容为主的网站，会有什么结果呢?
“不好用”，这是可能得到的答案，也是大多数使用者不习惯的时候常说出口的一句话。
2. 什么是“完整”呢?这是一个因人而异的问题。
曾经，有一个朋友这样问“你们为什么不新增这个功能呢?这样很难用，我去用 Facebook 就好了”。
我的答案是：“这个功能不适合我们。如果 Facebook 推出什么功能，我们就非得也要有相同或类似的功能，那么使用者的选择基础相同，必然会选择具备丰富资源、金援的产品，这样我们被放在同一个盘子上比较，便失去了特色了。”“猫是猫，不是狗，要如何要求猫学狗叫呢?”
手机是一个不同的介质，有其限制、特性，以及使用时机的限制，人们使用手机的时间通常非常短、碎片化，所以满足在行动平台上可能的几种主要需求便已足够，我们必须了解哪些是最主要、大部分使用者会使用到的功能，把这些功能做好，那么就没有完整与否的问题了，因为使用者的需求永远是不满足的，要照顾到所有人的需求是不可能的任务，但千万别尝试想把所有功能搬到手机上，否则即使做得“很完整”，最后可能还是会得到同一个答案：“不好用”。
其实，使用者懂得选择符合自己需求的产品，但有必要不断的在自己的服务或产品上新增功能吗?
我的答案是：是，不是。
是：要推陈出新，甚至整个翻新，让使用者尝鲜的心态获得满足，但另一方面必须要顾虑到设计的一致性，避免新的设计或功能偏离了产品的定位。
不是：同时间，随时检视已经开发好的功能的使用状况，最好的方法是透过统计数字来观察使用的状况，当使用的频率不高时，我们必须回头思考两个问题：是这个功能真的没有需求了(没太多人使用)，还是这个功能欠缺某些补给，例如：更好的整合、更明显或流畅的位置及使用流程。对于真的不受欢迎的功能，必须当机立断淘汰(retire)掉，因为过多的功能反而容易造成使用者的混淆，增加使用者使用时的选择的成本。
其实这也是很多人设计产品时常犯的问题：拿一个产品定位不太相同的产品来相比，然后要求自己跟那个产品一样『完整』。其实只要使用者的主要需求被满足了，他们真正要的往往并不是“完整”，而是“顺手”跟“够用”。
所以把时间花在“想像自己是使用者的情境”来设计一个产品才是正途。当然，“自己”永远都只能代表其中一个或一种使用者，所以，一个雏形完成时，可以多观察人、多从其他人的反应跟经验中得到回馈更好，这样产品才容易接近使用者实际的需求跟使用情境(use case)，而不是产品设计者“想像”中的需求。
让使用者“顺手”很重要
再来则是“顺手”。
想想看 Microsoft Word 有多少个功能?选单上看得到的项目，可能一两千个，看不到的功能，加总起来可能好几倍。但你常用或觉得用得到的功能有多少个?
“大概 15 个吧”，很多人大概会回答类似的答案。
既然你常用的功能只有 15 个，为什么还要把时间花在打造一个需要写一本书，拉长学习曲线，花去很多使用者时间，可能还会中途因为挫折而不想使用的产品跟功能呢?
把精神花在专注开发使用者最需要的少数核心功能，确保核心功能可以满足使用者“顺手”的需求，再来思考如何完善周边“必要”的附加功能，才不致在使用者觉得还不够顺手时，增加了使用者可能产生的新挫折感。
减法开发哲学
我在大公司受过的完整训练跟经验是：大公司的那一套完整产品开发经验跟流程不适合套用在每一个公司，特别是新创公司(startup)。
Startup 本身的资源有限、人力有限，必须要思考如何把资源投注在最重要的项目上，才不致浪费时间在开发“只有 20% 需求的功能”上 – 没错，要取悦所有使用者很难，因此，当资源有限时，必须取舍。
先照顾大多数人的需求，确保绝大多数使用者是被满足的，然后行有馀力再来检视是否必要满足剩下的使用者需求 — 有的时候，维持使用者的“饥饿感”是必要之恶，因为，很多时候连我们自己都不确定是否是短暂的需求，抑或可能发展出长久的使用习惯 — 这个问题跟购物慾望很像，当我们很喜欢一件商品时，心里头可能会开始囤积慾望，不断的堆积自己必须购买的理由，说服自己“我需要”，进而促成实际的购物行动，但很可能一两个礼拜后，这件商品就被晾在一旁了。
我认为 Startup 适用的开发方法是“减法开发”。
什么是“减法开发”呢?
1. 尽量列出需求
首先，团队可以天马行空发想，依照产品的主要定位构思不同的功能，并列出详细的使用情境(use case)，假设总共列出了 100 个待开发的功能。在这个阶段，我们先不去构思其可行性或是开发的时间。
2. 去芜存菁
现在，我们提出一个实际的假设：“我们的资源有限，只能开发其中 50 个功能，哪 50 个功能是非得要优先开发的?”
留意到了吗?第二个阶段我们必须思考的问题是：当我们必须取舍时，哪些功能是真正使用者必要使用的。取决“必要”性的关键在于，哪些功能是可能“现在(或暂时)没有也没有差别”。
3. 专注在核心项目
第三个挑战来了。“我们只有一半个月时间，依照目前的人力与资源，算一算可能只有 10 – 20 个功能可以如期被开发完成。”
我们必须在 50 个我们在第二阶段觉得“一定要开发”的功能里，再筛选出“真正必要”的功能。团队只需要专注在把第三阶段列出的 10 – 20 个功能开发完成即可。
因为，新创公司往往没有太多的资源，必须要在很快的时间内“做实验”(interation)，知道实验的结果，然后不断的从实验结果及经验中快速修正，继续做下一个实验，花费太多时间在开发一个大型专案，很容易把仅有的有限资源不知不觉中就耗费掉了。
把使用者的抱怨与不满变成助力
这是一句老话，可是我们往往(或偶尔)会忘记。千万别一开始就把所有资源都抑注在一个超大型的专案，因为对很多 Internet 的使用者来说，早已习惯测试新的服务跟产品，并提供自己的使用经验回馈，别放过广大的 beta tester 群所能贡献给你的价值。
开发一个超大型专案所冒的风险不小，因为一个新功能或新产品，往往推出后三个月内就会决定生死：这是一桩一翻两瞪眼的生意，很快就会知道结果。
所以，如果所冒的风险是如此，我们是要选择要花一年时间开发一个超大型、超完美的专案，还是很快地在三个月内先推出简单的版本呢?我会选择后者。
曾经，有一个公司耗费了很多人力、资源，花了两年时间开发一个新的服务，结果在一年半时，市场窜出了新的同样的服务，并且快速地在市场空窗期满足了使用者需求，掳获了很多使用者的心，形成一股不小的“实力”，最后只得花大钱跟其他竞争公司竞标，买下这个新的服务。
“测水温”是 Internet 软体或服务的常态，使用者早已习以为常，对于“不完美”完全可以理解，也很乐于尝试，因此，先推出核心的功能测水温，反应好再持续专注开发其他必要的周边功能来使得这个新服务变得更完善，反应不好，也不必冒着抑注了所有精力，花费很多时间开发一个大专案，却可能很快便知道不讨使用者欢心的结果的风险。
一次给一点，使用者最高兴
我承认这是我以前求学、工作时使用过的伎俩 – 使用者的期待是需要被管理的。
如果一次推出 100 项功能，大部分使用者不见得会觉得高兴，反而因为面临太多选择，亦或是在使用者遭遇到程度不等的问题，在这些功能里“迷航”了，他们心里头可能会觉得“不好用”。
其实，使用者接触一个新的服务都需要“学习”。每个使用者的学习曲线会依照他们的专业背景、接触网路的时间长短等而有所不同，这还不包括“适应”的问题。试想：100 项功能要花多久的时间才能上手，甚至“适应”(顺手)呢?
如果只推出 5 项功能，使用者可能会感到惊讶，很快地便可以上手，甚至可能到处广为宣传，使用者得到的成就感与满足感与前者有很大的不同。
你会选择哪一种方式呢?
source:http://www.iheima.com/archives/50687.html
