|
|
# 09 | 手把手教你写用例： 优化微信加好友的功能
|
|
|
|
|
|
如果你在科技公司工作，那么你一定对“use case”这个词语不陌生。
|
|
|
|
|
|
“use case” 中文是“用例”，维基百科的解释是“软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术”。这个解释有点难懂，简单来说，用例就是描述在什么场景下用户用产品来做什么事儿。
|
|
|
|
|
|
各种各样的产品经理文章对于用例的解释说法不一，推荐使用的用例格式也有很多种，其实用例的具体格式需要根据具体的产品场景和公司文化来确定。但是，需要注意用例的目的是清晰沟通这个产品到底需要解决哪几个问题，具体是怎么解决的，以及用户为了解决这个问题需要做哪些操作。
|
|
|
|
|
|
用例可以用文字来表示，也可以用图表或者流程图来表示，能让设计师和工程师以及产品团队的其他人员清楚、准确地理解，才是最重要的，而不是要一定遵循某个固定的格式。
|
|
|
|
|
|
所以这篇文章， 我并不是要告诉你用例应该采取某一个固定的格式，也并不是要让你按照我的格式来，更不是要让你记住一些抽象的概念，比如用例具体的定义，而是要告诉你在明确了目标群体、 需要解决的用户问题的情况下，如何把解决方案清晰地从用户的角度表达清楚。
|
|
|
|
|
|
## 列出加好友的用例
|
|
|
|
|
|
我举个具体的例子，来跟你解释一下到底什么是用例。假如你是微信的产品经理，你现在需要优化加好友的功能，用例可能会这么写：
|
|
|
|
|
|
* 首先，添加好友是双向的，彼此都成为了对方的好友。
|
|
|
|
|
|
* 其次，添加好友有不同的途径：
|
|
|
|
|
|
|
|
|
> 第一， **通过用户名添加；**
|
|
|
> 第二， **通过其他朋友分享的名片添加；**
|
|
|
> 第三， **通过扫描二维码添加；**
|
|
|
> 第四， **在群成员中找到该用户，点击进入这个用户的主页，从而添加好友。**
|
|
|
|
|
|
以上四个用例适用于一个用户想添加另一个用户。
|
|
|
|
|
|
除此之外，还会出现一个用户想同时添加一群人的情况，比如你在同学聚会的时候想添加所有同学等，这时添加好友的途径有：
|
|
|
|
|
|
> 第五， **找到距离很近的其他用户，同时添加所有在这个距离之内的朋友；**
|
|
|
> 第六， **同时输入相同的密码自动加入同一个群，从而在群中一个个地添加好友。**
|
|
|
|
|
|
**现在已经清楚罗列了所有添加好友的途径，但是这还远远不够，接下来你需要写清楚用例的条件、操作步骤和产品框架。**
|
|
|
|
|
|
**1\. 什么情况下能开启这个功能呢？**
|
|
|
|
|
|
只要用户登录了微信，在任何情况下都可以开启前四个方式。虽然这四种方式都可以帮助用户添加不在身边的人为好友，但是第1种和第3种更适用于面对面添加好友的情况。
|
|
|
|
|
|
虽然用户在任何情况下都可以开启第5种和第6种方式，但是如果没有一群人在身边，这个功能就有些小题大做了，所以这两种方式适用的场景还是一群人在一起面对面地添加好友。
|
|
|
|
|
|
**2\. 执行完这个操作以后，用户得到了什么呢？**
|
|
|
|
|
|
用户添加对方作为好友是一个双向的过程，从此以后，你就可以查看对方的朋友圈、给对方发消息、把对方加到某一个群里。
|
|
|
|
|
|
**3\. 考虑一下，如何清晰地表述这个用例怎么利用已经存在的产品架构。** 说白了就是，哪些部分是用户已经熟悉的、哪些部分是新的，这个问题一般适用于在已有产品上添加新功能的情况。
|
|
|
|
|
|
假设前四个用例在上一版产品中已经发布了，现在需要增加第5个和第6个用例。你首先应该弄清楚新加这两个功能， 到底有哪些部分可以共用以前的四个功能，哪些部分是需要新增加功能的。
|
|
|
|
|
|
比如说，进入添加好友的功能，即“入口点”（entry point），也就是说到底怎么开启这个功能呢？其实，新增加的第5个和第6个用例和前4个用例添加好友功能的开启方式都是一样的：点击“+”，然后点击“添加好友”，最后选择具体的添加方式。只不过，现在需要在这个菜单里面新增加两个选项而已。
|
|
|
|
|
|
而在这之后的功能就是新的了。前四种用例更多的是搜索和匹配，但是现在需要能让用户进行快速添加。
|
|
|
|
|
|
这个新功能的实现其实是利用了地理位置，并假设相同地理位置的用户多半是在一起聚会的。如果此时此刻这些人同时点击了“添加好友”，并且都在一个非常相近的地理位置，就可以把他们的用户名都显示出来，以方便大家添加。
|
|
|
|
|
|
找到要添加的用户名，就可以点击进入他的介绍页面，有头像、用户名、一句话的介绍，以及“添加到通讯录”的选项，其实这些功能和前四种方式是一模一样的。
|
|
|
|
|
|
在你弄清楚了哪些功能是可以共用的、哪些是需要新增加的后，就要呈现给团队的其他成员了。虽然流程图可以比较清楚地表达这些内容，但是我个人的建议是，不要过于追求复杂的图表，把大量时间花在做图上，而应该思考你表述用例的方式是不是最准确、最清晰的。
|
|
|
|
|
|
## 用例具体化
|
|
|
|
|
|
现在你已经列出了能够添加好友的所有途径，但是要把它转化为工程师和设计师能够进行操作的文档，还需要描述得更清楚，这时就需要把用例“具体化”。
|
|
|
|
|
|
比如说，第一个用例的具体流程是这样的：
|
|
|
|
|
|
> 用户点击“+” → “添加好友” → 会有个文本框让用户输入用户名 → 开启搜索 → 必须在用户名完全吻合的情况下，才能显示目标用户名 → 点击进入想要添加的用户的页面 → 点击“添加到通讯录”。
|
|
|
|
|
|
这种方式把一步一步的工作流描述得非常清楚，这其实和产品需求文档上的内容非常相似了。然而，并不是所有产品都可以用这样的方式表达，这种表达方式适用于产品已经有了很多成熟框架的情况。
|
|
|
|
|
|
比如在这个例子中， 你已经有了进入“添加好友”这个选项的工作流、显示好友搜索的逻辑，以及“添加到通讯录”这个选项。
|
|
|
|
|
|
对于一些还不存在已有框架的新产品来说，流程图看上去可能是这样的：
|
|
|
|
|
|
> 用户进入添加好友的页面 → 页面有一个可以搜索用户名的地方 → 显示搜索结果，但是为了避免加错人，需要有一些预防加错人的机制 → 添加目标用户。
|
|
|
|
|
|
这样可以把产品功能实现所需要的组成部分先说清楚，然后再详细思考一个个组成部分应该怎么设计。比如，用户如何进入添加好友的页面、如何避免用户加错人。你只有把这些问题思考清楚了，才能把产品需求写清楚，工程师和设计团队才可以真正开始实施。
|
|
|
|
|
|
再跟你分享一下，我在Facebook做产品经理的切身体验。我们产品的搜索、添加好友的功能与此类似，也更复杂一些，还涉及到了用户信息显示、隐私设置等问题。从这些具体的案例中不难看出，看似简单的添加好友的功能，会影响几十个不同的产品、上百个工程师，以及非常多的场景，因此把用例写得足够清楚是非常重要的。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
简单地说，用例就是描述在什么场景下用户用产品来做什么事儿，其目的是要清晰地、有条理地和工程师、设计师团队进行交流。因此，用例需要列出产品所有的情况，以及每种情况的工作流关系。
|
|
|
|
|
|
写用例时，需要写明：什么情况下可以开启这个功能；执行完这个操作以后，用户得到了什么；这个用例怎么利用已经存在的产品架构。
|
|
|
|
|
|
最后，我讲解了如何把用例具体化，这个过程对于缺乏框架的新产品和已经有框架的成熟产品是不一样的，并且分别给出了这两种情况下用例具体化的方法。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
请你思考一下，微信阅读公众号文章的用例都有哪些呢？请你描述一下已有的用例，并且添加两个新的用例。
|
|
|
|