• 闲聊邀请
• 邀请模式有哪些
• 设置邀请机制的目的
• 设计一个邀请的几个元素
• 案例

闲聊邀请机制
1. 你收到的线下邀请实例

• 哪类产品？
• 收到邀请的方式？
• 对你是否有足够的吸引力？
• 如何处理？
• 是否包含再传播机制，是否乐意再传播？

2.你收到的线上邀请实例

邀请模式有哪些
1. 说说线下的邀请模式

• 当面邀请
• 安利模式
• 免费派送餐巾纸上的广告暗含的间接邀请
• 请柬和请帖

2. 咱们再回到互联网上来

• 通过邮件邀请
• 通过IM、短消息邀请
• 以上实质上是传递邀请链接

邀请机制的目的

• 进行的口碑传播
• 造成稀缺感，加大产品吸引力
• 实现好友初始化
• 小白鼠测试
• 系统资源有限，只能逐步开放

设计一个邀请的几个元素

• 有足够好的产品（或是传播载体）
• 找到最佳的传播种子
• 找到适当的传播通道
• 实现种子传播，并扩展到自传播
• ……

案例

• 酒吧运用美女QQ签名广告的邀请
• Google wave
• HostMonsrer的CPS模式邀请
• kaixin001的邀请

《邀请机制与模式》这个话题本身不是一个纯的设计话题，它更多是属于传播、营销、市场等领域的范畴。我相信Google wave邀请机制的策划者应该不是一个产品经理（或是设计师），真正的策划人应该会是营销、市场内完成的。当然产品经理会从产品角度提出反馈：比如Wave的邀请人数是8而不是50，或者说明他们希望wave邀请周期拉长，或者说明wave系统容纳人数能力可能初期有限，或者说明他们希望对wave做更多的用户反馈进而迭代入下一环的设计。不管怎么说，越来越多新产品上市等方面的市场行为在通过邀请模式而不是传统媒体广告的形式，已经在证明社会化营销不可阻挡之势已经来临。

接着说一说如何在Web设计中如何很好的实现以用户为中心的设计。就需要有一个基本的逻辑：即UCD是可以和软件工程一样，形成一套科学的方法论，并且需要有效地嵌入到产品设计和开发流程中。

我刚入行的时候把UCD看成一种偏感性的设计理念，我想很多人会跟我一样的观点。比如，我们能指出某个产品设计的不足和某个失败的交互，但这还只是凭借观察体验和一些思路得出的认知。但其实UCD是一们科学的体系。并且UCD已在ISO13407中有非常清晰的定义（同样的可用性在ISO9241-11也有明确定义）：
a) 用户积极的融入及对用户和他们的任务需求的清晰理解；
b) 用户与技术之间一个合适的功能定位；
c) 设计方案的迭代；
d) 跨学科的设计。

建立这个逻辑之后，我们聚焦到web设计上来。这里推荐的是Jesse James Garrett在《The Elements of Web Design》的经典web设计模型，非常理体系化。

上图的很多标识不够清晰，更详细版本大家可以点击这里查看。

Jesse提到了web设计的两条线：作为软件的web设计（Web as software interface）和作为超文本的web设计（Web as hypertext system）。前者是任务导向（task-oriented），后者是信息导向（information-oriented）。然后在两条线上有或者交叉或者独立的方法来演进。这个模型狂赞不止哇……

最后说说衡量UCD效果这个问题：用户满意度和用户推荐度。

1. 数据对创新没有价值，但是数据可以指导设计。之前互联网圈子就该不该听用户的话题有很多讨论。Keso早就说过不要听用户的。在我看，确实用户的很多需求不是用户自己说出来的，而是产品人员发现或创造的。同样的用户数据，不同的产品人员一定会有不同结论，最后不同的结论会输入到各自的产品。当然当转移到交互设计等环节的时候，用户的声音就需要放大，并灌输到产品中。

2. 对于调研报告和数据的分析要有技巧。前期需要调研开放性问题，先做定性调研，否则可能有大的缺漏。因为有可能我们设定的某些调研场景就是有问题的，比如一部商务手机在我们设想里的应用场景可能是office或者车上，如果我们都没有假设沙发或者床这样的场景，后期定量结果可想而知。

3. 用户做调研的心态和用户真正使用和购买的心态是不一样的。所以别把数据当宝贝，数据在那放着，关键是你如何从数据中得到恰当的反馈。当日还有这样一个案例：一部手机的用户报告显示，该手机的摄像头使用率非常低，于是该厂家决定取消摄像头功能，这样大大降低了用户的购买价格。而结果是， 没有摄像头的手机销量情况很差。为什么？因为用户填写数据报告的场景和用户购买的场景是不一样的。用户给你反馈了5个新功能，但是当你满足了用户所说的5 个功能的时候，用户可能反而不要了。

4. 数据报告是以前的东西，而产品是未来的产品。在互联网领域，数据报告和产品上线周期较短，问题较小。而从一部手机设计实现周期而言，通过数据报告得出需求，再到产品实现的时间差需要考虑。所以积累一些预期产品（PS 就像那些不会量产的概念车一样）。

5. 更多的了解数据分析原则，在产品评审中争夺话语权。亲身经历告诉我们产品需求评审和运营方案评审，没有这个是不行的。

6. 人人都要有产品经理的素质。发现很多企业的产品经理更多的是项目经理的角色。如果只是卡项目节点，关注时间节点，那么这个产品经理只是参与了产品生命周期的一小部分。这个是个老话题，我这里建议UI、ID、运营、市场都具备一定产品的素质，这样产品在前期开发和后期营销的衔接会更顺畅，产品才会更成功。