Oxygen's Shared Items

今夜酒店特价（一）：酒店业的奥特莱斯折扣商店

Thu, 19 Jan 2012 12:06:01 +0800

本文一共五篇，此为第一篇。作者任鑫（微博：@Mars任鑫），首发在雷锋网。

“今夜酒店特价”的商业模式是什么？

“今夜酒店特价”对于酒店和顾客会带来什么样的影响？

服务业里有一个词叫收益管理，说的是“在适合的时间，将适合的商品，以适合的价格，通过适合的渠道，以适合的方式，卖给适合的顾客，使得总收益最大化”。“总收益最大化”翻译成白话就是“多赚钱”，而“多赚钱”的来源其实只有两个：要么从每个顾客身上多赚一些，要么多拉点顾客进来。

这两个来源听起来是矛盾的，要多赚钱感觉就要高价，要多销感觉就要薄利。一般的做法是首先尽可能的吸引正常的销售，吸引不差钱的主儿，从他们身上能赚多少是多少。然后，再根据自己的剩余库存状况来判断会不会有东西卖不掉，有的话低价清销给注重性价比的顾客，卖一件是一件。这里面关键是区隔顾客和商品。第一个问题是怎样识别出“不差钱”的顾客和“注重性价比”的顾客，第二个问题是怎么设计不同的商品，让它们仅仅对某一类顾客产生吸引力。

举个例子，耐克鞋新款上市时可能卖八九百块，贵的还要上千。这些鞋子会通过百货公司或者其他繁华地段上的耐克专卖店销售，卖的都是全价。等过一阵子，发现部分商品滞销，这时就会把卖得不好的鞋子送到城郊的奥特莱斯折扣商店去卖，价格一般是原价的2-5折。这种安排其实经过了精心的设计：对于不差钱的顾客，他们想要的是“马上买到电视广告里看到的新款衣服”和“方便地去市中心的百货公司买到”，自然卖他们高价，能赚多少是多少；而对于注重性价比的顾客，则用“2-5折的价格”去吸引他们前往奥特莱斯购买。更关键的地方是，奥特莱斯往往安排在郊区，而且不销售当季热卖库存，这样就可以显著降低奥特莱斯对于不差钱的顾客的吸引力，让他们占不到“2-5折”这个便宜，继续乖乖的付全价。这样，从理论上（实际上还是会有偏差），我们就同时做到了“多赚”和“多销”。

从这个例子当中，我们可以看出，其实商家是用渠道和商品的组合来区隔了消费者。“方便渠道 + 热门商品”针对的是正常市场，“限制性渠道 + 限制性商品”针对的是特价市场。正奇搭配，获得利益最大化。其中奥特莱斯折扣店的设计就非常有趣，它并不仅仅是通过特价吸引顾客购买，已达到清销库存的目的。更重要的是，它人为设置了很多限制（例如“买不到当季最新款”、“交通比较不方便”），这些限制使得奥特莱斯在吸引注重性价比顾客的同时，并不会大规模的让不差钱的顾客迁移过来，不会显著影响到正常销售渠道的利润。

“今夜酒店特价”的定位就是酒店业的奥特莱斯折扣商店。每天晚上6点，酒店会检查自己的空房数量，如果空房数量太多，估计肯定卖不光，就放一些到“今夜酒店特价”平台上，以平时两折到七折的价格售卖。比如一家四星级酒店，平时房价599，今天晚上发现空房太多，就以250块的价格提供10间房给“今夜酒店特价”，“今夜酒店特价”加19块钱利润，以269块钱来卖。用户打开iPhone或者Android手机，打开“今夜酒店特价”APP，就能用269块钱订到四星级的房间，省了330块。酒店清空了自己本来会要浪费掉的库存，多赚了200块（假设洗床单被套换牙刷牙膏的成本高达50元）。而“今夜酒店特价”也得到了19块钱利润，三赢合作。

整个销售过程中，“今夜酒店特价”和奥特莱斯走的完全一样的路线：一方面，通过超低折扣价格吸引注重性价比的顾客，销售掉过剩的库存；另一方面，则用渠道（只能通过智能手机APP预订）、时间（只能在晚上6点以后预订）和商品（大部分酒店只能预定一晚）来增加限制，降低自身对于“不差钱”的顾客的吸引力，保护酒店的正常销售不受影响。通过这样“卖点”和“门槛”的组合，“今夜酒店特价”很本分地将自己定位在辅助性的尾货销售渠道上。

关于项目管理的一点体会

Mon, 07 Nov 2011 18:48:46 +0800

“1人100个月完成的项目，不是100个人1个月就可以完成。”

项目管理是让项目活动中相互竞争的各类制约因素：质量、进度、资源、风险等取得平衡的艺术，同时也是平衡项目干系人的各种需要、关注和期望，带领不同的人朝着相同目标迈进的领导艺术。

成功的项目管理可以简单理解为：按时、在预算内+满足产品需求+满足质量需求地完成项目。

以下是我对项目管理的一点体会记录。
——————————————————————————————————————————-

需求等级

视觉 A：图片没有分享功能吗？

技术 K：图片有链接转发分享、微博或邮件形式分享等多种分享，全部开发的话需要推延时间表。

策划 D：图片只做预览、下载已经足够了，暂时不做分享。

交互 E：如果我们的用户是基于邮箱用户，图片的邮件分享还是建议做。

… …

如果在前期产品需求文档中没有明确定义每个需求的优先等级，或者说项目成员对需求的优先等级没有明确的意识，可能类似的争论会时常发生在项目成员之间，每个人会基于自己对产品目标的理解来考虑这个需求是否要做，什么时候做，做到什么程度而产生分歧，因而增加项目推进的阻力。

所以在前期产品需求文档中，必须明确定义出每个需求的优先等级，需求的粒度可细化到每个大功能下的子功能需求，如：图片分享功能的转发链接分享、邮件形式分享这样的子功能需求。等级的划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等；

一般的需求等级划分：

P0 -Must have：如果缺失，产品不能发布

P1 -Should have：如果缺失，产品能发布，但不能达到预定目标（功能/性能）

P2 -Nice to have：做了则更好

P3 -Neutral：对产品没有明显的好处，用户不在意

… …

每个需求的优先等级确定之后，产品经理根据产品预定目标、开发成本、运营计划等来定义一个等级分界线，高于或等于这个等级分界线的需求在本期开发，部分根据成本、运营计划等因素调整到下期开发，而低于这个等级分界线的需求则只会在下期开发，这样让全体项目成员对本期要做的需求达成共识。

需求等级的实际应用：

WBS各工作包Triage的参考基准之一；Triage即确定需求任务是否要做，是否要现在做的一个共同决策过程；在Triage的过程中，任务owner对自己的任务以及其他人的任务有更全局的认识。
Bug的Triage的参考标准参考基准之一（也是zero bug *注1 和code freeze *注2 时间节点计算的参考基准之一）；Triage即确定测试中的Bug是否要修，是否要现在修；如：在功能开发期间，P0、P1、P2及以上的Bug都要修；当进入接口冻结期后，只有P0、P1normal及以上的Bug才允许修，以保证优先的Bug问题更快地被解决。

*注1 Zero Bug：当前不存在active bug，或不存在高优先级或特别严重的bug

*注2 Code Freeze：除高优先级或特别严重的bug外，代码冻结不再接受提交

——————————————————————————————————————————–

WBS

技术 K：相片上传的界面还没有搭建好吗？这部分我们需要先做起来。

前端 J：视觉设计师没有完成呢！

视觉 A：我在做相片的展示页面，还没有做到相片上传。

… …

项目各成员对自己需要负责的任务粒度细分不到位，每个任务的交付时间点不够明确，对任务之间的依赖关系也不够清晰，造成项目推进中的协作成本提高，项目时间预估准确率不高，项目控制的风险增加；

因此在产品需求文档确认之后，必须做工作分解 WBS（Work Breakdown Structure），即把需求分解成较小的、易于管理的工作包。一般的工作包是最小的“可交付成果”。工作包必须详细到可以对该工作包进行估算（成本和工时）、安排进度、分配负责人员或组织。

项目经理、项目成员和所有参与项目的职能主管都应该参与WBS工作，根据项目规模情况，可以由项目经理或各模块主策划来组织。组织方负责召集有关人员，集体讨论所有项目工作，确定项目工作分解的方式后，各职能方提交各自的WBS，汇总后画出WBS的层次结构图。结构图中应包括每个工作包名称（内容定义）、指派人员名称、所需工时、可能的依赖关系等；

WBS的工作包，最终以任务形式录入到QA中进行跟踪管理。

WBS的好处：

为资源、成本、进度、质量等控制奠定共同基础，确定项目进度和控制的基准；
为各独立工作包分派人员，规定这些人员的相应职责，便于项目职责的落实和明确划分；
针对各独立工作包，进行时间、资源需要量的估算，提高时间、资源估算的准确度，并确定工作顺序，提高协作效率，利于更准确的制定项目进度计划表；

——————————————————————————————————————————–

QA可视化项目管理

技术 K：我完成到图片分享功能，图片下载的bug已经就提交上来了，但是我现在没有时间改bug。

测试 F：我已经提了一轮的bug了，但是我不知道bug什么修好，然后我可以去复查。

交互 E：图片分享功能开发完成了？可以测试了吗？

产品经理：现在大概还有多少P0的bug？zero bug时间节点是否需要后延？

… …

如果没有QA，项目的状况不是对每个项目成员透明化，就会出现以上的各种情况；

QA作为协同式任务管理工具，通过对每个任务的记录和跟踪，让项目成员对整个项目的情况有直观的了解，项目经理可随时监控项目推进中的风险是否在可控范围，并提前快速作出调整。

不管是前期开发的工作包还是后期的测试bug，均以任务的形式录入在QA里，然后对这个任务的一些基本属性做设置，如：属于哪个milestone、哪个模块等，然后由各个阶段的Triage的负责人按照需求等级标准来对任务作分类定级，并确定是否做，是否现在做；所有的任务都必须经过Triage并approve通过，才能开始工作。Triage的决策需要多个层面的知识（结合产品、技术、进度等多方因素），特别是在大项目中，Triage往往是一项群体工作，以功能小组（feature team）或产品决策组的方式来进行。在项目的不同阶段，可以由不同的角色来主导Triage流程。

在任务approve后，各职能方leader将任务指派给相应具体执行的人员。执行人员，也就是任务的owner，必须设置任务的Status date，如：Status任务状态是Working（进行中）；Status date即完成日期点，Status date应真实反映实际工作计划，并应契合项目时间表。

在执行人员完成任务时，QA会通知各职能方leader去关闭这个任务，关闭的意义在于通知任务的相关跟踪者，可以着手下一部分的工作，如某功能代码任务关闭，即相关测试人员就知道可以开始这个功能点的测试工作；

通过任务在QA系统里的记录和跟踪，以及任务状态的实时更新，最终会汇总生成各种可视化的图表，项目进展直观，且可度量，能够很好的把握整个项目推进的节奏，对项目中各项问题和风险定位更容易，并可在周会上对项目的所有成员公开进度信息，便于协调一致；

其中最重要的图表：glide path任务走势图：

“实际任务走势”与“计划任务走势”的对比，可以衡量出计划与实际的偏差。

——————————————————————————————————————————–

每日构建

技术 K：我们只在每个小milestone才会打build。

交互 E：希望可以每日bulid，我可以每天拿到最新的版本进行测试。

测试 Q：我建议测试前期可以每个milestoen打版本，但是中期开始，每日build。

… …

每日构建（daily build）是指每天对整个项目做一次完整的自动构建，生成可执行文件的过程，对Web类产品，每日构建通常要伴随自动部署的过程，将这些可执行文件部署至测试环境，并按照一定的规则对这个安装包或测试环境做版本编号，是一种Public build的管理方式。

每日构建是编译管理的一种方式，项目初期，可根据根据需要按照一定的频率打，如：每周、每个milestone，随着项目的进行频率逐渐增加build的频率，如：每天build。

每日构建的好处：

每日构建让从产品经理、项目经理、策划、交互、视觉等所有的项目人员从第一个小功能模块完成开始，能够随时测试最新的版本提交bug，并能及时了解技术开发的进度；
每日构建让测试人员从第一个小功能模块完成开始，能够每天测试最新的版本，提交新bug和复查部分bug，而不需要等着某个小milestone或者所有的功能代码都实现了，再开始测试，大大增加了测试和开发的重叠时间，测试更充分，测试和开发的迭代效率更高，产品质量控制得更好；而且bug提交到qa上，也会一并附上build版本号，方便技术还原现场，更快地解决bug；
每日构建使得技术必须对每天自己输出的代码负责，一旦每日build失败，必须检查原因，并纠正不可再犯，以避免再次build失败，这样能非常有效地提高所提交代码的质量，减少bug的产生，加快开发效率；

虽然搭建并维护daily build，需要比较大的工作量，但绝对物有所值。

——————————————————————————————————————————–
参考：杭院项目管理部《项目管理白皮书》

源地址：http://uedc.163.com/8142.html

移动产品设计之设计

Sat, 08 Oct 2011 23:17:17 +0800

按照我的理解，场景、任务、用户可以称之为设计的三要素，每一个设计实际上都是试图去帮助用户在某个场景下完成某个任务的。同样的设计遇到不一样的场景就会有不一样的方式，从Web设计到移动产品设计亦然。

曾经有个朋友问我，从Web设计到移动产品设计你感觉最大的差异点是什么？我觉得，最大的差异点在于用户使用场景的变化，场景的变化引发了交互方式巨大的变化，从而也使得信息呈现方式有所不同，再加上硬件设备的差异，最终使得2者千差万别了。所以，移动产品设计之设计应该首先从用户的使用场景出发，同时考虑用户的硬件设备差异，综合以上2点去帮助用户完成某个任务。

当然，从生态系统的角度而言，移动生态系统也是迥异与互联网生态圈的。移动生态系统可想象成拥有许多层的系统，每一层都依赖于其他层，他们相互依存构成了无缝的端到端的体验。

运营商在最底层，他们是移动生态系统正常运作的基础，他们负责基础设施建设并维护与用户的关系；运营商运营着无线网络，而网络能力同时也受制于设备与与天线的类型；而由于不同设备对工业标准解释的不同直接早就了移动生态系统最大的挑战，移动设备碎片化；软件与服务要在设备上运行就需要有平台，移动平台主要分为授权平台、专有平台、开源平台，其中我们熟知的有Java ME、iphone、Balckberry、android等；移动平台通常是与他所运行的操作系统绑定在一起的，比如symbain、Windows Mobile、ios、android；而开发者通常能够访问到的就是这些平台的应用程序框架并以不同的语言来开发应用程序。

在移动产品设计的过程中我们也会经常有意无意的涉及到生态系统的某个层面，而哪怕用户只想在移动端做极其简单的事情比如“访问我的博客”，都必须通过这些层，所以，这导致整个的移动环境十分复杂，整个移动产品设计需要具备的能力与素质也相对更甚。

移动产品设计之使用场景的变化

（图片来源：Tapworthy）

没有了舒服的人体工程学座椅，只有拥挤的车厢或者顶着烈日的街头；没有了灵活的鼠标和舒服的键盘，只有晃动的屏幕和方寸间的按钮；你不再是一边放着歌一边刷着网页，而是希望能够迅速的找到你想去的那个店铺；你也不会成天挂在线上，而是会经常担心这个月的流量是不是又超标了……

这种场景的变化呈现给我们的是用户在移动设备上不断的碎片时间的消耗，用户越来越没有耐心。这看起来挺糟糕的，可实际上也是好事，这种使用场景的变化会迫使你放弃做类似Web端大而全的产品设计的想法。相反的，你会聚焦去解决用户在某一个碎片时间段里的需求。这种更聚焦的“单核思维”需要贯穿与整个移动产品设计中（详见：更多的限制，更简单的设计）。

移动产品设计之设备的变化

你的用户会使用什么样的设备来访问你的应用？这个问题是每个设计师在设计最初需要思考的。你的用户所使用的设备需要从多个维度去考虑，如操作系统、使用的网络环境、设备的分辨率等，这些信息都必须被综合起来考虑，最终运用到产品设计中去。对没错，这就是移动产品设计中臭名昭著但又很好玩的“适配”。2个同时使用android手机的人在使用同样一个应用程序的时候可能体验是天堂与地狱的差别，而即使同样都使用iphone但是在不同的网络环境下体验也不一样。这些，都需要去考虑…..

当然，这里有另外一个问题我觉得可以探讨一下，那就是不同平台直接的设计借鉴与移植。我的感觉是ios与android完全可以按照同样的一套架构去设计，只是在具体的交互方式上按照不同平台的特性去做就OK。比如同样是删除在ios上是左右滑动在android上是长按。

另外，这种硬件设备的变化也是移动产品设计与Web产品设计一个很大的差异。在移动产品设计上，一定要充分利用设备本身去完成设计。相对Web产品而言，移动设备自身提供了很多硬件能力，比如光感、磁阻、陀螺仪、….对这些能力的运用是移动产品设计的起点（详见：移动产品设计之硬件能力）。

移动产品设计之交互方式的变化

整个移动产品的的交互过程可以概括为，用户触发某个任务跟客户端发生交互，客户端将该任务反馈给服务端，服务端向后端请求数据并做数据拼接同时反馈结果给客户端，客户端将最终结果展现给用户。当然，某些复杂的任务实际上需要客户端向服务端并发数次的请求。

考虑与服务器端的交互并不是移动产品设计所独有的，但是却是移动产品设计过程中最需要设计师去“设计”的交互。因为这关乎3个事情，对用户流量的消耗和用户操作的流畅性，同时也是对客户端性能的一个考验。这是我认为目前移动产品设计的用户体验最重要最根本的地方，保证客户端性能的稳定性，用户可以在低网速条件下顺畅的操作，同时尽可能的帮助用户节省流量，而UI层面的体验问题反倒是其次的。twitter和foursquare不论是在ios和android甚至symbain上都没有花哨的界面，但是他们仍然是我心目中当之无愧的最优秀应用。

同时，从键盘机到触屏机再到多点触控甚至于目前的语音助理，我们发现移动端的人机交互方式在不断的演进。于此同时我们也发现，越是高端的移动设备用户的“惰性”反而越强，用户期望能够使用更低成本的交互更快速的完成任务，这也是移动产品设计必须要面对同时也是移动产品设计师最能有成就感的地方。

最后，单就手机端产品设计而言，对于移动平台的选择

iphone这2年的势头太猛烈了，加之推广渠道单一产业链相对完整，所以iphone客户端的设计、推广都很容易见效且效果巨大；android太过开放，直接结果就是渠道纷繁复杂但无一能处把控之势，所以推广费力且收效甚微，小团队可以在开辟完ios战场并有成效之后果断跟进；symbian？如果可以，迅速放弃吧！WP7势头可观，但目前不太适合小队伍入场，大团队可先做储备。

我眼中的敏捷设计

Tue, 20 Sep 2011 16:17:24 +0800

2001年，许多公司的软件团队陷入不断增长的流程困境，为了解决这个问题，这个领域中最优秀的experts一起概括出了一些全新的价值观和原则，从而可以让软件开发团队具有快速工作、响应变化能力，他们自称为敏捷联盟。敏捷开发过程的方法很多，包括Scrum, eXtreme Programming, Feature Driven Development, Adaptive Software Development等等。目前，我所在的公司内部也有很多团队开始启用Scrum的开发流程，力图改变瀑布式开发模型的诸多弊端。作为Run了3年该流程的team，我们团队在不断学习和总结中得到了进步，我也希望可以从设计的角度来分享一些敏捷开发流程中快速迭代设计的心得。

Process 流程

这是一个高速变化的时代，无论是产品的更新还是技术的进化，同时变幻莫测的需求对传统软件开发模式造成了极大的冲击。当用户需求不断变化造成软件开发目标的不断更换，传统的设计方式会举步维艰，从而造成了软件的滞后，总是无法贴近用户的实时需求。快速迭代设计的特点是：先设计出稿，再不断改进。白鸦在 2011中国交互设计体验日上分享到：“怎么做都是错的。唯有迭代的速度，才能取胜。” 可见，快速迭代的要求，无论是对研发还是设计，都已迫在眉睫。

整个快速迭代设计流程分为5个阶段：

* Iteration-1

前期准备阶段，团队很容易就各类需求该放哪些进入Sprint backlog发生讨论，设计师主要参与PO(Product Owner)/PM组织的用户需求讨论，对需求优先级排序，解读一些用户潜在需求并转化成为产品功能需求，毕竟相比他们，设计师更加懂得产品细节。同时，设计师可以同步展开用户研究的工作，了解Persona的主要工作流和Goal。

* Iteration 0

与每个项目开始之前设定Sprint 0相同，Sprint里也有一个叫Iteration 0的阶段，包括设计开工之前的验证与出具设计方案。通过与开发团队的沟通来验证设计方向与设计方案的可行性，可以创建一些信息流图与内容结构，做好坚实的设计架构。同时，在用户需求被解读成为功能列表后，利用纸片、PPT、Balsamiq等工具创建快速原型，最好在这个阶段让研发团队介入，对设计原型进行评估。然后设计师根据快速原型，负责设计其实现方式，通常会有几个解决方案。在Scrum团队内部与开发测试人员反复讨论权衡后，选出最优方案。这个阶段设计师的交付物为交互线框图、低保真模型等简单设计文档。

* Iterations

设计不断迭代的阶段，因为我们假设改阶段用户需求已经确定，所以主要是基于设计方案的迭代，协同开发实现的进度，将设计不断修正至最优。正是这种快速的模式让设计师能在一个可以体验的原型上验证设计，从而改进设计。与流行的测试驱动开发（TDD）类似，我们也可以采用测试驱动设计（Test Driven Design,详见http://www.agiledata.org/essays/tdd.html）的方式。QA要对用户的背景和工作模式比较熟悉，协同设计师一起敲定User Story，撰写Real User Test Scenarios，并根据测试结果优化设计。设计师与开发团队成员一并进行Usability Testing，以便在早期消除可用性缺陷，减轻后期维护成本。

* Release

作为design release的阶段，前面的工作主要内容是确定功能的主要逻辑与工作流，这个时期，我们可以在优使性（Usability）上有所提升，做好Final Usability Testing，确认没太大疏漏，再将其发布出去。不同于QA的最终验收测试，这里的可用性测试需要从用户的角度去“使用”产品，不是去找功能的缺陷，而是从优使性方面看是否顺手，是否符合用户心智模型，是否高效完成用户目标。

* Production

设计发布过后，为了适应不断更新和快速迭代的需要，设计师在这个时期的工作重心从偏用研设计转移到偏运营维护的方面来，一方面收集一些用户反馈和wishlist，改进之前的不足；另外一方面为了产品的下一个迭代更新做好规划，方便产品的发展和扩充。

整个流程有两个迭代循环：
1.Requirements Iteration
这个迭代循环贯穿于整个敏捷设计流程。用户需求随着时间推移不断更新，整个设计流程的迭代。根据以用户为中心的设计思想，当用户的需求发生变化时，在设计流程中要及时响应，做出调整变化。
2.Solution Iteration
这个迭代循环主要指Iterations阶段，用户需求相对确定，设计方案的不断优化更新。当需求基本确定后，设计师需要配合开发团队不断优化设计思路，提供更优的设计解决方案。

特别需要注意的是，前面两个阶段（Iteration -1, Iteration 0），应该早于当前研发的Sprint N一个周期（Sprint N-1）进行。进入当前的Sprint工作周期，完成第一个迭代设计后，研发团队可以开始该部分内容的开发测试，与设计师不断互动推动迭代。在Sprint N的末期，设计师完成当前Sprint的基本设计工作后，开始收集前面Sprints release内容的反馈。团队不需要提前太多进行设计，要保持需求的最新update，主要依赖测试结果作为支撑，不断持续改进优化设计，以便每次迭代结束后产出物都最适合当前迭代的需求。

Rules 原则

快速迭代设计的一些原则：

* 验证可行性的必要

完美的敏捷思想是团队中的每个人都是全才，大家都可以design，coding，testing。不过这样的团队不多，全才的混合有时候更容易造成管理混乱，相反，专才的合理搭配能产生更好的效果。所以，如果你不会写代码，一定要在设计早期拉上开发人员，坐在一起慢慢探讨设计可行性，用代码验证原型之后，再确定方案。

* 测试用例验证设计的重要性

根据测试驱动设计的理念，设计师与QA协同合作，利用早期测试结果驱动设计更新，比设计师长期独自酝酿出的详细设计文档更有用。行不行，利用草图或者低保真原型让QA去测测看就知道。Scrum鼓励充分沟通与互动，这个时候QA的测试用例能发现很多设计缺陷和遗漏。TDD如下图所示：

* 注重团队设计

与瀑布模型的单打独斗不同，快速迭代设计更推崇团队设计，由设计师主导，把握设计框架，整个团队给出解决方案。一些design scenario和workflow的归纳，即使经验丰富的设计师，也不如团队智慧来的全面，当然，除非你是乔帮主，使用导演中心论的设计流程。另外，团队设计的好处还可以减轻设计师的负担与压力，一起承担产品兴亡的重任比一个人承担要安全可靠的多。

* 设计不多不少，恰好就行

兵贵神速，指的就是以快为王。特别是在快速迭代设计中，你不必在你的原型或草图中事无巨细的列出所有可能，完美的概念在这里是不适用的，甚至你不需要完成设计的整个部分，只要把关键模块讲清楚了，开发与测试理解了，就足够。想想那些精美的设计文档中无数看上去perfect的图片和排版，最后真的有人在乎吗？只要你在迭代开发流程中能于脑海中攫取所有细节并传递给团队，不要文档都可以。无需太具体，思考那些真正有价值的地方。

* 写好User Story

User Story是在Agile开发流程中从用户角度对系统的某个功能模块进行的简短描述，它包含了目标用户(不同角色)、功能需要（可以做什么）以及其创造的价值（实现目的）。它可以是：
1.一个用户需求
2.产品功能的描述
3.用来计划和追踪任务的工具
4.团队沟通的桥梁
通常我们把一个User Story按照以下格式写在即时贴上：

以第一个句型为例：
As a _ I would like _ so that _
作为（某个角色)，我希望可以（做什么），以达到（什么目的）
User Story照理应该是由PO写，不过有些团队（比如我们:D）是由设计师来完成，同时在即时贴上标注预估完成时间（我们团队采用了Story Point这样一种估算方法，这里不赘述）和优先级别，以便开发团队根据它们来形成Sprint Backlog。

* 任务量

不同的功能模块其工作量也不尽相同，我们可以按以下三种类型划分:
1. Large
一般来说每个User Story都需要在一个Sprint内完成，避免太大而跨越几个Sprint。如果出现太大的User Story导致一个Sprint塞不下，则需要将User Story分解，这个Sprint完成一部分，但是不release，只是demo给PO/PM，余下的在接下来的Sprint里完成。
2. Normal
按正常流程进行快速迭代设计。
3. Mini
JDI (Just Do It), 一些小功能的实现无需文档，任何沟通方式都可以用来传达你的设计思路，然后交由开发去实现。

* 关于文档

原本瀑布开发模式下设计师的唯一交付物Specification，在快速迭代设计中已经不是那么重要，因为快速变化的用户需求让设计节奏加速，不断更新维护Specification成本太高。用户是为你设计出的产品或者功能付款，而不是你的设计文档，所以传递设计思想才是主要目的，PPT、Visio等Wireframe或者email、meeting notes等记录都可以作为设计参照。
对于文档，我们一般遵循如下原则：
-尽可能在文档中简单的描述需求、分析结果、信息架构和设计细节，只要它们恰好满足PO的要求即可。
-如果该Scenario的逻辑足够复杂，那么请毫不犹豫的用文档详细的描述，以开发团队恰好能充分理解为宜。
-文档的简繁程度需要经过几个Sprint的迭代，才能找到最合适的level。

* 保持一直设计

设计对产品来说如此重要，特别是在敏捷开发流程中，没有一个专门的设计阶段(There is no design phase)，整个流程都伴随的设计。从前期纸片概念，白板框架，用户场景测试，到具体细节代码实现，终极用户测试，都离不开设计的跟随。这不再是那个只需要在早期完成设计就弃之不管的模式，他要求你每天都不停的参加讨论参入迭代参与设计。

Epilogue 后记

我们团队面对的是一款由公司早期元老打造的工程领域软件，它的用户基数庞大，它的地位曾经显赫。然而它的功能逐渐老化，模块架构也相对固化，开发团队很难对整个系统进行改动，因为整个软件架构已经固定，任何大的改动都是牵一发而动全身，不但会造成许多与改动处无关的环节出现问题，莫名其妙的regression defect也让QA措手不及。一些设计改进都必须得在之前设计的基础上进行调整，力求一致性，很难加入全新的交互模式和UI风格。同时，正是由于产品功能没有大幅度的更新，瀑布模式比较擅长的低风险复杂功能开发已经无法满足用户需求的小快灵。因此，我们目前所使用的敏捷设计流程尽管无法跟全新开发的产品一样自由，只是在大框架的制约下进行功能的迭代更新，但也取得了不错的效果，3年做下来完成了许多小功能的快速成功发布，提升了大家对于Scrum流程继续使用的信心，致力于建立一个持续的可改进的快速响应团队。本文所提及的流程并不适用所有情况，希望大家各取所需，保留对自己有价值的部分，摒弃不适合的。

参考：

http://www.agilemodeling.com/

http://blog.rexsong.com/?p=2365

使用正确的图片来影响人们做出购买决定

Fri, 26 Aug 2011 17:04:48 +0800

你喜欢在博客文章中使用图片吗？是的，如果不是很麻烦的话，相信大家都不会介意放上几张漂亮的图片来点缀一下内容的，不过你的图片可能会导致下面的两种后果：

图片会帮助你实现你的业务目标，也可能会伤害你的转换率。

听上去很简单，不过除非你能够真正了解图片是如何来影响人们做出购买决定的，图片的一些细微差别就可能给你的转换率带来截然不同的效果。

因此，从今天开始，不要再盲目地添加一些没有必要的装饰图片到你的网站了！

为什么你不该使用图片来做装饰

如果你经常写销售文案或者Landing Page，你可能听过这样的话：“一字值千金，一图抵千字”

这绝对是一个真理……前提是你使用了正确的图片。

错误的图片通常会让人们觉得混乱，然后很容易地被人所忽略。

“是什么让一副图片恰到好处，与内容相得益彰？”

先看下面的测试：

如果你只是从Flickr或者其他流行的图片网站照搬一些图片到你的网站，你很可能就放置了错误的图片。

没错，你或许觉得它能够吸引人们的注意，但是除非图片直接与你所谈论的东西相关，否则访客就很可能会忽略它。

举例来说，T-Mobile 在他们的网站上突出显示他们的代言人凯瑟琳泽塔 – 琼斯，也许她是有史以来拿个电话放在耳边的最美的女人，但对于一个潜在的电话购买客户来说，Who Cares！

从用户界面工程上来讲，

“有一个年长的顾客，他有兴趣购买一个按键稍大，更容易按键操作的手机，当他不能在网站上任何图片中辨别手机按键的大小的时候，他感觉到了些许失意。而当他看到凯瑟琳泽塔 – 琼斯拿着一个他喜欢的电话放在耳边的巨幅广告banner时，他被彻底激怒了。这名顾客告诉我说：“她的确是个很漂亮的女人，不过我只不过是想看看按键有多大而已，这和她的咪咪大不大一根毛的关系都没有，伤不起，伤不起啊！”

为什么顾客会有这样的感觉？

凯瑟琳泽塔 – 琼斯被用做了手机的装饰。没错，她或许真的很能吸引人们注意，但那能对T-Mobile的电话销售起到什么帮助吗？人们希望看到电话看上去到底怎么样，而不是哪一个明星拿着它。

在使用图片的时候确保你有一个需要这样做的理由

我们有许多理由在我们的网站或者博客上使用图片，当我们使用图片的时候，确保你并不仅仅因为“它看上去还不错”而使用图片。

什么才是使用图片的真正理由？

看看下面的三个实例：

#1: 当你销售产品时，使用产品的图片

你可能会觉得这是个谁都明白的常识，不知道大家是否曾经浏览过房地产网站？

几乎没有一个房屋销售，中介网站为他们所销售／代理的房产提供足够详细的图片。

为什么呢？我也不知道，知道更让我觉得哭笑不得的是什么吗？

几年前我准备从网上找一个出租屋，我基本很难找到哪些我感兴趣的房子的照片，但是房产经纪的照片道是贴得到处都是。

听我说哥们儿：我只是TMD想看看厨房长什么样子而已，如果你不想做我的厨娘或者孩子的奶妈，鬼才想看到你长什么样子！

在我们继续之前，我有一个忠告:

在准备使用产品图片的时候，确保你的图片能够突出产品的主要特色。为了说明这一点，我们来看看来自Jakob Nielsen的这个电子商务案例：

在Pottery barn的网站有一个书柜的分类页面，访客花费大量的时间来查看每个书柜的缩略图。而在 Amazon.com，当访客查看电视的分类页的时候，他们则花费时间来阅读电视的描述文字，忽略了产品图片。

为什么会这样呢？书柜的产品照片能够有效的帮助人们理解他们正在准备购买的东西，而电视机的产品图片看上去都差不多，这就是人们为何会忽略电视产品图片的原因。

现在我们来谈谈，如果你并没有运营一个很大的电子商务网站，而仅仅销售一个产品，情况又是怎样？

我们来参考一下MacBook Air的营销案例：

你知道为什么上面这张图片是个天才吗？

MacBook Air 的主要卖点不在运行速度，而在于它的大小轻薄。

除了把MacBook Air从信封中轻轻地拖出来，还有什么更好的办法来展示该产品的主要特色吗？

没有过多的谈论产品本身，仅仅告诉人们它有多小，而那正是为什么人们购买它的的理由。

现在问一问你自己：

在你销售一个产品的时候，什么才是让人们情愿为产品掏钱的主要理由？

一旦你得到了答案，把你的答案放到一张图片中去……，也许是几张图片，然后，你将会发现更多的访问者被转化为了你的顾客。

#2: 在短行文字旁使用图片

人们喜欢较短的文字行长度，因为短行很少会被图片挤压而换行，而且更容易阅读。

实际上，人们阅读较长的行（大约每行100个字符）速度会比阅读短行的速度快，因为有更少的眼球运动。

这也是我在QuanZhiBaBa.com上的图片运用策略。通常我会在博客文章中采用200像素宽度的图片，让我的文字行长度变得更短，方便读者开始阅读我的文章内容。

通常在3到5个语句之后，我的行长度会变长。通常采用这种策略的文章更容易被读完并被分享到社会化网络。

为了充分利用这一战术的优点，需要你弄清楚如何才能缩短你的行长度到40－60个字符，并且使用一张图片来填补剩余的空间。

如果你希望说服人们来购买你的产品或订阅你的博客，你需要让他们了解你提供了什么给他们，而这就是我为什么喜欢采用本图片策略的原因。并不限于博客文章，在Landing Page的设计中运用该策略也是非常有价值的。

#3: 使用图片引导访问者的注意力

不管你聪明还是愚笨，即使你天生就不喜欢扎堆，不喜欢随大流，你觉得你并不是一个好奇心重的人。但是，人在很多时候总是无法抗拒某些特别的东西，就像我们下面要提到的3种情形：

1. 人们无法抗拒跟随别人的目光

2. 人们无法抗拒一个箭头所指的方向

3. 人们无法抗拒跟随任何事物的“视线”

好奇是我们的天性，如果某人正在注视一样东西，我们会不自觉的也看过去试图找到一个答案。如果一个箭头指向某个方向，我们也想找出答案。最后，物体往往也有一个“视线”，有着与箭头一般的作用，这些东西都会指引我们去寻找答案，也许你并非有意识的去跟随，但实际上我们内心深处总是藏着一个 “WHY？”

我们来看看Chemistry.com的这个Landing Page：

你认为当人们来到这个Landing Page的时候会注意哪里？

如果你猜是注册表单，那你绝对是正确的。

另外一个例子，Usable World做的一个测试也显示了类似的结果：

很酷吧？看到人们是如何跟随宝宝视线的吗？人们也注意到了底部的图形，因为宝宝的指向第二个图形的下巴起到了与箭头相似的作用。

( 有兴趣可以去Usable World的网站看看，他们有很多宝宝图片引导注意力的例子).

箭头的作用更是不言自明，如果你在你的网页放置一个色彩鲜明的箭头，指向一个特定的点，人们往往会注视哪里。

注意：通常只有比较积进的Affiliate Marketer才会使用箭头，我们最好还是采用“视线”这样更为微妙的箭吧。

究竟这些图片是如何帮助我们提高转换率的呢？

我经常看见许多博客上使用人物图片，让后让人们跟随图片上人物的目光离开他们的网站。

这实在不是一个明智的选择。如果你有一个人物图片，请让人物的目光指向你需要人们注意的地方，否则，你很可能会把访问者引导到他们的计算机屏幕之外。

还有一个额外的好处：

你可能认为你不需要指引人们去注视某个地方，因为在你的网页上一切都非常明显。

让我来告诉你：人们用他们的条件反射神经来浏览网页，准确的说应该是扫描网页，这很容易让他们错过那些对你的商业目标来讲尤其重要的那些内容。

你应该使用一切你能够用到的武器，确保他们注意到你最希望让他们看到的东西。

为什么你需要使用真实的人物图片（而不是卡通）

如果你能看到本文的这里，恭喜你，对于靠网站吃饭的人来说，你很可能已经成为这群人中最聪明的1％。

不过在这里我还有一个最后的技巧给你：

无论你作为一个公司，自由职业者，或是任何其他形式的生意来运营一个网站的时候，你的网站应该总是包括一张你和你的团队的图片。

为什么？

人们喜欢与人联系……而不是不露脸的公司或者企业

最近我在我的互联网营销博客做了一个眼球轨迹测试，我发现访问者花费了大量的时间在我的网站页脚部分。

没错，他们在寻求他们还能在我的网站做什么，如果我有一个精彩的About Me页面，那么在这里放上一张靓照和简单介绍，或者再加上一个邮件订阅表单会是非常不错的选择。

在网站使用真实的照片还有一个好处：

人们喜欢和他们认识的，喜欢的，信任的人做生意。Jakob Nielson在文章“博客的十大可用性设计错误”一文中提到，如果你不晒出你的靓照，人们通常会往坏的方面去揣测为什么你不愿露脸的原因，并且会不自觉的假设你就是一个不值得信任的人。

你会向一个戴着面具的人买东西吗？我是不会的。因此，使用真实的相片来建立你的信誉，借此来提高转换率。

总结

我们会舍得花费大量的时间来写博客文章和销售文案，现在腾出一点时间来选择正确的图片吧，那值得我们去做。如果你能找到那张完美的图片，你就有机会体验转换率爆炸的快感。

现在，你是怎么想的呢？

你在网站上是怎么使用图片的？

源地址：http://quanzhibaba.com/archives/552

抑制越俎代庖的冲动

Fri, 19 Aug 2011 14:22:50 +0800

曾以为，诸如朝三暮四、邯郸学步、削足适履之类的成语都只适合用来描述动物的智商。凭着理性的大脑，人类绝不会犯这些低级错误。但离开学校真正接触现实的社会后，各种经历时常让我感慨，这些老祖宗凝练出的精华之所以能够历久弥新，正是因为它们源于你我身边真实的生活。

最近常浮现在脑中的词是“越俎代庖”，意思是主持祭祀的人跨过礼器去替厨师操办酒席，常用来比喻超出自己的职责范围去干涉别人管辖的事。在现代社会，一个人不可能掌握所有技术。所以最好的方法是进行社会分工，每个人只需要精通一种技术，再与其他人协作即可。然而这种分工配合的模式过于理想化。因为现实生活中，团队成员往往会不满足于份内的事儿，还想对他人施加影响力。于是乎，内耗重重。

个体在团队中虽然只承担部分职责，但或多或少会对合作者的工作成果有所预期。当别人做出来的活儿与自己的预期有偏差时，便会心存不满，不吐不快。产品设计师觉得交互画的线框图与梦想中的产品差太多；交互觉得产品提供的需求不靠谱，只考虑商业需求和KPI；开发觉得视觉提供的效果完全是异想天开，在渲染时极其消耗资源。

互不信任的情绪在升级，各位的手也越伸越长。产品提需求的时候直接带上了线框图，只期望交互把控件对整齐；交互奋力抵制不靠谱的需求，只磨嘴皮子就是不配合；开发磨磨蹭蹭不想写太费脑子的算法。每个人都想让产品变成自己期望的那样，去影响并不属于自己专长的领域，挤压别人的决策。合作的美梦为什么会变成内耗的噩梦呢？

原因在于合作的方式不靠谱。公司里常见的合作方式是瀑布式的。各个职位的人组成了一条流水线，一个环节的任务完成了，就输出交付物，给下一个环节的人继续加工。

理想情况下，每个环节的人应先向下游交付一份“效果”描述文档，下游的合作者再施展自己的才华，为这些“效果”提供“解决方案”。然而实际情况则是下游抱怨“效果”不靠谱，上游抱怨“解决方案”不达标。信心在一次次失望中崩溃，于是下一次再描述“效果”时就想夹带私活，把自己偏爱的“解决方案”直接灌输给合作方。然而，这种头痛医头的方法是非常低效、破坏分工机制且打击合作伙伴积极性的，只治标不治本。

要想消除这些内耗，抑制越俎代庖的冲动，需要优化流水线式的配合方式：

1、下游应当提前参与上游的决策：

上游应该在对效果有初步想法时就邀请下游参与讨论，看是否存在极其不靠谱的点，以免自己一个人闷头走得太远。当然下游也应明白此时自己只是参谋，只有建议权，不要表现得过于强势。通过这种方式，上游可以了解合作方的能力范围和工作习惯，下游也能参与决策，对最终产品有了熟悉感，更像是一起孕育的孩子，而非仅仅是个乙方。

2、向下游提供“效果”图时，也要交代一下它的背景

在交付“效果”文档时，可以也附带说明一下为什么要这么做。知其所以然，可以让下游对“效果图”有更深刻的了解，也能在思考“解决方案”时有更灵活的发挥空间。

3、交付文档要翔实地定义“效果”的所有细节，表述方式要利于下游理解

个体对自己脑袋里的想法是很清楚的，所以当文档中的细节存在纰漏时不太在意。比如，“这个图标是临时用用的”、“点这里时是要判断一下再跳转的”。但对于阅读这份文档的合作者来说，则像是到了初到陌生地的游客，会把地图上每一个像素都奉为真理。与其在合作者做好活儿之后大呼“这完全不是我要的效果”，不如自己认真一点，保证每一个传递给下游的细节都是正确的。连自己都懒得说清楚的点，又怎么要求别人来猜你到底想要什么效果呢？

越俎代庖的冲动源于对他人能力的不信任。与其专制地把别人控制得死死的，不如尽早倾听别人的意见，并尽责地管好自己的摊子。你对别人要求得越多，给别人的喘息空间就越少，收获的惊喜也越少。

源地址：http://goo.gl/lr78E

产品，你理解对了吗？

Fri, 19 Aug 2011 14:16:22 +0800

Marty Cagan发表于2010年11月23日

译者：姜沈励/ 审校：唐丰能林航

在大众消费品行业，当你提到“产品”一词时，大部分人脑中会浮现出一个非常清晰的实体，例如一块肥皂或是一把剃须刀。但在互联网行业，“产品”一词就显得格外抽象：首先，互联网上的产品通常是指软件，而不是实物；其次，这些软件通常并不安装在你的电脑里，而是直接运行在远端服务器上，甚至是运行在抽象的“云”里。

因此，大部分网络公司由于网站体型过于庞大，需要我们人为地将其拆分成许多小“产品”。大型网络公司的网站一般被拆分成许多（通常是几十个）小“产品”，这种组成结构只是为了适应内部组织需求（organizational needs），而普通用户是察觉不到的。

在早期的文章中我提到过把大型网站拆分成多个可管理模块的关键点。现在，我想谈谈对产品的看法：当我们提到“产品”时，我们到底指的什么？这里的产品可以指整个网站也可以指其中一个模块。

我觉得今天讨论的对象相当重要。我认为，大部分团队只是凭直觉工作他们定义产品和组织团队的方式不合理，直接造成了好产品“难产”。在采访过这类团队后，我觉得，让大家意识到什么是产品，也许能改善这种现状。

我这样定义典型的网络公司产品：

产品 = 用户的整体体验 = 功能 + 设计 + 盈利 + 内容

- 功能是指产品可以干什么。

- 设计是指交互设计、视觉设计和工业设计（对物理设备而言）。

- 盈利是指盈利模式。可能是各种形式的广告、捐赠或者交易。

- 内容可以是自己原创的、由用户提供的，或者两者相结合。

虽然看似简单，没有火箭制造技术那么高深神秘，但对我来说，还是存在两个关键点：

1.产品的外观和功能不可分割，它们应该被视为一个整体。

2.网站的产品负责人必须平衡好功能、设计、内容与盈利之间的关系。

例如：

-如果设计师不是和产品经理、工程师工作在同一战线，那么每个人的工作都不好开展。

-如果强行将网站员工划分为两个团队，一个团队负责开发为用户提供价值的产品；另一团队负责营销推广，你会发现很难优化整体的用户体验，甚至会引起两方的利益冲突。

-如果只专注于功能开发，而忽略了内容的创造，你就无缘感受整合带来的好处。

提示：

-在一个电子商务中，对“产品”的定义除了上述四点外，还包括订单履行（fulfillment)、商品包装、客户服务、退换货策略。并且，我们常常把网站上出售的货物叫做“商品”，避免和这里所提到的“产品”相混淆。

-在传媒公司，编辑就是内容的缔造者，而内容是产品的一个组成部分。

-与此同时，公司还需要有专业化的产品团队（具体内容见后续的文章），并且团队的“性能”通过产品积分卡（Product Scorecard，具体内容见后续的文章）来衡量。

作为互联网行业的产品经理、设计师或者开发者，如果你能用系统的眼光来看待产品功能、设计、盈利和内容，必将受益匪浅。

原文链接：http://www.svpg.com/defining-product/

本文节选自《启示录：打造用户喜爱的产品》一书作者的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。

源地址：http://blog.sina.com.cn/s/blog_73969ace0100tdjo.html

Show me more

Thu, 11 Aug 2011 05:22:37 +0800

Today, we’re rolling out two new features on Twitter.com that help you discover more on Twitter. You can now see when someone favorites or retweets one of your Tweets. You can also learn which Tweets are most interesting and inspiring to the people you follow.

The first new feature offers a simple way to see what's happening on Twitter in relation to you. Just click on the new tab with your @username, and you’ll be able to see which of your Tweets are Favorites, plus the latest Retweets (of your Tweets), Tweets directed to you, and your new Followers.

The other new feature is the Activity tab. It provides a rich new source of discovery by highlighting the latest Favorites, Retweets, and Follows from the people you follow on Twitter – all in one place. It’s easier than ever to explore Twitter, connect with people, and discover what’s happening around the world.

&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp

FedEx, GE和Google的文化在打架

Tue, 26 Jul 2011 11:39:59 +0800

昨天和一位朋友聊天，提及几家比较了解的公司的文化，觉得把这三家公司放在一起对比很有意思，这三家有着迥异文化，却都非常成功的公司是FedEx，通用电气，和Google。

FedEx的创始人Smith在越战的三年奠定了之后他创建的公司的文化，他理解FedEx的核心是第一线的装卸工人，他深刻理解社会中劳动阶层的需要。他的信条的第一项就是“人”，他把人放在最重要的地位，像对待战友一样的对待团队成员。因为一个人不够优秀而解雇，就像战场上扔下受伤的战友一样不可以接受。这种兄弟连一样的文化对于FedEx这样的靠大量忠诚的员工支撑的公司来说，至关重要。于此类似的，我能联想到，Starbucks也是这样的文化（第一线的店员被足够尊重，西雅图的总部叫做Global Service Center，用来服务全球的门店），还有中国的海底捞都有类似的以人为本的哲学。对于第一线的员工几乎等同于产品和服务的行业，这种文化行得通，而且所向披靡。

通用电器是另外一种风格，或许是FedEx的反面。它强悍的末位淘汰制，保证就算所有的人都足够优秀，都完成了指标，也必须有一部分的人离开公司。（对于FedEx的人来说，这简直是恶魔公司）。不仅仅末位淘汰，如果不是所在行业的第一二名，这个部门就会被解散。对于通用这样既不是靠绝对的技术创新，也不是靠第一线面对用户的店员。，而是通过不断的收购，管理，壮大或者关闭的过程，这种文化获得了在商业领域获得了巨大的成功。

Google又是第三种极端。它既不末位淘汰，也不对于员工有过多的管理，属于散养型公司，但是它的进人的严格程度让人不能理解，让人笑掉大牙，甚至让人发指。Google的秘书也需要全球面试的故事就是这种严格进人的最典型代表。Google这种不靠门店，不靠第一线员工面对客户，也不靠末位淘汰的方式保持人员的优秀，却是保证创新的土壤的方式发展的公司，这种文化也适用于这个行业。很多成功的高科技公司，在这个行业里面，也基本上是这种思路。

三个完全不同的公司，截然不同的文化。但有一点是共通的，就是他们的文化服务于它们所在的行业。不同的行业需要不同的文化。适者，生存。

Oxygen's Shared Items

今夜酒店特价（一）：酒店业的奥特莱斯折扣商店

关于项目管理的一点体会

移动产品设计之设计

我眼中的敏捷设计

推荐几个简单的协作工具

使用正确的图片来影响人们做出购买决定

为什么你不该使用图片来做装饰

在使用图片的时候确保你有一个需要这样做的理由

#1: 当你销售产品时，使用产品的图片

#2: 在短行文字旁使用图片

#3: 使用图片引导访问者的注意力

为什么你需要使用真实的人物图片（而不是卡通）

总结

抑制越俎代庖的冲动

产品，你理解对了吗？

Show me more

FedEx, GE和Google的文化在打架