Magicmeowo

前言

通知消息，作为产品的基础功能，一直没让我逮着机会好好研究，趁着还在做企业内部的工具类产品设计，简谈感受和观点。

任务

任务的本质其实是待办事项，在个人场景中，主要是以个人主观行为掌控，主要体现在时间以及待办的内容数量。而在协同的工作场景中，待办事项则会涉及到，

人：任务发布者，任务执行者，任务关联人
时间：任务发布时间，任务截止时间，
内容：任务内容和任务数量，任务关联资料等
状态：已完成，未完成，是否逾期
更多描述：备注说明，项目紧急程度，项目重要程度等。

有时，任务的多线程还会关联多个执行者，因此对任务执行的质量和时间的重要性就体现出来了。
对于个人而言，任务创办后，直接就可以根据任务设定的节点时间，进行对应执行和调整。
但如果是对应多人协作场景，则会涉及，任务的发布与任务的接收是否及时，任务的传递与执行是否及时。
因此任务通知和任务提醒，在这个场景下延伸出来。

一个建议：任务由于强相关任务，因此在流程的涉及上应该尽可能还原或优化任务流程。

通知

广义上的通知，是指外界对个人的信息传递，它可能会要求接收方有对应的反馈，或强调信息传达的到位。
通知常定义为，官方，上级或同级，向下传达的信息内容。
不同类型的通知，内容，机制有所不同。部分通知可能会要求有相应动作回复，否则该通知不算接收到。
通知区别于消息，时效性并没有那么强，通知更多强调的是内容的单向传达，以及强制性。

消息

消息区别于通知，消息则更强调时效性，当消息发送者向接收者发了一条消息时；接收者能够很即时的收到，并可主动进行回复。消息的自由度也较高，不太强调发送者和接收者之间的层级关系。同时接受者的主观能动性更强，可以选择回复或者不回复。消息相较于聊天，消息可用于聊天场景下，例如聊天室内，单人对单人的一个互动，或者单人对多人，多人对多人的互动。
一个比较典型的例子是，WeChat 群聊功能，以及 iOS 14 最近更新的 iMessage 信息聊天室功能。

这里我也产生了一点疑问，两个场景的差异化以及 iOS iMessage 设计的“不足之处”：
场景一：WeChat 群发消息功能，相当于一个群发消息可投递至单人或多人或群组。
场景二：iMessage 群发信息功能，一个群发消息可投递至单人或群组；（因为默认选择多人就建立类似微信的聊天室）
后者的不足之处：可以满足一个群发消息可以以相同的内容发给不同的人，但是接收者被捆绑到群组会涉及到信息的隐私问题，接受者全部被邀请到一个聊天室里，但有的时候，发布信息的人其实不希望建立这种1对n的单线程群组关系，而是想建立1对1的n线程关系，我觉得这个地方需要考虑提供分发方式的选择操作。

关于两个场景的差异，个人解读观点：
正常的群发短信场景，可能一条信息内所包含所有接收者，互相之间应该是看不到的，比如WeChat 群发消息功能；如果要发建立接收者关系，可以先建立关系，再对关系组进行消息发送。这种关系的建立在社交类产品和涉及到关系类权限类设置的产品中多为常见。

而在iMessage 定义的这个基于邮件系统来的群发场景，多个关系人之间，是类似抄送收件的关系人体现。在邮件系统中，无论是接收方还是抄送方都能看到邮件的关联人信息。

优化方案已经给出：提供给信息发送者，发送发送方式的选择项。单独发送至多人（独立发送），或者群组发送。

消息与通知：由于通知和消息的差异主要体现在发送者和接收者的主动性上，因此不少产品会选择将通知直接嵌入到消息中，作为一种消息的类型，常见强调信息时效性的协同工具类产品都保留这样的设计，其它社区类产品也可见这种设计方式。如飞书、企业微信、钉钉、网易云音乐、微博等。（举这些产品为案例，只是因为这些产品较为头部，使用者较多，可能还有其它类产品也遵循这样的设计方式）

动态

动态通常来源社区，或带有社交属性的产品。常常来源于发布者（某个人，或角色，或者官方）发表的一些内容或发布者的状态的变更。这些内容往往不强调接受者一定要收到，更加侧重于发布者的主动性。基于动态产生的互动，或接收者主动发起与发布者动态产生的互动行为。可以有对应的渠道进行追溯。这里关于动态内容的互动需要针对不同的产品进行论述，比如工具类产品可能侧重于记录，而社交社区类产品可能强调对于观点的认同，异同观点的表达，或者是收藏，记录等。

提醒

提醒的本质，是基于不同时间节点，对事项的提示。
这里有两个比较关键的点，一个是时间，另外一个是事项。而事项本身可能关联的人，是我，也可能是别人。
在大多数提醒的产品中，由于不涉及协同关系，所以不太强调设置提醒者和被提醒者之间的关系。而在任务管理的协同场景中，设置提醒，可以选择被提醒者。
因此，提醒区分于通知，消息或者动态，的关键点，并不在于主动设置或被动设置。
更重要的点，是在于时间的体现。

时间，不同时间的不同，主要体现在过去，现在，以及未来。
而提醒的场景，优先体现的是，距离当下最近的未来，即将发生的事项的提醒。
根据时间的顺序逻辑，过去的事项一定是提醒过了，但是这个事项是否被执行，是需要用户进行标记的。
因此，提醒的时间逻辑应该是，优先提醒距离当下最近的即将发生的事，其次是距离当下最近已经发生的事，其次是未来要发生的事，以及过去提醒过但可能没有被标记为执行的事。

有2个值得思考的场景是，
1、已提醒和未提醒的事项的差异区分
2、已被标记为已执行和未执行的差异区分

前者主要是时间上的体现，结合视觉可以有对应的方案。
而后者更注重场景上的体现，
如果场景要求将所有发生过的事情，体现连续化追溯，则所有提醒应该在一张表内进行展示。例如iPhone的提醒，在一个表内可以设定隐藏已经执行过的事项。（劣：单张表依然无法满足时效性内容）
如果更加强调时效，则可依据时效，将过往已经提醒过的事情，进行收录。（劣：单纯按时间维度分，无法体现事项是否被执行的状态）

参考：iPhone 的提醒，既体现了时间维度的分类，今天（当下最重要的事），计划（当下和未来），全部时间（过去，当下，未来）又可以在任何一个时间类型中，看到该时间段内，已执行和未执行的状态。

这应该是“提醒”相对灵活的状态。

一个观点，不一定对：
因为提醒和任务（事项）的关系是紧密联系的，不少产品直接将 iPhone 的提醒直接拿来当成待办事项的设计，我认为这是需要考量的，当我们选择沿用一个产品的设计方案，首先应该思考的是自己的场景是什么，其次是我们要沿用的这个设计方案为什么要这样设计。以及我们的场景和这样的方案设计是否符合，或者说有没有什么更好的方案去解决当下我们的场景的问题。

各模块的功能差异

当一个产品中，以上场景都出现的时候，就应该考虑整合了。而在整合之前要做的事，是区分各个场景。对于任务和提醒而言，其实在不考虑协同的产品中，主要是用户的主观能动性，同时这种场景下，提醒的内容数量是相对可控的，个人计划也相对可控。

如果涉及到任务体系，也可以选择自主设定是否要提醒，这样主动性依然在用户手中。
而在更加强调协作的场景中，比如多任务多人协作场景，这个时候提醒可以是由他人发起，提醒我去执行的。主动权可能就在对方手中，这个时候数量以及个人计划的可控性相对较低。

任务下发通知，和任务提醒执行是两种场景，因此也会区分到底是通知，还是提醒。

通知和消息的差异在对应的模块已经有写到，可以选择差异化二者，保持相互独立。
或者将某一模块嵌入另一模块中，
具体涉及方案也需要根据实际的场景进行设计。

动态也可作为消息的一种存在。不少社区社交类产品有这样的设计。但动态由于涉及到多种类型的操作，因此会在动态这类内容下，进行细分，以上是我对提到的这些模块的一个大致认识和区分。如果真的要涉及到具体的某一个或几个功能的涉及，除了要考虑场景外，还需要考虑对应的信息内容，机制，关联关系等。

最后分享一个我认为消息系统目前做的比较好的产品：董车帝
它很清楚地区分了 通知消息、互动消息、系统消息、聊天消息，这几类的场景本身有异同。没有冗杂在一起同时保持了相对一致性。

其它产品诸如，微博、网易云音乐、知乎等有社交属性的社区产品，大多将消息整合在一起。
当然这可能是产品发展成熟度或者产品策略的设计考量，但在产品初期，能将通知系统做的相对清晰和简单的设计，还是值得点赞的。