SaaS产品设计方法论.docxVIP

SaaS产品设计方法论有这样一个场景： 老板/用户：我有一个特别棒的想法，优先级很高，你赶紧把方案产做出来。 产品经理：保证效率！我马上就开始画原型，然后内部评审，接着推进开发。 这时候局部产品经理急于表现，需要将需求快速落地，第一反响就是开始执行, 所以经常会发生一种情况，产品经理很努力的去做，把需求或想法百分百的去还 原，但结果老板或用户体验完之后发现，这并不是我想要的功能。 出现这种情况的原因是产品经理没有了解到这个需求背后的动机和目的，这是很 多小伙伴容易出现的问题。而SaaS产品设计，不仅仅只关注设计，在此之前我 们更要关注产品的定义。需要我们想清楚这个需求对应的场景是什么，场景中的 需求价值是什么。之后才是结构化的框架把功能设计出来。 文章整体分为以下几个局部： . SaaS产品设计痛点场景拆分 . SaaS产品不同维度的认知 .我们通过什么方式去理解业务 .我们如何梳理业务判断需求价值 .我们如何设计产品架构与功能 有一种方式轮岗机制，有机会的话能够直接上手体验业务方的工作是最好的。用 户调研主要从流程维度和具体场景维度去设计调研问题。 在理解业务这个层面上我们需要循序渐进的，理解业务没有太多的技巧，通过观 察和调研交叉，了解用户/用户需求，并通过产品设计满足需求，了解反响，进 而根据反响持续满足需求--通过不断地这样循环深耕业务，才能不断深化对业 务的理解。 四、SaaS产品如何梳理业务判断需求价值很多产品经理在做了一波业务调研之后，也对业务有了一定程度的理解，认为接 下来就该到需求分析了。其实不是这样，除了对业务要有一个深度了解之外，还 需要还原业务中遇到的场景是什么，用户需求价值是什么。如何去判断需求的价 值，其实本质是我们需要在产品定义这个环节去梳理清晰。 产品定义分两个局部：第一回归场景（梳理并描述业务场景），第二理清价值（判 新场景中需求的价值）O.为什么要回归场景? 在这个跟大家描述两个我们常见的工作场景彳艮多时候产品经理在提出产品方案 时，大家围绕实现细节开始讨论的时候容易出现，‘我觉得’的方式来表达自己 的观点，每个人都有自己的想法，无法达成统一的意见。还有一种情况是在没有 理解场景的情况下直接开始画原型，这时候会出现我们产品上线之后总是不符合 实际线下流程，还得推倒从来。 现在我们回想上面两个场景中为什么出现这种情况，本质是因为产品经理对外 （工程组其他人），完成一项任务肯定是需要多个部门多个角色频繁的传递用户 需求，因此使用一套易理解，贴近实际的沟通的方式就很重要，而场景就是通行 于不同角色之间解决产品问题的语言。 对内（自身思考）产品设计我们需要先发散后收敛，因此动手画原型，写文档之 前我们需要做大量的思考，调研。逻辑基点是用户面临的实际情况到底是什么样 的，即回归场景。 .单个场景与多个场景在单个场景上，SaaS产品不能创造,只能还原。这也是和C端的区别点,C端 因为自己就是用户，可以以发散的方式创造场景，从而引领用户需求。SaaS业 务天然存在壁垒，无法发散获取，只能还原场景，且颗粒度需要更细。在多个场 景上，SaaS产品需要考虑业务的闭环。同样以C端举例，c端产品相对简单， 重点在于单点突破核心场景。SaaS产品业务链长，缺少任何一个必备场景都可 能无法闭环。所以回归场景我们需要先将单个场景描述清晰，进而梳理链条中的 全场景。 .场景我们该如何去描述回归场景我们需要通过一种通用的场景描述方式，对内形成自己的思考基点，对 外让大家形成共识。在这里跟大家提供一种场景描述方法场景描述的7要素（用 户、环境、时机、目标、动作、截止、任务）SaaS产品的场景是真实存在的， 不是凭空捏造的。需要在真实业务中得到验证。场景描述方式本身不重要。重要 的是对外能够形成统一的认知，对内思考能够还原用户实际情况才是关键。 要素介绍 某一个用户一个人/一种类型的群体 某一个用户 在某一个特定环境下空间、材料、设备等物理环境/物质、工具、时 出现某一个特定的时机触发用户产生目标的事件/影响用户行为的环境* 带着某一个目标任务结束的停止条件 带着某一个目标 采取了一系列动作简单、具体、最小化的任务 和某些介质交互介质的背后，可以是另一个用户 完成了一个特定的任务通常是逐步进行的 针对单一的场景我们可以通过单一场景描述方式去还原，针对多个场景时我们可 以借助场景需求清单，场景需求清单是多个场景串联形成的结构化信息，他是一 个业务链条下的场景拆分后的需求集合，场景需求清单可以帮助我们梳理业务链条下的场景关系，防止遗漏影响业务闭环的场景。基于之前的调研，找到关联步 骤/流程，根据流程还原每个流程下的代表性场景,并拆解出需求。核心步骤提 炼成三步：第一梳理出清晰地业务流程.第二将场景归类到流程中.第三基于场 景拆分