设计师应该学习的需求分析方法

篇首语

随着互联网产品的不断向前发展，“产品设计导向”一类的概念已经不仅仅限于大公司中，在往日越来越注重“短期效率”的小公司也都纷纷开始注重产品设计方面的建设。

所谓的“产品设计导向”指的是产品建设之前要围绕着产品的立项、目标用户等等去规划产品的功能点，明确产品核心价值;在产品上线之后，通过数据分析和功能反馈，发掘更多的需求，去规划下一步的”功能增删改“，将产品的设计方向引导到更正确的位置，提升用户留存率，延伸挖掘出产品更多的可能。

另一方面，从现在的设计环境而言，对所有的设计师既是机遇，又是挑战。大量的UI专用工具(Sketch、Principle、Flinto、Origami等)的出现，大大的压缩节省了产品前期的UI设计师的工作效率，所以现在“全链路思维”已经从刚出现时的“概念化思维”变成了“主流化趋势”。所以现在很多的UI设计师在站酷发布自己的作品的时候大部分都喜欢加入一些产品前期分析(功能设计、用户画像等)内容。

但是很多设计师的分析环节明显就是为了证明“有”而去“做”，缺少了真正的分析部分。给我印象很深刻的就是之前看到的一个二手房买卖的UI设计作品，典型用户画像里主流用户是：“男、七十岁、目标是给自己的儿子购买婚房”。实际上这种所谓的产品分析流程对于设计师而言是没有任何帮助的，只是从形式上走个过场罢了。

本篇主要讲述产品设计中的一些分析方法，范围从“个人练习式设计”到“团队合作式运作”，知识点大概有：空雨伞思维、文章大概六千字左右，建议阅读时间：15分钟。适读人群：初级产品经理、交互设计师、在工作中职能范围与产品规划有关的UI设计师、想要学习产品设计的新人(文中含有大量配图用来辅助观点，因此建议PC端阅读)。

产品运作流程概览

我遇到的比较普遍的问题是：很多设计师对于自己所在公司产品的运作流程并不是十分了解。这样会在你实际配合工作的时候感到无从下手。有的甚至于同一家公司的不同设计师对于产品设计方面的理解也不尽然相同。所以说要从浅到深的学习产品功能设计，就必须先理清当前工作的常规流程，例如常见的产品运作流程(如下图)

上面是一个相对规范的产品开发流程，实际上你在看到上述流程图后，对照自己公司的情况，会发现有一些岗位上的缺失。出现这种情况最大的原因是因为很多公司会把一些职能进行合并用来节省成本，现在仍然有大多数的公司并没有交互设计师的岗位，但是交互设计的职能不代表没有，而是被产品经理或者视觉设计师兼任了。你需要明确团队中各个人负责的职能部分，才能更好地提升沟通效率。

个人思考方法(一)：空·雨·伞

上面讲到了设计师的“全链路思维”现在已经成为了一种主流的观点，将来的前期的铁三角“产品经理、交互设计师、UI设计师”很有可能结合变成是“交互视觉二合一”甚至是“产品交互视觉三合一”的状态。所以现在很多的设计师开始尝试自己去DIY一个需求或者做ReDesign这样的设计，希望可以通过这样的方式完成自己跨领域能力的一个积累。但是当他们打开电脑的时候，大部分人会发现自己突然变得没有思路，从产品方向点确定到产品视觉产出之间出现了断层。

其实做过设计练习的人都知道，由于一些现实场景的不同，一些人在做设计练习的过程中会受到很多条件的局限，尤其是在孤立无援的情况下，你面对自己的练习作品往往会无从下手。当然，不同的场景下有不同的分析方法。

在团队协作的时候，分析方法要全面、严谨、反复推敲。

在个人练习的时候，分析方法要高效、直接、简化不必要的流程，以培养自己的分析能力为主，在这种场景下，空·雨·伞就是一个非常好的思考提升方法(如下图)

简单概述“空雨伞”思考方式：观察(事实) → 思考(内在) → 产出(解决方案)

运用在设计上就是：发现痛点 → 思考原因 → 提出解决方案。“空·雨·伞”因为简单、成本低、易上手，可以作为设计入门培养思考能力的一种方法，但是在使用空·雨·伞的分析方法时需要结合一定的具体调研(或者轻量级的用户研究)相配合，不然又会变成一味的“拍脑门儿”式的主观臆测，对于分析能力提升没有丝毫帮助。

个人思考方法(二)：逻辑树

逻辑树又称问题树、演绎树或分解树等。很多咨询公司分析问题最常使用的工具就是“逻辑树”。逻辑树是将问题的所有子问题分层罗列，从最高层开始，并逐步向下扩展。

简单来形容一下逻辑树：把一个已知问题当成树干，然后开始考虑这个问题和哪些相关问题或者子任务有关。每想到一点，就给这个问题(也就是树干)加一个“树枝”，并标明这个“树枝”代表什么问题。一个大的“树枝”上还可以有小的“树枝”，如此类推，找出问题的所有相关联项目。逻辑树主要是帮助你理清自己的思路，不进行重复和无关的思考。

如果你要运用逻辑树方法去分析产品，主要的一点在于学会细化拆解目标。