09 | 手把手教你写用例: 优化微信加好友的功能

09 | 手把手教你写用例: 优化微信加好友的功能

朗读人:丁婵    09′43′′ | 4.86M

如果你在科技公司工作,那么你一定对“use case”这个词语不陌生。

“use case” 中文是“用例”,维基百科的解释是“软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术”。这个解释有点难懂,简单来说,用例就是描述在什么场景下用户用产品来做什么事儿。

各种各样的产品经理文章对于用例的解释说法不一,推荐使用的用例格式也有很多种,其实用例的具体格式需要根据具体的产品场景和公司文化来确定。但是,需要注意用例的目的是清晰沟通这个产品到底需要解决哪几个问题,具体是怎么解决的,以及用户为了解决这个问题需要做哪些操作。

用例可以用文字来表示,也可以用图表或者流程图来表示,能让设计师和工程师以及产品团队的其他人员清楚、准确地理解,才是最重要的,而不是要一定遵循某个固定的格式。

所以这篇文章, 我并不是要告诉你用例应该采取某一个固定的格式,也并不是要让你按照我的格式来,更不是要让你记住一些抽象的概念,比如用例具体的定义,而是要告诉你在明确了目标群体、 需要解决的用户问题的情况下,如何把解决方案清晰地从用户的角度表达清楚。

列出加好友的用例

我举个具体的例子,来跟你解释一下到底什么是用例。假如你是微信的产品经理,你现在需要优化加好友的功能,用例可能会这么写:

  • 首先,添加好友是双向的,彼此都成为了对方的好友。

  • 其次,添加好友有不同的途径:

第一, 通过用户名添加;
第二, 通过其他朋友分享的名片添加;
第三, 通过扫描二维码添加;
第四, 在群成员中找到该用户,点击进入这个用户的主页,从而添加好友。

以上四个用例适用于一个用户想添加另一个用户。

除此之外,还会出现一个用户想同时添加一群人的情况,比如你在同学聚会的时候想添加所有同学等,这时添加好友的途径有:

第五, 找到距离很近的其他用户,同时添加所有在这个距离之内的朋友;
第六, 同时输入相同的密码自动加入同一个群,从而在群中一个个地添加好友。

现在已经清楚罗列了所有添加好友的途径,但是这还远远不够,接下来你需要写清楚用例的条件、操作步骤和产品框架。

1. 什么情况下能开启这个功能呢?

只要用户登录了微信,在任何情况下都可以开启前四个方式。虽然这四种方式都可以帮助用户添加不在身边的人为好友,但是第 1 种和第 3 种更适用于面对面添加好友的情况。

虽然用户在任何情况下都可以开启第 5 种和第 6 种方式,但是如果没有一群人在身边,这个功能就有些小题大做了,所以这两种方式适用的场景还是一群人在一起面对面地添加好友。

2. 执行完这个操作以后,用户得到了什么呢?

用户添加对方作为好友是一个双向的过程,从此以后,你就可以查看对方的朋友圈、给对方发消息、把对方加到某一个群里。

3. 考虑一下,如何清晰地表述这个用例怎么利用已经存在的产品架构。 说白了就是,哪些部分是用户已经熟悉的、哪些部分是新的,这个问题一般适用于在已有产品上添加新功能的情况。

假设前四个用例在上一版产品中已经发布了,现在需要增加第 5 个和第 6 个用例。你首先应该弄清楚新加这两个功能, 到底有哪些部分可以共用以前的四个功能,哪些部分是需要新增加功能的。

比如说,进入添加好友的功能,即“入口点”(entry point),也就是说到底怎么开启这个功能呢?其实,新增加的第 5 个和第 6 个用例和前 4 个用例添加好友功能的开启方式都是一样的:点击“+”,然后点击“添加好友”,最后选择具体的添加方式。只不过,现在需要在这个菜单里面新增加两个选项而已。

而在这之后的功能就是新的了。前四种用例更多的是搜索和匹配,但是现在需要能让用户进行快速添加。

这个新功能的实现其实是利用了地理位置,并假设相同地理位置的用户多半是在一起聚会的。如果此时此刻这些人同时点击了“添加好友”,并且都在一个非常相近的地理位置,就可以把他们的用户名都显示出来,以方便大家添加。

找到要添加的用户名,就可以点击进入他的介绍页面,有头像、用户名、一句话的介绍,以及“添加到通讯录”的选项,其实这些功能和前四种方式是一模一样的。

在你弄清楚了哪些功能是可以共用的、哪些是需要新增加的后,就要呈现给团队的其他成员了。虽然流程图可以比较清楚地表达这些内容,但是我个人的建议是,不要过于追求复杂的图表,把大量时间花在做图上,而应该思考你表述用例的方式是不是最准确、最清晰的。

用例具体化

现在你已经列出了能够添加好友的所有途径,但是要把它转化为工程师和设计师能够进行操作的文档,还需要描述得更清楚,这时就需要把用例“具体化”。

比如说,第一个用例的具体流程是这样的:

用户点击“+” → “添加好友” → 会有个文本框让用户输入用户名 → 开启搜索 → 必须在用户名完全吻合的情况下,才能显示目标用户名 → 点击进入想要添加的用户的页面 → 点击“添加到通讯录”。

这种方式把一步一步的工作流描述得非常清楚,这其实和产品需求文档上的内容非常相似了。然而,并不是所有产品都可以用这样的方式表达,这种表达方式适用于产品已经有了很多成熟框架的情况。

比如在这个例子中, 你已经有了进入“添加好友”这个选项的工作流、显示好友搜索的逻辑,以及“添加到通讯录”这个选项。

对于一些还不存在已有框架的新产品来说,流程图看上去可能是这样的:

用户进入添加好友的页面 → 页面有一个可以搜索用户名的地方 → 显示搜索结果,但是为了避免加错人,需要有一些预防加错人的机制 → 添加目标用户。

这样可以把产品功能实现所需要的组成部分先说清楚,然后再详细思考一个个组成部分应该怎么设计。比如,用户如何进入添加好友的页面、如何避免用户加错人。你只有把这些问题思考清楚了,才能把产品需求写清楚,工程师和设计团队才可以真正开始实施。

再跟你分享一下,我在 Facebook 做产品经理的切身体验。我们产品的搜索、添加好友的功能与此类似,也更复杂一些,还涉及到了用户信息显示、隐私设置等问题。从这些具体的案例中不难看出,看似简单的添加好友的功能,会影响几十个不同的产品、上百个工程师,以及非常多的场景,因此把用例写得足够清楚是非常重要的。

总结

简单地说,用例就是描述在什么场景下用户用产品来做什么事儿,其目的是要清晰地、有条理地和工程师、设计师团队进行交流。因此,用例需要列出产品所有的情况,以及每种情况的工作流关系。

写用例时,需要写明:什么情况下可以开启这个功能;执行完这个操作以后,用户得到了什么;这个用例怎么利用已经存在的产品架构。

最后,我讲解了如何把用例具体化,这个过程对于缺乏框架的新产品和已经有框架的成熟产品是不一样的,并且分别给出了这两种情况下用例具体化的方法。

思考题

请你思考一下,微信阅读公众号文章的用例都有哪些呢?请你描述一下已有的用例,并且添加两个新的用例。

版权归极客邦科技所有,未经许可不得转载

精选留言

  • 徐东鹏~种下一朵太阳花
    用例是通过一系列动作,完成某个操作。 因为关于阅读的用例比较简单,简单列下涉及的功能点。
    阅读前:推送、朋友圈信息流、聊天消息、微信热点推荐、搜索;
    阅读中:聊天置顶、分享、留言、收藏、文中搜索。
    阅读后:查看推送记录、查看留言、查看收藏、搜索。

    考虑增加的是查看阅读记录、选中文章内容做评价,可点击内容查看他人评价。
    2018-05-11
  • Beryl🌻
    一直觉得微信在公众号上应该增加一个最近阅读的列表选项,例如当你阅读某篇文章时有一条消息过来,如果想看消息,就要退出当前文章,看完消息再回到文章时就比较麻烦了,还要从头找。
    2018-06-09
  • Lisa
    一、开启公号文章的途径:
    公号推送
    朋友圈信息流
    群内信息流
    聊天消息
    搜索
    微信热点
    其他公号文章内嵌
    二、用户得到了什么:分享、留言、收藏、搜索页面内容,添加公号,在聊天中置顶,保存到其他APP,投诉等等

    三、可以添加的新用例
    搜索推荐相关主题的文章(不限同一公众号)
    我的哪些好友也在阅读这篇文章

    四、如何利用已存在的产品架构
    在公号文章底部添加相关文章的链接和已阅读的好友头像
    其他可利用已有的产品架构
    2018-05-18
  • linda.zx
    从三方面大致分析已有用例
    1.文章来源:公众号推送、微信聊天中、微信朋友圈中、微信搜索
    2.阅读体验:适应移动端阅读体验的文章排版;可以搜索文章中的内容;可以设置文字大小
    3.阅后操作:通过文章订阅公众号;分享给好友;可以收藏;可以投诉举报;可以留言交流;可以在浏览器打开文章

    能想到可以新增的用例有
    1.可以通过百度、谷歌等搜索引擎搜索到文章的内容
    2.可以分享至为知笔记、印象笔记之类的应用便于用户收集碎片知识
    2018-05-10
    作者回复

    嗯 写的很有条理

    2018-05-13

  • herongchang
    极客好像不支持评论下继续评论呀 哈哈哈 其实这算一个基本功能。。只好再开一条留言了
    还是回到用例的目的:讲清楚不同用户在不同场景的不同操作,系统应该如何正确的响应。
    我以前也写文字版的测试用例,跟工程师调研了一下,他们往往更喜欢看图(想想也能解释,在理解的难易程度上 图大于表大于文字嘛)所以后来就以流程图的形式来写。
    这里说核心流程不算太准确,因为用例可以很细,最细的能细到测试用的测试用例。应该说要目的是一致的,只是展现的方式有所不同。
    欢迎继续讨论哈
    2018-05-14
    作者回复

    嗯 多谢你的评论 很具体

    2018-05-22

  • 黄黄黄
    可能添加的新途径:
    1.好友在看的文章
    2.热门文章
    具体的入口和方式没有思考清楚,可能会从搜索入手推荐好友中的公众号文章热词以及整个微信公众号文章热词
    2018-05-10
    作者回复

    嗯 有意思 怎么提取公众号热词呢

    2018-05-13

  • 黄黄黄
    微信阅读公众号文章的途径:
    1.关注的公众号新推送文章直接看
    2.朋友圈别人转发的文章直接看
    3.好友聊天/群聊天转发的文章直接看
    4.通过微信搜索关键词看公众号文章
    2018-05-10
  • LeungJun
    初创时期,为了产品快速迭代,敏捷开发,能将沟通尽可能保持平滑顺畅和开发、测试沟通以完成实现没毛病;但成熟企业内,这种方式很难保证产品信息完整性和追溯,尤其是重业务的toB企业;
    比方说,开发阶段:团队容易扯皮;
    产品迭代阶段:业务的逻辑只在负责的开发、测试、产品身上,其他未必清楚完整,对于流动性普遍很大的互联网企业问题不容乐观;
    同时后期的开发、测试、产品好难接手之前产品优化;
    2018-08-13
  • Lynn
    用例应该覆盖到:用户,场景,遇到的问题;可以用导图穷尽出来。
    2018-05-27
  • 第一原理性与刻意练习
    如果有demo会更直观些
    2018-05-26
  • 第一原理性与刻意练习
    如果加上实际的demo或例子会更直观些
    2018-05-26
    作者回复

    嗯好的 多谢反馈 我们以后的案例多加demo

    2018-05-29

  • Jerry
    可以理解为用例是对使用流程进行详细化说明?
    2018-05-13
    作者回复

    可以这么理解 用例就是讲清楚使用的场景都有啥,每个场景的体验和流程

    2018-05-15

  • herongchang
    用例听着有点像核心流程?
    2018-05-12
    作者回复

    你们的核心流程是怎么定义的?

    2018-05-13

  • Charles
    前置条件和后置条件?
    2018-05-12
  • namsom
    请问一下老师,我们在确定了UC之后,是否需要画业务流程图呢?
    2018-05-11
    作者回复

    我觉得取决于你是不能把事情说明白 一般流程图可以解释清楚事情 但是如果大家已经明白了情况 到不一定一定要流程图

    2018-05-13

  • 秋日晨光
    有图表会更形象些吧
    2018-05-10