再谈产品

再谈产品，我相信多聊多思考，关于产品的思路就会更清晰，收获就会更多。产品存在的目的就是解决用户需求，解决用户问题。所以前面的需求分析很重要，在这里我先不去谈需求分析。而是聊聊方案设计。方案设计是设计满足用户需求的功能或者设计解决用户问题的方案。这里的需求与问题是有区别的。需求是我们常说的用户需要被满足的需要。问题是我们设计出来的解决用户需求的方案存在的问题。所以可以理解满足需求是设计一个新功能，解决问题是针对现有功能的优化。而设计新功能或者针对现有的功能优化都是设计方案。

接下来就聊聊设计方案。一个方案的设计可以从不从层面去设计，如产品层面、交互层面、UI层面。实际上这三个层面是我们根据自己的认知来分类的。他们之间绝对有模糊的边界，也就是不那么清楚应该属于哪个层面的。产品层面的方案主要是关于完整功能的方案，很少关注细节。是一个粗颗粒的。一个功能有功能的属性。当我们去定义一个功能时候，会去描述这个功能的操作流程，数据流程。操作流程就是用户与界面交互的逻辑。数据流程就是数据在后台怎么流转的。

再对交互逻辑深层次发掘，交互流程就是，用户的行为在时间的维度上是怎么流转的。这里面涉及到主要的流程，即用户完成任务大多数是怎么操作的。还有分支流程，即少数用户完成任务是怎么操作。好友异常流程，一旦因环境造成了流程中断，怎么样让用户的行为继续，从而能够继续完成任务，或者让用户离完成任务更近一些。所以在设计流程的时候有好多判断，一但用户不是按照我们设计的主流程走，应该怎么走这个流程。一但出现不同问题，应该怎么走这个流程。所以抽象一点就是“如果怎么样就怎么样”，就是设计流程的核心。

再看后台的数据流转流程，首先是数据是怎么来的，主要是用户行为产生的，用户产生了一个数据，我后台怎么处理这个数据，是计算？还是存储？还是传递？计算与存储都是没了后来传递下去再使用，为了支持用户的行为流程。比如用户输入手机号、验证码，后台会把这些数据存储起来，以后使用。如果要存储起来以后使用，需要先判断下这个手机号是不是这个用户的，所以通过短信验证码来确认这个手机号是不是这个用户自己的，这就是判断逻辑。如果是，就把这个手机号存储起来并分配一个唯一编号关联起来，这就是用户的账号产生了。这里涉及到信息编辑，组合，存储。把一个数据生成了一个账号对象，这个账号对象其实就是一个更有意义的功能。在后台表现为一个更有意义的数据组合对象。为了以后怎么使用呢？是作为这个用户在应用内这个虚拟世界里的身份。以后这个用户产生的其他行为数据都会与这个身份绑定，从而可以更好地位这个用户提供服务。在举一个例子，比如订单的生成，这个订单包含了一些我们服务需要知道的基本信息，谁买了从哪里到哪里几点发车的车票，车票包含了哪些乘客、是否包含保险、是否包含抽奖券等附加信息。然后还有这个订单的原信息。订单的价格、服务费、产生时间、订单状态。这些信息都有了，然后会把这些信息组合生产一个订单对象，存储起来，然后会拿着这里面的相关信息去其他地方交互。比如，要把这样的一张票信息发给车站，需要车站从数据库内把这样的一张票标记为已卖，再存储上这个购买人的信息。然后再发给我们的后台。我们的后台再把这个信息通知到用户。这整个流程里涉及到的是，信息的处理与传递。

以上举的例子就是后端的流程，其实一句话总结为，信息的处理与传输。当然这中间会涉及到与前端行为流一样的流程逻辑判断。比如流程遇到问题了，怎么走异常处理。前后端是相辅相成的，是互相作用的。

好了今天就写到这里，发现这个话题梳理进去还是挺有意思的，很容易进入流的状态。

---

原文发布于 2019-07-31 · 查看微信公众号原文