产品设计的一个小心得：业务、通知、运营

当设计内部业务功能或者系统久了，就会有种感觉，其实整个系统就包含三个用户群体的需求：

A、业务实现需求：

　　这需求是这个功能、系统的相关使用群体，主要解决这些人或者群体在使用这个功能或者系统上的业务上需求。像验收人员要操作系统验收东西，这种需求偏重业务实现，注重数据的输入与输出，是整个功能的基础。

B、系统互动需求：

　　这需求是系统与使用者之间的需求，从一个业务闭环来说，用户操作——系统需要反馈给相关人员——用户/其他用户上去执行新的行为，这种形成一个业务闭环。其实说白了就是“消息通知”的设计。为什么说重要呢？举个场景，我发起了一个报销流程，但是财务没收到这个功能推送的消息或者提醒，然后财务也不会主动去看这个系统有没要处理的事情，那这个业务是走不下去的（虽然有点极端，一般要用的系统都是强制要上去看）。

　　所以为了更好推动整个业务进程，最好的做法就是“消息通知”，无论是推送PC端的还是移动端的，将合适的信息推送给需要的人，引导相关人员上去系统完成业务，就是这需求的核心。

C、运营管理需求：

　　系统是需要有人运营、维护的，很少功能或者业务是不需要人工介入的，如果没有考虑这些需求的话，就会导致产品人员来做运营工作。举个例子，你设计了文章发布或者图片上传的功能，但是没有做配套的后台给运营人员查询、审核查，结果有说图片侵权的时候，运营人员只能找产品，产品找开发来搞。

　　如果设计一个功能、系统的时候已经考虑到普通运营人员、管理员、超级管理员，并设计好相应的权限，当出现异常情况时，可以通过这些人员所拥有的权限去处理相关业务，而不需要改数据库、改代码的方式去解决异常情况。

 

为什么写一下这个，是因为之前从0到1设计的时候，很多时候都会忘记消息跟运营的需求，结果上线之后发现效果不理想，然后逐渐补充相关功能。

如果从一开始就已经考虑到这些问题的话，那从第一个版本就相对来说可以控制得更好一些。

这个只是一个小的心得，不复杂。