随着互联网产品的不断向前发展，“产品设计导向”一类的概念已经不仅仅限于大公司中，在往日越来越注重“短期效率”的小公司也都纷纷开始注重产品设计方面的建设。
所谓的“产品设计导向”指的是产品建设之前要围绕着产品的立项、目标用户等等去规划产品的功能点，明确产品核心价值；在产品上线之后，通过数据分析和功能反馈，发掘更多的需求，去规划下一步的”功能增删改“，将产品的设计方向引导到更正确的位置，提升用户留存率，延伸挖掘出产品更多的可能。
另一方面，从现在的设计环境而言，对所有的设计师既是机遇，又是挑战。大量的UI专用工具（Sketch、Principle、Flinto、Origami等）的出现，大大提升了产品前期的UI设计师的工作效率，所以现在“全链路思维”已经从刚出现时的“概念化思维”变成了“主流化趋势”。所以现在很多的UI设计师在站酷发布自己的作品的时候大部分都喜欢加入一些产品前期分析（功能设计、用户画像等）内容。
但是很多设计师的分析环节明显就是为了证明“有”而去“做”，缺少了真正的分析部分。给我印象很深刻的就是之前看到的一个二手房买卖的UI设计作品，典型用户画像里主流用户是：“男、七十岁、目标是给自己的儿子购买婚房”。实际上这种所谓的产品分析流程对于设计师而言是没有任何帮助的，只是从形式上走个过场罢了。
本篇主要讲述产品设计中的一些分析方法，范围从“个人练习式设计”到“团队合作式运作”，知识点大概有：空雨伞思维、文章大概六千字左右，建议阅读时间：15分钟。适读人群：初级产品经理、交互设计师、在工作中职能范围与产品规划有关的UI设计师、想要学习产品设计的新人（文中含有大量配图用来辅助观点，因此建议PC端阅读）。
产品运作流程概览
我遇到的比较普遍的问题是：很多设计师对于自己所在公司产品的运作流程并不是十分了解。这样会在你实际配合工作的时候感到无从下手。有的甚至于同一家公司的不同设计师对于产品设计方面的理解也不尽然相同。所以说要从浅到深的学习产品功能设计，就必须先理清当前工作的常规流程，例如常见的产品运作流程（如下图）
上面是一个相对规范的产品开发流程，实际上你在看到上述流程图后，对照自己公司的情况，会发现有一些岗位上的缺失。出现这种情况最大的原因是因为很多公司会把一些职能进行合并用来节省成本，现在仍然有大多数的公司并没有交互设计师的岗位，但是交互设计的职能不代表没有，而是被产品经理或者视觉设计师兼任了。你需要明确团队中各个人负责的职能部分，才能更好地提升沟通效率。
个人思考方法（一）：空·雨·伞
上面讲到了设计师的“全链路思维”现在已经成为了一种主流的观点，将来的前期的铁三角“产品经理、交互设计师、UI设计师”很有可能结合变成是“交互视觉二合一”甚至是“产品交互视觉三合一”的状态。所以现在很多的设计师开始尝试自己去DIY一个需求或者做ReDesign这样的设计，希望可以通过这样的方式完成自己跨领域能力的一个积累。但是当他们打开电脑的时候，大部分人会发现自己突然变得没有思路，从产品方向点确定到产品视觉产出之间出现了断层。
其实做过设计练习的人都知道，由于一些现实场景的不同，一些人在做设计练习的过程中会受到很多条件的局限，尤其是在孤立无援的情况下，你面对自己的练习作品往往会无从下手。当然，不同的场景下有不同的分析方法。
在团队协作的时候，分析方法要全面、严谨、反复推敲。
在个人练习的时候，分析方法要高效、直接、简化不必要的流程，以培养自己的分析能力为主，在这种场景下，空·雨·伞就是一个非常好的思考提升方法（如下图）
简单概述“空雨伞”思考方式：观察（事实） → 思考（内在） → 产出（解决方案）
运用在设计上就是：发现痛点 → 思考原因 → 提出解决方案。“空·雨·伞”因为简单、成本低、易上手，可以作为设计入门培养思考能力的一种方法，但是在使用空·雨·伞的分析方法时需要结合一定的具体调研（或者轻量级的用户研究）相配合，不然又会变成一味的“拍脑门儿”式的主观臆测，对于分析能力提升没有丝毫帮助。
个人思考方法（二）：逻辑树
逻辑树又称问题树、演绎树或分解树等。很多咨询公司分析问题最常使用的工具就是“逻辑树”。逻辑树是将问题的所有子问题分层罗列，从最高层开始，并逐步向下扩展。
简单来形容一下逻辑树：把一个已知问题当成树干，然后开始考虑这个问题和哪些相关问题或者子任务有关。每想到一点，就给这个问题（也就是树干）加一个“树枝”，并标明这个“树枝”代表什么问题。一个大的“树枝”上还可以有小的“树枝”，如此类推，找出问题的所有相关联项目。逻辑树主要是帮助你理清自己的思路，不进行重复和无关的思考。
如果你要运用逻辑树方法去分析产品，主要的一点在于学会细化拆解目标。
举个例子：
在2017年我创建了自己的个人站酷号，但在发布了一部分的文章之后，我开始意识到文章的可读性始终不高。在这个时候我们就可以按照逻辑树的分析方法去进行拆解分析，去发现自己提升的空间。
如上图，就是逻辑树最简单的一种场景应用。确定目标后向下进行拆分，拆分出三级逻辑树是比较容易的，甚至你可以沿着已经列出来的大纲继续深入细化，再拆分出更细更深层的各种提升点。
逻辑树分析法在个人作品中的主要作用是发散思维；在实际工作中的作用则是针对特定问题进行分析，理清思路。总而言之，是让你在分析的过程中更加有条理，避免重复思考。但是逻辑树分析也有一个缺陷，就是在逻辑树分析的过程中，根据现象分裂出子层级的步骤十分依赖你的认知能力，就如同做设计一样，当你感觉界面的视觉出现出题的时候，需要利用你学出来的知识去进行视觉优化，如果你对设计理论知识掌握程度并不是很强，那就不能采用逻辑树分析法解决问题。
总而言之，逻辑树分析法适用于对问题研究十分深入的情况下，如果你对当前的环境认知并不充足，那么就很容易走入歪路，跑偏主题。
实际项目：用户调研访谈
在一些实际项目中，用户调研是需求来源的主要渠道。提起用户调研，很多人会觉得这不属于UI设计师应该做的事情。其实行业逐渐规范的现在，用户调研、分析需求的能力也成为了衡量UI设计师能力的一个标准。现在的互联网产品种类繁多，从早期只做主流行业，到现在基本所有的冷门行业都有涉及；作为设计者而言，大多数设计师已经开始在设计的过程中心有余而力不足。
造成这种现象的主要原因为是因为随着行业的细分以及范围的扩大，我们距离用户的真实场景偏离太远，导致我们在设计中很容易理所当然的赋予给用户大量无用的东西。偏离了用户所需要的主要轨道。因此对于很多的设计师来说，学会了解用户以及分析需求成为了十分重要的事情。
然后整理了一下我在用户调研过程中的几点认知：
第一，保证调研的目标的准确性
我们需要明确，我们希望通过调研达到怎样的目的？（例如：提升部分页面转化率、收集用户对于产品不满意的地方、通过用户使用产品发现用户潜在的痛点）
第二，有目标的选择用户
一般来讲互联网公司都有收集客户反馈的部门，他们掌握着所有客户的反馈意见。我们在选择调研用户的时候，最好可以根据我们在调研行动确立初期拟定的目标去选择调研目标
第三，适当的准备调研内容
当我们确定了调研目标和调研用户之后，就可以根据现有状况去准备调研内容。调研内容一定是要在事先拟定好（开始调研之后根据实际情况进行改动）
一般市场调研细分的维度通常有四种，分别是：地理、人口统计、行为、心理统计。运用在互联网产品里面就更加的复杂。以B端产品为例：我们在调研中可能要把调研对象分为客户（老板）和用户（业务员）去进行不同情况的信息跟踪，而且根据产品的属性不同，需要提前预设好调研内容的侧重
第四，调研过程中
在调研过程中，我们可以适当结合上文讲述到的“空雨伞”方式去进行调研观察，收集用户需求（如下图）
在调研过程中，除了思考之外更多需要注意的是对用户洞察的记录与剖析，在记录用户行为的过程中，需要遵循“不干扰”、“不引导”、“记录客观”等原则，这样可以才可以保持用户行为记录的准确性。
第五，获取反馈整理结果
在调研结束后，我们应该产出一份完整的调查报告，按照本次调研预设目标进行整理，规划出合适的大纲，把调研收获转化为明确的产出，产出形式最好以报告（PPT、PDF），而不是口述或者微信消息，这两者之间差别很大~
需求归类：KANO模型
虽然说现在很多的公司都开始建立了用户体验类的部门，但是因为用户调研或者体验类的工作很难去量化产出。而且在大部分情况下当产品按照用户调研反馈的结果进行调整后，往往很少会出现我们幻想中的“逆袭”、“口碑急剧上升”，有时还会因为受到一部分用户观点的带偏导致产品口碑下降，用户表示不满；又或者会出现需求级规划混乱，重要功能反而后上线这种尴尬的情况。
所以这驱使着团队中负担“用研用体”职能的角色对用户需求进行正确的分类和排序
这个时候就可以运用到卡诺模型（KANO模型）。
KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。根据不同类型的质量特性与用户满意度之间的关系，狩野教授将产品服务的质量特性分为五类：
1.基本型需求
用户对企业提供的产品或服务因素的基本要求。是用户认为产品“必须有”的属性或功能。当其特性不充足(不满足顾客需求)时，用户很不满意；当其特性充足(满足用户需求)时，用户也可能不会因而表现出满意。对于基本型需求，即使超过了用户的期望，但用户充其量达到满意，不会对此表现出更多的好感。
例如对于网盘类产品来说，用户的基本需求是有快速的上传和下载。如果下载速度达不到用户的期望，则用户满意度将一落千丈。对于顾客而言，这些需求是必须满足的，理所当然的。对于这类需求，企业的做法应该是注重不要在这方面失分，需要企业不断地调查和了解顾客需求，并通过合适的方法在产品中体现这些要求。
2.期望型需求
提供该功能，用户满意度提高，如果不提供该功能，用户会感觉到不满。当然在这里要补充一句，这里的需求并不都是我们整理出的主观需求，也有可能是用户在使用的过程中产生的客观类需求，例如遇到不会的体验，需求得到响应时我们给的反馈
例如对于一些O2O类的产品，虽然做的都比较成熟，但是由于体量庞大的原因，偶尔也会受到糟糕体验，用户在受到糟糕的体验之后往往会期望能通过反馈得到心理上的安慰。例如携程（旅程预计时间偏差）、美团（酒店体验差）、饿了么（用餐体验差）等。在用户遇到这种糟糕体验之后，期望能通过投诉建议获得官方的反馈，那么官方把这种问题解决的越圆满，用户的满意度也会随之提高。
3.兴奋型需求
又称魅力型需求。指不会被用户过分期望的需求。对于兴奋型需求，随着满足用户期望程度的增加，用户满意度也会急剧上升，但一旦得到满足，即使表现并不完善，用户表现出的满意状况则也是非常高的。反之，即使在期望不满足时，用户也不会因而表现出明显的不满意。
4.无差异型需求
不论提供与否，对用户体验无影响。是质量中既不好也不坏的方面，它们不会导致顾客满意或不满意。
5.反向型需求
用户没有这个需求，提供后用户满意度反而会下降。
按照kano模型分析可以对收集到的产品需求进行分类，筛选掉一些不合理的需求。更好更有目的性的完成产品待办清单的记录。
后
对于设计师来讲，不管是个人设计练习还是团队项目，都应该掌握一定的产品需求收集和分析的方法。如果你真的下定决心要向交互设计、用户体验方向发展，那就更需要下定一些功夫去学习相关的知识，学会形成自己的思考方法。一开始可能会很痛苦很累，但是如果一味的试图走捷径，最后只会得不偿失。
作者： 千夜Ryan_Vision 来源：站酷
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务、UI设计公司、界面设计公司、UI设计服务公司、数据可视化设计公司、UI交互设计公司、高端网站设计公司、UI咨询、用户体验公司、软件界面设计公司
在日常工作中，身为设计师的我们时常有这样的情形：身兼多个业务，但大部分的业务都是小业务，业务方给的需求也是七零八碎的小需求居多。面对该情况设计师有时会觉得没有一点挑战，限制自己对美好设计，给用户创造美好生活的想法，总想要去搞个大新闻。
不妨回头看看小业务，自己真的对它了解了么？这里提供一种视角，小业务也可以做大视野的事。通过一个小业务的案例改版，讲述如何从小项目中出发。
曾经负责过一个基础模块支持：设计详情。它是设计师用酷家乐设计工具设计方案产出的载体。该模块在之前有过改版迭代，迭代对业务目标（留存活跃）的提升并不理想。那从哪里入手呢？
理清业务目标
挖掘用户需求场景
梳理产品功能
拆解设计目标
设计策略实施
验证迭代
相对于大业务（例如网站改版），小业务因为简单，其业务目标界定常容易被忽略。在日常设计中常会遇见设计师在不知道业务目标是什么、目标模糊、目标不正确的情况，直接从梳理小业务具备哪些功能直接入手，分析下现状问题后开始制定设计策略，这往往会导致设计出现解决不了关键问题、出现偏差情况。产品功能本身只是满足用户需求和实现业务目标的服务载体，只是策略的表象。理清小业务所承担的业务目标是前提，那么如何理清呢？
理清业务目标
小业务目标来自大业务目标，对大业务的业务目标进行一级级向下拆解后，即可获得小业务对应的目标。目标拆解需要遵循MECE原则，拆解方法包含：二分法、过程法、要素法、公式法、矩阵法。（tips：目标的拆解有一定难度，）
Dapp设计详情为例，在酷家乐大增长业务背景下，用户活跃和用户留存为核心的目标，设计详情处于设计路径的一个节点，拆解得到设计详情的5个主要业务目标：
设计详情-用户周活跃
设计详情-新用户留存
设计详情-老用户留存
设计详情-内容投稿数
设计详情-内容分享数
业务目标可分为2个类别：
第一类别：符合用户意愿，如活跃、留存，在满足用户需求的情况下可以自然达成；
第二类别：不符合用户意愿，如内容投稿、内容分享，用户不太会主动去完成，需要去创造动机，激励用户进行。
有小业务的业务目标后，第二步就需要给用户提供价值满足用户需求，以此来实现业务目标的达成。梳理清楚小业务服务了哪些用户需求是提供价值的前提，那如何获取用户需求场景呢？
1. 用户访谈——获取相关用户需求场景
用户需求场景可以帮我们清晰了解到用户使用产品的原因。用户需求场景可以一句话进行界定，包含四个关键要素，其中需求本身最为核心，需要挖掘出当前诉求和其背后的潜在需求。
“在【某环境下】，【某用户】做了【某事】来满足【某需求】”
用户访谈为了挖掘到更为深入用户需求场景的要素信息。以设计师入行年限分组（1-3年、3-5年、5年以上），每次分组访谈2-3个设计师。梳理出设计详情相关的8个需求场景
访谈信息整合如下
2. 规整用户需求场景
在业务访谈中获取的场景往往都是碎片化的，碎片化场景对设计指导容易出现偏差，需要把场景结构化，为后续的方案设计提供依据。我把获得的场景按照设计师设计流程进行规整，按设计前、设计中、设计后三个阶段进行划分。
以上梳理了设计详情相关的用户需求场景，再来看原设计详情只基础满足了资料管理和方案展示的2个单一场景，在设计师的整个设计流程中只占了一部分。从设计层面来看，该2个场景局限在方案设计大场景中，设计更多做的是对其方案设计操作的体验优化，在原有较好操作体验的现状下，其对给用户创造价值上没有很大增量。再从以上业务目标来看，2个单一场景很难去促使用户对内容进行分享和投稿。
在理清小业务的业务目标和需求场景后，下一步就是按照场景去梳理产品能力。
1. 小业务功能现状分析
老版app设计详情的功能进行初步的现状分析，设计详情包含渲染、图文编辑、图片管理、投稿、分享5个主要功能。从需求场景来看，多个场景无法实现，如营销、谈单；从业务目标来看，通过当前功能有较大的优化空间，如当前投稿很难让用户知道投稿有什么价值。
2. 产品能力梳理
分析现状发现功能不足以支撑用户需求场景，有获取功能2个方向：
挖掘现有能力：可以扩大梳理范围，从小业务所在的上一级业务到整个平台，一级级往上梳理场景对应的现有功能。
打造新能力：围绕场景，打造出新的功能
挖掘平台上现有能力，可对业务的能力价值最大化利用，与其他业务形成互通，实现1+1大于2的业务价值。亦可围绕场景打造新能力，可反推产品去发倔新功能。
以下是设计详情涉及所有场景的产品功能矩阵，从平台获取到了很多全新的能力，以及对原有的能力进行了能力拓展。
在梳理出产品能力后，需要通过设计策略把产品能力有效组织起来，让用户快速感知快速上手使用。设计策略推导自设计目标，那如何得到设计目标？
基于用户需求场景将行为事件拆分，提炼行为事件再推导出设计目标，再基于设计目标给出设计策略。
Dapp设计详情受制于移动端能力，只涉及设计详情中5个相关场景，其设计目标和设计策略的拆解结果如下
拆解出设计目标后，基于目标分析产品现状得到存在的设计问题。为什么要基于目标分析现状？首先需要明确什么是问题，问题是导致目标和现状不一致的原因。只有明确了目标才可以理性分析与现状存在多少问题。在日常中时常看到设计师会直接得到问题，很多情况是默认假设了一个预设目标，但这目标得到不严谨、不全面，容易导致得到的问题本身也出现偏差。设计策略基于设计目标或问题得出，其最终都来自设计目标。
对老版Dapp设计详情现状进行了分析，得到了问题
在上一步得到设计策略后，围绕着设计策略是设计方案。本段将不全部展开说明，只选3个关键点讲述设计方案的思考
1. 设计详情框架的设计
Dapp设计详情涉及5个场景的承载及产品功能繁多，设计三步思考：
第一步：简化功能认知，对功能结构化，以场景的维度重组织功能，并以场景打造功能集合的认知，建立场景能力区；
第二步：梳理场景共同涉及的内容，作为联系的载体承载场景的放置，设计详情中展示态的方案涉及到了5个场景中的4个场景
第三步：提取场景中即时性和高优先级功能，打造快捷功能区
框架如下
建立框架后，填充具体的能力和内容。如场景入口放置于底部，并根据场景优先级做了主次的区分。
设计详情框架建立后，打造细分场景中的设计
2. 营销获客场景设计
营销场景的设计，将营销组成拆分为可营销内容、营销的渠道、渠道内容展现三大类，就可以清晰去梳理出现有的功能，以及可从内容、渠道各自去拓展挖掘。内容和渠道清晰后，再传达各渠道提供的价值激励用户去触发行为。
3. 谈单场景设计
谈单场景关键在方案详情上，谈单面对不同情况，存在多种内容形式去展示方案。在上面内容梳理中最主要是3个内容：图文方案、全屋漫游、渲染图册。在方案详情中，头部承载了全屋漫游、图册，如图文方案过于繁琐可直接点击全屋漫游图进行讲解，亦可点击封面进入图册直接图片说明。图文详情加上了房间切换的导航，可快速切换到需要讲解的地方。
上线后数据平稳后观测，设计详情的周活提升了89%，每个场景下的功能数据都得到显著的提升（tips：有部分数据因技术原因没有采集到）。除了改版了Dapp侧的设计详情，后续对PCweb侧的设计详情进行迭代，同样起到不错的结果。数据的结果验证了方法的可行，并起到了积极的效果。
以上是我应用这套设计方法去做了块小业务优化，反向推动进入产品迭代，上线后取得了不错的成绩。在本次赋能后，对小业务中多了一些感悟
小业务是大业务的缩影，可以作为去赋能大业务前沿验证的实验田，大概率可以快速验证自己的想法，即使方向错了因为小业务改动影响面也小
因知识广度和深度的限制，不是所有设计师都可以一开始就可以把控大业务，小业务可作为打磨设计深度专业度，一些小业务的复杂度并不低于大业务
该设计方法同样适用于大业务，但方法是死的，不是所有情况都套用，得需要把握重点灵活应用
不要总想着搞个大新闻，在能力未被业务方认可时，小业务的赋能可以成为一个很好的发声口
不要轻视小业务，有可能是你根本还不了解
信息架构是产品的骨架。具体而言，就是一款产品有几个一级页面，以及支撑起整个产品的一级页面、二级页面各有几种内容样式。所谓一级页面，微信的“发现”页就是一个一级页面；在“发现”页点“朋友圈”，进去的就是一个二级页面。所谓内容样式，Banner 是一种内容样式，九宫格是一种内容样式，设置页面那种列表也是一种内容样式。
这样的信息架构，有什么价值？
01 信息架构的价值：掌控感与健康迭代
对用户而言，信息架构的主要价值在于掌控感；对产品而言，信息架构的主要价值在于健康迭代。
1. 掌控感
如果房间里很乱，到处都堆满了东西，常穿的衣服也找不到了，我们就很容易变得烦躁不安。相反，如果混乱的房间被收拾得很整洁，我们的心情也会随之变得愉悦起来。
这中间的原因是什么？
个人觉得，从原始社会到 21 世纪，我们人类一直生活在竞争中，所以一直在追求一种对生活的掌控感。这种掌控感，会让我们找到一种存在感和价值感，从而给身处竞争中的我们一种安全感。一个收拾得井然有序的房间，会让我们觉得一切尽在掌握中；一个胡乱塞满东西的房间，则会让我们觉得这个房间处于失控状态，从而引发烦躁不安。
一款 App，如果主要的几个一级页面也都塞满了各式各样的内容，那么用户通常也会感到烦躁不安。这是因为用户不能马上理出头绪，不能马上获得那种掌控感。另外，如果大的改版经常让用户体会到这种烦躁不安，用户就会对这款 App 感到不满和失望，甚至失去信心和期待。
所以说，信息架构的第一个价值，就是让用户始终有掌控感。
2. 健康迭代
产品的更新迭代，有时会出现“发福”和“微整形”的情况。这都属于不健康的迭代。
所谓发福，就是变得臃肿了，比如一级页面突然增加了很多内容样式。所谓微整形，就是和之前比有点乱套了，比如有的一级页面突然消失了、有的一级页面突然出现了、有些常用的功能突然找不到了，诸如此类。
一款产品，如果大的改版总是通过发福、甚至微整形的方式实现，用户就很难获得掌控感。
反过来，一个优秀的信息架构，是接近“冻龄”的。也就是说，不管产品怎么更新、怎么加新功能，都能简单如初，都能让用户马上获得掌控感。典型的例子是微信：微信已经加了很多功能，但整体给人的感觉依然是简单的。
这样的信息架构，很少发福，也几乎不做微整形，所以能让用户永远有掌控感，从而确保产品能够健康迭代。
02 怎样实现信息架构的价值
什么样的信息架构，能够实现“掌控感”和“健康迭代”？
其实参考答案刚才已经出现了，那就是接近冻龄的信息架构。或者更确切地说，是一种“以不变应万变”的信息架构。
这里的不变，是指信息架构看起来永远没有明显变化，永远都很简单。万变，是指不断新增的功能，不断变化的功能。
如何做到以不变应万变？一级页面和二级页面都很关键，其中最核心的是一级页面。这里也顺便抛一个问题：一级页面，用来干啥？
一级页面主要用来干三件事，分别是：提供掌控感、提供常用功能、提供小入口。也就是说，一级页面尤其要把掌控感给到用户，要让用户快速找到常用功能，同时还要为不常用的功能提供一个小入口。需要说明的是，这个理念可能不太适合一些商店类产品，比如淘宝这样的电商产品，所以仅供参考。
那如何完成这三件事？主要有以下四个要点。
1. 不要超过 4 个一级页面
4 个和 5 个，它俩之间存在微妙的区别。比如我们给手机号或银行卡号分段时，更喜欢每段最多分 4 个数字，而不是 5 个，直观对比见下图。
4 个还是 5 个
很多 App 的底部导航栏，也是只有 4 个Tab，即 4 个一级页面。受生活经验等因素影响，当我们看到 App 有 4 个一级页面时，内心或潜意识里可能会觉得：哦，4 个，还算简单，基本能记住；而当看到有 5 个一级页面时，可能会感到一丝压力：5 个啊，有点多了。
总的来说，我们更偏爱只有 4 个一级页面的产品，因为 4 个仍在简洁的范畴内，5 个就已经开始走向复杂。在《微信背后的产品观》这场分享中，张小龙也提到过：“微信保证只有 4 个底部 Tab。”
2. 不要超过 3 种内容样式
Keep 6.0 系列的“探索”页面有 5 种内容样式，显得很复杂。微信的 4 个一级页面中，“发现”和“我”页面只有 1 种内容样式，“微信”和“通讯录”页面只有 2 种内容样式（加上顶部的搜索框），显得非常简单，和 Keep 的对比如下图所示。
Keep 6.0 系列与微信的内容样式数量
像微信这种内容样式数量上的极简，可能很多产品难以做到。那么，我们不妨退而求其次，早期先从 1 种、2 种内容样式开始。后期加功能了，可以考虑第 3 种，谨慎考虑第 4 种，尽量不要增加第 5 种，因为一定会变得复杂。
大家可能会说，产品的功能很多，3 种内容样式不够用。
针对这种情况，只要逻辑上不存在大的问题（比如把“支付”放到“通讯录”页面），就可以尝试把不同内容合并成一种样式。微信在这方面就做得很好，大家可以参考它的设计。比如下图的“通讯录”页面，联系人上方那些内容，和联系人不是同一类内容，但它们共用一种内容样式——一个简单的图文列表。
微信“通讯录”页面：不同内容合并成一种样式
3. 不为二成需求，去打扰八成用户
产品设计里存在一个比较常见的问题，就是往一级页面塞很多内容或功能，其中有相当一部分是用户日常用不到的，这种设计容易让人觉得臃肿。比如 Keep 6.0 系列的“运动”页面，就用了较大空间来推荐付费计划和运营活动，如下图所示。
用较大空间来推荐付费计划和运营活动的 Keep 页面
相信有相当一部分用户是不需要这些内容的，所以这其实也是一种打扰。这种打扰会影响到这些用户对这个界面的掌控感。
这种现象有两个可能的原因。一是企业担心用户不用这些功能，所以就在一级页面用很多空间来展示它们，Keep 的例子应该属于此类。二是有部分用户提建议，所以企业就加了这些功能。
关于第一个原因，个人观点，有些功能本身就属于二成需求，在一级页面占用太多空间不仅改变不了这个现实，还会对用户形成打扰。
关于第二个原因，个人看法，用户的建议通常只代表个人立场，而企业至少要代表大部分用户的立场。比如，网上就有人建议微信在朋友圈加一个屏蔽别人的功能，实际上微信有这个功能，只是一直隐藏，没有放出来——因为用的人少，它属于二成需求，放出来的话会对八成用户形成打扰。
总的来说，理想情况是接受现实、尊重规律：是八成需求就提供八成空间，是二成需求就提供二成空间。具体参考如下图所示。
是八成需求就提供八成空间，是二成需求就提供二成空间
4. 尽量不在标题栏使用 Tab 或下拉框，增加维度
这其实是张小龙分享过的一个观点，我个人很赞同，就直接引用一下。下面直接看两个例子。Keep 6.0 系列的前三个一级页面，标题栏都使用了 Tab，就显得内容很多，有点复杂，如下图所示（仅展示前两个）。
使用了 Tab 的标题栏
微信中拥有标题栏的前三个一级页面，其标题栏都没有使用 Tab 或下拉框，就显得简单、内容少，如下图所示（仅展示前两个）。这也是微信保持简单的一个重要原因。
没有使用 Tab 的标题栏
结语
一般情况下，产品都需要更新迭代：增加新功能，完善旧功能。
用户则是一个矛盾体：一方面对新功能和新事物怀有好奇心；另一方面又希望每次打开常用的产品时，都有一种回到家一样的熟悉感和一种家里井然有序的掌控感。
好的做法，就是类似微信那样：尽管加了新功能，但是看起来没有明显变化。也就是说，以“不变”的信息架构，来应对万变的功能。
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
当你拿到一份 PRD 需求文档 时，你在想什么？
好像所有字都认识，怎么放在一起变成最熟悉的陌生词？
好像对方在侃侃而谈，而你只是用微笑来表达那不知所措的尴尬？
还是，一目十行，了然于心，拿出你的看家本领，迎面而上！
……
看过形形色色的 PRD 文档，有纯文字版的，全篇找不到一张图片，估计担心会影响设计师创意无限的大脑发挥；也有看过图文结合的淋漓尽致的 PRD 文档，甚至有直接上手 sketch 的，原型都画好了；当然也有直接丢给你一张图，让你照着做的…
所以，面对这些不同特点的 PRD 文档，设计师该从哪里开始呢？这真是一个好问题，期待这篇分享能助你拨开迷雾。
需求分析，直白的说，就是要找出二个 W 一个 H：
一个需求，从用户需求到产品需求，再到产品功能，当中会经历一个可长可短的过程。不管这个时间如何计算，无可避免的是，它一定会消耗资源。而需求分析的进行，可以在一定程度上避免资源的浪费。
1. 识别伪需求，挖掘真需求
分析需求的过程中，需要去了解需求的背景，用户真实的诉求是什么。很多时候，“所谓需求”，是用户装饰后的“解决方案”。大部分的用户是用他“已知的事物”来阐述“未知或难以描述的事物。
2. 是否符合产品定位？产品目标？目标用户？
存在即合理，所以并没有所谓真正“无理的需求”，而是这个需求，是不是和你的产品是对齐的，再好的锅，它也需要一个合适的盖。需求也是同理，只有当需求与产品定位、目标以及目标用户是一致时，才能让产品发挥最大的价值，比如当初的来往和现在的钉钉。
3. 需求的价值
需求或许不一定有价格，需求必有其价值，不然它就是一个无意义的需求。当用户提出一个需求时，必有其想要表达或想获得某种东西，即使它可能很微小。
4. 是否有更好的解决方案
不只是用户会提出装饰后的”需求“，PM/PD 同样也会。这很正常，人都会基于自己的自身环境，受教育程度，对事物提出自己的看法以及他认为好的解决方案。
但对设计师来说 ，需要多走一里，向前一步，看看有没有更好的解决方案。而更好的方案，需要设计师更透彻的了解需求。当然这不是硬性要求，只是要考虑多种的可能性。
比起要了解你接到的需求，先了解你的产品，是一件很有必要的事情。需求只是产品的某个部分，要先把握全局，才能更好设计。不然，很容易一叶障目，错误评估需求。
或者应该说，对产品进行任何改动或优化，都要基于对产品认识上进行的。
需求分析时，设计师要了解到，需求提出者、需求来源、需求背景、目标用户、解决问题、产品方案、产品目标，以及分析后整体需求的优先级。
1. 需求提出者
PM/PD，偏业务类需求 —— 产品需求
设计师大部分的需求来源，都是来自 PM/PD， 而这类需求基本上经过了 PM/PD 的过滤，并且比较偏向商业业务方向
产品用户 —— 用户需求
用户的吐槽、建议、反馈，用户从自身出发，提出希望被满足的功能
设计师，偏体验交互类需求 —— 设计驱动的需求
设计师通过设计走查，主动与用户沟通和用户调研等方式，获取得到的需求
BOSS 层需求 —— 老板需求
这是特殊的需求，充满机会与陷阱。
这里是四类比较典型的需求提出者，不同的提出者对需求的着重点会有不同。
2. 需求来源
需求的来源，其实是多面的，和产品的目标用户息息相关。目标用户在哪，需求就会在哪产生。了解需求的来源，也有助于需求的评估，后期如果需要做用户研究，也能对此提供帮助。
3. 需求背景
需求背景，是需求产生的环境，比如用户是在什么情况下遇到问题，使用场景是什么，用户路径是什么
了解用户碰到的痛点和痒点是什么，如果有可能，可能自己去走一遍用户的使用路径，亲身体验用户碰到的问题。有些时候当你真正痛过了，你才会知道这真的是一个坑。
4. 目标用户是谁
需求所服务的目标用户是谁，这很重要。遇到问题是目标用户，还是边缘用户，是大部分用户的诉求，还是一小部分用户的诉求
需求的目标用户需要与产品的目标用户对齐，不然可能这个需求不错，但却是其他产品的需求，与产品不对口
特别是产品本身涉及多角色的用户，比如 B 端中台的产品。所以，明确服务的目标用户是谁，可以更准确去对焦需求，对症下药，方可药到病除，不然可能是药到命除…
5. 解决问题
需求解决了什么问题，这是一个要问的问题。当你花了时间在讨论需求是什么时，但是如果需求并没有解决用户的根本问题，其实就是在浪费时间 。
解决什么问题，是需求的价值所在。很多时候，做了很多需求，其实不一定真的了解需求本身是为了解决什么问题，而这种不了解会让设计师对需求的了解是停在浅水区。
6. 产品方案
当你接到需求的情况下，一般也会接收到提出者的解决方案。这时，要去验证产品方案能否有效解决用户的问题，这与上一步「解决问题」是一个相互验证的关系。
产品的方案，不等于设计方案。不要对产品方案照搬，最后只做了界面的美化者，设计师要更深度去考虑整体产品的交互、体验以及用户心智。条条到路通罗马，天无绝人之路，你要记得转弯。
7. 产品目标
需求完成后，期待是会达到什么样的目标呢。这个目标与产品目标是一致的吗？
解决问题、产品方案、产品目标，这三者是存在强相关的关系，并且互相影响。
需求分析是不可跳过的一环，打开 Sketch 之前，设计师需要的是理清需求，找出疑惑点，你疑惑的地方，用户可能同样会遇到，如果设计师不清楚，也请不要将这样不清不楚的设计呈现给用户。
文章来源：优设 作者：箴盐设计
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
做设计师这些年，我一直有个类似“闪电侠”的标签——就是在保证一定质量的情况下，出活贼快。这个特质最大的好处就是每天可以给自己腾出多一点时间做别的，比如我写文章学习（打wangzherongyao），这点哪怕是血汗工厂或没事儿也要996的福报厂也适用。同时它也是不当狗腿子也能获得不错绩效（认可）的一种特质。
今天这篇脱离理论派纯实用性的和大嘎聊聊：如何提升需求分析及上手能力，降低返工率。
和设计师打交道的4个最重要的角色方：产品经理/开发/你的直属老板/你的组内设计成员，每个人都有自己的脾气/处事方式以及鸡血程度，每个人也都带着不同的目的性在做事情。磨刀不误砍柴工，先了解合作方，再了解他们提需求的目的，会让你更快get到正确的需求点。
举个例子，估计大家都遇到过热衷改需求的产品经理，昨天图出了一半，今天他又要改了！
很多铁汁这个时候会抑制不住掀桌的冲动去直接讨伐产品经理，但实际上建议大家先了解更改需求的原因是什么再做打算。比如：是不是他们老板临时又下达了新的旨意？如果是的话是不是建议他们在和老板确认完需求后再提交设计，又或者可以直接拿统计工时和prd返工率导致的整体排期拖延直接与他沟通问题严重性。
最后就算实在不行，建议大家对自己的上级进行清晰的问题反馈，一个好的上级是可以很妥善帮大家解决这些跃级不好解决的问题。不建议在群里硬杠或者直接向他们的老板反馈，因为这样容易制造长期对峙的状态对于我们做任何事情都是百无一利的，所有的交流都尽量以和平相处为主。
再举个例子，老板让铁汁你做个设计自驱的产品优化设计方案ppt。
上手之前，先分析下你老板要这个ppt干啥子。
大部分情况下类似的这种产出目的性只有一个：这是给老板的老板看的，让他觉得设计团队有在好好积极的干事情，且还干出了点东西。那么其实这个ppt的真实需求方其实不是你的老板，而是你老板的老板（业务线负责人：一个可能压根看不懂设计的人）。这个时候如果你把ppt的内容重心放到了设计的细节以及ppt的美化上，就很容易躺枪，也就是累了个半死还不落着好（真实发生在我周边的案例）。
因为看不懂设计的人对于这些东西是没有太大感知的。相反，如果你能注重设计与数据的结合，多放一些前后对比案例以及针对用研去做的设计提案就会是完全不同的效果。
在开始着手设计前，我们可以先对需求进行基础分析与规划。首先定义好需求的量级/优先级以及排期，接下来就需要根据需求的实际情况判断需要参与的上中下游成员。
举个例子，这里我们收到了一个需求：一个直播app需要在原有功能基础上增加一个直播间的类型（情感解忧节目）。
那么我们先快速过一遍prd原型，超过3个核心页的明显体验改动，外加上N种小细节状态以及三级页。基本我们可以判定它属于一个中型量级的页面，排期紧急的话大概在3天左右。从原型上看，应该会涉及到交互/ui/运营推广设计/前端+开发这种人员组合。
那么在明白了人员配置之后，需要申请运营推广设计组帮忙设计的部分就需要提前告知给相应的负责人进行提前排期，而对于一部分页面的具体实现方式在不确定的情况下提前和对应技术铁汁沟通。
再举个例子，这里我们希望延续在app里面沉浸式黑色面板的体验，所以新发布的故事也希望做成和常规白色不一样的深色面板。
但实际上这个新故事发布页面属于非native原生的H5页面，是由前端铁汁操刀的，实现起来并不像原生页面可以直接设置默认背景色。这种时候很多技术铁汁选择直接忽略这个问题去开发，或者直接告诉你进页面的时候会有一道白闪，巴特，解决不了。接下来设计师们很多也会选择返工重改白色版本。
但更且高质的解决方法建议大家先看下竟品和自身app里是否有同样情况解决问题的案例，抽出来摆在他们面前就会比较有说服力，通常情况下不是特别难搞的他们也会争取搞定，你也减少了返稿，保障了用户的体验。
这里很多铁汁可能会说，和他们bibi半天也许最后的结果还是得改稿子，还不如我直接改了来得快。因此这个问题就又回到了第一点，你得先了解你合作方/需求方的秉性，在决定效率优先的前提下这个沟通是否有必要，且控制在多长的沟通时间范围内是性价比最高的。
很多铁汁想知道该用什么样的方法论去控制自己的输出，好达到专业规范且能很好说服他人的目标。其实无论是分析需求优先级的kano模型/大项目问题挖掘的双钻模型/尼尔森十大交互原则还是设计排版的那些格式塔原理，在做真枪实战中你会发现它们就像一个上真战场厮杀的战士带了把华丽的歌舞剧假刀的感觉。
这个原因很简单，因为他们都是通用方法论。实际工作中我们遇到的项目通常紧急且各有不同的诉求，而通用方法论只是我们的一种知识储备，在我们上手设计时会对我们的设计产生基础的正向引导，帮我们规避一些低级的体验错误，比如莫名其变的交互手势设计or和WCAG色值对比度偏差很大的视觉设计。
但如果我们想要最快速精准的对症下药，那核心武器只有一个——做竞品分析。这里的竞品不是说和你家产品一模一样商业模式的才算，哪怕你家是0-1的产品创新，没有垂直类竞品可以参考，也可以挖掘到很多相似的同类竟品分析细节。
在分析竞品的ui和交互的同时你可以快速get到被验证过的设计方案，还可以补充很多“不成文的”经验，比如为什么有的细节大家都是这样的设计，去度娘搜索一下原因，保证你的经验值又增加了1个百分点。同时拿线上产品多次试验过的经验来做方案参考是相对风险性低的一件事情，这个对于产品和技术也有一定的说服力。
但这里有个特别需要注意的事情，很多铁汁做竞品分析做着做着就变成了抄竟品？
其实没有什么创新是真正的从0-1，哪怕汽车的创造也是建立在马车基础上的，因此该如何有效的做竞品分析，青出于蓝而胜于蓝，是个非常大的课题。
这里简单来说分为3步：
文章来源：彩云译设计 作者：Nana的设计锦囊
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
这周我们进行下一步讨论：如何对分析结果进行选择。
首先我们需要了解互联网产品研发团队的各个角色分工。
对于初期的产品研发，可能公司没有团队概念，所以从想法到设计到开发，都由一个人搞定；
等到公司发展差不多，自己成了领导，就可以对各个角色和分工有所分组，也就是大多数初创公司的分配情况：
随着公司业务的发展，产品经理需要处理越来越多的业务规划任务，所以从业务视角和用户视角将之前的产品经理岗位职责进行划分：
所以最终的角色分配是：
再大一点的公司，会增加项目经理岗，把之前产品经理负责的职责拆出一部分，这部分职责就是项目管理。所以角色分配最终是：
了解了团队角色分工，只是让产品得到了更专业的技术支持，接下来我们需要切入正题：对交互方案进行评价筛选，筛选的标准可以围绕：有用性、易用性和吸引力展开。
1. 有用性：
方案是否同时满足业务目标与用户体验目标，为了更好理解，大家可以看下如下事例：
如果所有的线上商品都发顺丰快递，对于用户来讲，用户体验当然很好：够快。但是从业务目标来讲，这是不可取的，毕竟快递不能独顺丰一揽。所以这个想法没有顾及到业务目标，是不可行的；
很早之前，有过 Open ID 的概念：用一个 ID 就可以登录多个网站。但是接入了 Open ID 的网站，对于自身产品的登录注册就会有一定影响，所以这个想法不了了之。
后来 Facebook 和 Twitter 开放了自己 ID，可用这两个账号进行其他网站登录。于是国内很多网站也开始支持微博、微信、QQ 账号登录。
这样降低了用户注册成本，而且也获得了一定收益。所以这是个不错的想法，但是对于一些需要获得用户信息的产品可能不太适合，所以视情况而定。
总结来说，有用性就是要满足产品利益与用户利益。毕竟如果只是很好看，最多也就只能被称作一个艺术品。
2. 可用性
所谓可用性就是用户容易理解，使用起来没有障碍，并且感受良好。
关于产品可用性，大家可以去了解下鼎鼎有名的尼尔森十大可用性原则。
3. 吸引力
所谓吸引力就是产品有打动人、超越用户期望值的细节。
关于吸引力设计，大家可以了解一下 KANO 模型，KANO 模型定义了三个层次用户需求：
基本型的需求：用户认为产品必须有的功能属性，如果没有，用户会不满意；如果有，用户会觉得理所当然。这个层次的需求，还谈不上用户满意与否；
期望型的需求：不是产品必须的功能属性，可能用户自己也不清楚一些功能，但是又恰恰是用户希望看到的。如果这种需求实现得越多，用户会越满意；如果没有满足用户这种期望值，用户会不满意；
兴奋型的需求：对于一些无关紧要的功能需求，如果产品满足了这些需求，用户会非常满意，从而提高用户忠诚度，最后把它推荐给好友。
通过以上标准对方案进行分析，最后涉及到决策，不管哪种类型的角色分配，都需要进行决策，这里可分为以下两种：
个人决策：对于最后的方案选择，由一个人进行「拍板」，这种决策方式速度快，容易抓到事情本质；但是缺点是缺少了团队氛围，不太建议这种一人说了算的决策方式；
群体决策：这种决策方式团队氛围会好很多，通过发表每个人的看法，最后得到合理的、正确的、富有创造力的解决方案；但是缺点就是因为参与者多，需要比较长的时间进行决策，即使这样，也建议使用这种决策方式，不过前提是需要事先确定一个明确的负责人，这样可以对决策后果进行负责。
从小的方面来讲，决策也可分为：
内部 review：设计的作品先在团队内部进行过稿，然后修改，切忌全部做完才进行 review，需要做完一步就进行内部讨论；
外部评审：以会议的形式展开，召集大家对作品进行讲解。
确定了最终方案后，我们需要把它推销出去，具体有以下几种方法：
将思考过程可视化：可以采取上一篇文章的表格分析方式，让设计更有说服力；
自己人效应：对自己人说的一些建议方法更加信赖；
准备一份PPT：展示设计思路；
讲一个故事：以用户的某个使用场景开头，一步步讲解用户的使用情况，慢慢过渡到产品功能设计；
掌握必要的演讲技巧和表达能力：包括口头和文字表达能力，通过这两种表达理清思路，也更好让别人进行反馈。
最后想说的一些话：
作为交互（设计）专业人士，我们需要把握好一个尺度：什么该坚持，什么不该坚持，对于一些专业方面的东西，我们需要团队内部人员都坚持，这样目标会更清晰；但是对于一些比较小的设计细节，有时候可以适当妥协。
如何对设计需求分析结果进行选择：
文章来源：优设 作者：Pony欧尼的日常
如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里
完整的 UI 设计流程到底是怎样的？从需求到产品上线，要经历多少个阶段，每个阶段有哪些应该掌握的基础知识，本次优设独家专题为你从零开始梳理出 UI 工作流程，适合新手阅读学习。
本篇工作流程第一节：需求分析。
UI 设计工作，包括 APP 设计、网页设计、小程序设计等方面。而一个产品完整的 UI 设计流程，是指拿到一个新的项目需求后，从设计思考开始，产品前期分析，设计产品，设计评审，用户测试，直至产品上线。
我们的工作流程如下：
以上的流程都是与设计师密切相关的内容，我们的关注点不能只有视觉效果，孤立的设计容易脱离产品，反复修改，因此前期分析与后期支持都值得我们重视。
产品立项后的第一阶段是需求分析阶段，当我们拿到一个新的需求时，首先要了解的就是产品的需求是什么，了解市场背景、产品定位、概念，客户的需求是什么。
一般来说，我们接到的需求分为三类：全新产品、现有产品新增功能、产品改版。
前期分析阶段中，需求方主要是与产品经理进行沟通，产出文档有三种：
有了数据参考来源后，我们就能从五个纬度分析产品。
1. 产品分析
市场背景、产品业务、现有产品各项数据。
2. 用户画像
3. 需求确认
产品需求主要是为了满足用户或企业价值，所以一定要确认重要且紧要的需求内容是什么，什么功能和内容暂时不需要做，什么功能和内容放在后期做，因此设计时也要考虑产品未来的扩展性。
4. 逻辑流程
5. 竞品分析
和国内外同类产品进行比较分析，知己知彼。
竞品选择，从两个方向出发：
相关教程：《视觉设计师如何做竞品分析？来看这份超全面的指南！》
最后，比起产品经理来说，设计师在这个阶段能获三个信息：
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务。
如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里
完整的 UI 设计流程到底是怎样的？从需求到产品上线，要经历多少个阶段，每个阶段有哪些应该掌握的基础知识，本次优设独家专题为你从零开始梳理出 UI 工作流程，适合新手阅读学习。本篇工作流程第一节：需求分析。
UI 设计工作，包括 APP 设计、网页设计、小程序设计等方面。而一个产品完整的 UI 设计流程，是指拿到一个新的项目需求后，从设计思考开始，产品前期分析，设计产品，设计评审，用户测试，直至产品上线。
我们的工作流程如下：
以上的流程都是与设计师密切相关的内容，我们的关注点不能只有视觉效果，孤立的设计容易脱离产品，反复修改，因此前期分析与后期支持都值得我们重视。
产品立项后的第一阶段是需求分析阶段，当我们拿到一个新的需求时，首先要了解的就是产品的需求是什么，了解市场背景、产品定位、概念，客户的需求是什么。
一般来说，我们接到的需求分为三类：全新产品、现有产品新增功能、产品改版。
前期分析阶段中，需求方主要是与产品经理进行沟通，产出文档有三种：
有了数据参考来源后，我们就能从五个纬度分析产品。
1. 产品分析
市场背景、产品业务、现有产品各项数据。
2. 用户画像
3. 需求确认
产品需求主要是为了满足用户或企业价值，所以一定要确认重要且紧要的需求内容是什么，什么功能和内容暂时不需要做，什么功能和内容放在后期做，因此设计时也要考虑产品未来的扩展性。
4. 逻辑流程
5. 竞品分析
和国内外同类产品进行比较分析，知己知彼。
竞品选择，从两个方向出发：
相关教程：《视觉设计师如何做竞品分析？来看这份超全面的指南！》
最后，比起产品经理来说，设计师在这个阶段能获三个信息：
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务。
1.1 什么是业务需求
业务需求是企业为了达到某些目标和某种目的而制定的。它代表着企业希望下一轮产品的迭代能带来什么收益，所以企业和 PM 在制定需求时必须谨慎且方向清晰。在工作中，交互要分析拿到的业务需求是否合理，所以就要理解在业务需求中的一些基本元素：
拿到需求首先就要分析，定位是否清晰，属于技术类、数据类、设计类等中的哪一类，筛选所有需求中哪个更重要，然后再去做相应的工作。
1.2 什么是业务目标
蓝蓝 http://www.lanlanwork.com
