探索中前行一个设计师做产品的浅显心得人

编辑导语：当设计师有了一定的工作经验后，往往会发现工作的范围不再只限于输出设计方案。这就要求我们除了专业的深度累积，也还需要拓宽横向职业技能。本文作者今年完整的参与了一个从策划到运营全程跟进的项目，在探索过程中，累积了一些产品搭建的基础知识，并且分享给大家。在我的认知体系中，将产品的类型进行了如下划分：以主体维度划分，产品类型可分为“消费级产品”和“企业级产品”，也就是我们常说的“C端产品”和“B端产品”。消费级产品和企业级产品的区分特征在于，产品的客户和用户是否为同一主体。所谓客户，就是付费的那类人；所谓用户，就是使用的那类人。消费级产品，付费的和使用的都是同一类人；而企业级产品，付费的和使用的不是同一类人。基于以上的阐释，我们可以给出书面的定义：消费级产品，是指客户和用户为同一主体的产品。企业级产品，是指客户和用户非同一主体的产品。以需求维度划分：产品类型可分为“工具类“、“社交类”、“生活类“、“信息类”、“娱乐类”、“游戏类“六种。具体的类型定义我就不做冗余阐述了，这些类型还是比较好理解的。有了前序的产品类型分类后，明确要设计的产品是属于哪种类型，接下来进入从0到1的必经之路。一、评估产品的投入和产出在建设任何一个产品或功能前，首先都需要考量建设的必要性。对于必要性的考量，无非就是要回答以下几个问题：1.能带来什么价值？这个问题是产品的基石，实际是在思考用户的本质需求。在这个阶段我们很容易犯的错误就是把解决方案当成是价值本身。用个大家烂熟于心的例子，用户说想要一匹马，但用户的本质需求其实是想要提高通勤效率。那么我们在回答这个问题时，就不能浅显的认为答案是“我可以给用户提供一匹汗血宝马”，“提供马”只是带来价值的一种解决方案，并不是价值本身。2.价值怎么量化？以工具类产品为例子，其价值就是降本或增效。到底能降多少本、能增多少效，是需要给出量化评估的。成本一般可用人力成本、硬件成本来评估，效率一般可用耗时来评估。这里给出的量化评估，细化后就是后续产品的关键指标和目标。3.影响范围有多大？影响范围其实可以归入到价值量化的问题中，这里单拎出来的原因是因为这一点很多时候会被我们忽略。在系统产品中，影响范围一般可通过角色数、用户数来进行评估。同样的，影响范围也是后续产品的关键指标和目标。4.需要投入多少资源？设计师也应该需要具备一定的成本意识，对于产品开发的投入，一般会通过工时（人日）、硬件、外部采购这三个纬度来评估显性成本。同时，从经济学的角度看，人力资源、部门预算属于私用品，有时我们还需要考量其他产品因未能使用到资源而产生的价值损失等这类隐性成本。TIPS：前三个问题是从“产出”的角度出发，第四个问题是从“投入”的角度出发。正如微观经济学的厂商理论中，会分为生产理论和成本理论两个方向来研究。二、业务流程与产品架构当验证完产品建设的必要性，决定要开发这款产品后，就该进入到业务流程的梳理和产品架构的设计阶段。这是产品从0到1建设时独有的一个必经阶段，我们必须严肃、认真、敬畏。业务流程，包括了业务流、状态流、数据流，涉及钱的系统还会有资金流。产品架构，是指产品中的功能模块或子系统组合。对于复杂的系统，一般需要先梳理业务流程，再设计产品架构。产品架构会随着业务流程的梳理而逐步呈现，这是一个很自然而然的过程。在这个阶段，我们会需要借助一些图工具，包括业务流程图、状态图、权限表、时序图等工具。工具的种类是很多的，以下仅举例我在项目中使用过的几个工具。业务流程图主要描述的是业务需要经历的主步骤，是状态图、权限表的基石。完整的业务流程图帮助产品、设计、研发、测试等各个角色的参与人快速了解业务全貌。可以直接从业务流程图中洞察业务逻辑是否合理，在更进一步的细化工作开始前，就能先砍掉很多不必要的分支流程（功能），或是修正显而易见的逻辑错误。状态图主要描述的是业务步骤中存在的各种状态，是梳理异常业务流的强有力的工具。可以清楚的看到会有多少同页面的不同状态。设计师在初次接触状态图时，容易忽略系统产生的路径与页面状态，或是把系统路径与角色路径混淆在一起。权限表主要描述的是各角色对产品各功能模块的页面权限、操作权限、数据权限，是基于状态图，添加角色后的细分理解。每种业务状态都由相应的角色/系统操作产生，而链接其中的每条线就是赋予不同角色的权限能力。描述方式上，基于开发的语言，和技术模型的结果进行表达更清晰易懂。将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。时序图主要描述的是功能模块间的业务、数据、信息、资金的流转，是基于数据流程图对产品架构的最终呈现。和我们熟悉的服务蓝图比较起来，时序图更适合面向研发人员，清晰的介绍数据流转关系。除了展现产品整体的数据流转信息外，也可以用以说明某些涉及多平台多方合作的数据流转关系，以下的案例便是一个比较简单且适合向开发哥哥阐述数据关系的时序图。TIPS：注意“这是产品从0到1建设时独有的一个必经阶段”的理解。这个阶段虽然在后续产品迭代（从1到）的建设中不是必须经历，但是并不意味着就完全不会经历。一切都在变化之中，产品架构也会跟随业务变化发生调整。这并不是鼓励我们可以随随便便的在迭代中重启产品架构设计，架构设计一旦重启，就意味着业务主流程的缺失或冗余，随之而来的就是整个系统问题。这个时候，就提头去见开发哥哥吧。三、优先级的考量经济学家说，社会的资源总是不够的，人类的欲望总是多样的。同样的，完成了产品架构的建立，我们对产品所要具备的功能模块或子系统已经了然于胸，但开发资源是有限的。这个时候就需要一套机制或一种逻辑支撑我们做抉择，决定哪些功能要先开发，哪些功能可以后面慢慢迭代。优先级是产品工作中常常挂在嘴边且永远绕不开的话题。优先级本质上是对功能或需求的一种分类维度，而分类标准可以有两种：用户价值标准、企业价值标准。以用户价值为标准对优先级进行考量，最经典的就是Google的“牙刷理论”。牙刷理论把功能分为三个层次：很多人用、很多人经常用、很多人不仅经常用而且必须用。以业务价值为标准对优先级进行考量，可以把功能分为三种：生死功能、特性功能、扩展功能。生死功能是指刚性、痛点、决定产品生死的功能，如数据分析类产品的准确性；特性功能是指为了契合用户、提高收入的功能，如数据分析类产品的美观性；扩展功能是指不决定生死、不决定定位、不决定体验、但又不可缺少的功能。通过以上两种标准综合考量，功能模块或子系统的优先级基本也可以梳理出来了。四、概念模型与操作接下来，我们就要开始进入具体功能模块的策划。诶，先别急着交互画原型。在这个阶段，我们需要思考，如何让用户理解系统功能的运作方式，这个过程就是在建立概念模型。举个简单栗子，志愿者去为某公益机构服务做善事，我们会把这个过程理解任务认领的过程。这就是一个简单的概念模型，基本不用学习，我们就知道要去向机构认领再提交自己做的结果。但在数字环境下数据读取中，任务认领就不是如我们表面看到的那样简单，而是在多个模块甚至系统间交换数据。点击就可认领任务，就是一种方便用户理解在数据流转方面如何运作的概念模型。试想，如果系统直白的将它原本的运作方式呈现给我们使用，我们甚至需要编写一段代码才可以成功解读一个任务描述，再将任务归属到我的账户系统下，估计我们很多人一时半会儿学不会。看完这个栗子相信大家应该对概念模型这个东西有点感觉了。概念模型帮助我们把复杂的物理现象转化成可用的、可理解的心理模型，它是组织和理解复杂事物的非常重要的工具。一个好的概念模型，可以化繁为简，减少用户的学习成本，这也是概念模型的意义所在。完成了概念模型的选型和建立，用户在这个功能模块中需要执行哪些操作以及操作的步骤都将很自然的呈现出来。TIPS：无论在产品开发环节还是在用户与产品的交互环节，固有的复杂度都无法依照我们的意愿去除，只能设法调整、平衡。所以在建立概念模型时，产品经理不能仅仅

转载请注明：http://www.jinyawz.com/zfljj/11263.html