B端作品集中如何做有效的项目分析？总监级干货来了！
在今天的作品集输出、外包项目汇报上，只展示界面、图例的做法是行不通的，还要加入文字说明，来表达你的设计思路（Design Thinking），俗称项目分析。
对项目分析应该写什么的疑问和抱怨非常多，有相当一部分设计师对应该怎么解释自己的设计是完全没有概念的，以为网上字写的多，专业名词、概念用的多的项目包装，就是优秀案例，并以它们为样本来学习。
所以今天的分享，就是理解项目分析是什么，以及如何有效进行 "分析"。
一、设计项目中的分析是什么
从事设计行业，就要正视一个根本性的问题，我们只是 “画图的 / 美工”，还是 “做设计”的。
首先我们理解不同平台对设计的解释：
- Wiki 百科：所谓设计，即“设想和计划，设想是目的，计划是过程安排”，通常是指有目标和计划的创作行为及活动。
- 百度百科：设计，指设计师有目标有计划得进行技术性的创作与创意活动。设计的任务不只是为生活和商业服务，同时也伴有艺术性的创作。
- ChatGPT：设计是一种创造性的过程，旨在解决特定问题或实现特定目标。
- 通义千问：设计的核心目标是通过理性思维和创造性方法，解决实际问题、满足需求、传达意图和情感、提升用户体验或创造出具有审美价值的作品。
总结起来，设计包含两个部分，即计划和实施。计划就是对设计的目标做分析，并对后续的实施方案进行策划。而实施就是使用对应的工具完成设计内容，并根据项目要求进行交付的过程。
不管在哪个领域的成熟设计，都包含这两个部分，比如服装设计师设计新品需要考虑时下潮流的趋势和风向，建筑设计师设计建筑需要考虑预算和安全性，品牌设计师设计 VI 需要考虑企业的文化和受众。如果缺少这些专业、严肃的思考过程，那么设计就是无根之木，大概率无法符合现实世界的需要。
什么是现实的需要？即需要设计解决的问题。
国内有一档节目叫 《梦想改造家》，很好得记录了室内设计师在计划和实施两个阶段的工作过程，从前期访问业主实地考察分析，到后期设计并解释如何解决现存问题、满足业主需求，推荐所有设计师一看。
“设计是用来解决问题” 的，这是学习设计师反复会听到的一句话，但相当一部分同学都会把它当成正确的废话。
因为在目前接触的工作环境里，设计的目标看起来和解决问题 “毫无关系”，只是老板、产品经理给出需求，然后你跟着做，接着再按他们的意见修改，你认为好的设计没被采纳，意见也不听等……
由此可以引申出一系列对环境的吐槽，总结自己是如何沦落成美工的，根本没有分析的余地。这是种巨大的误区，任何项目的设计都包含可以分析的对象和要素，问题在于设计师有没有定位这些问题而已。
先从一个理想的项目流程说起，首先老板/产品要做需求的制定，提供项目说明和原型，然后设计师要在这个阶段分析业务、用户、体验、竞品、交互、视觉的内容，然后再展开设计完成后续的交付。
在这个流程中，分析阶段第一步是先理解业务，也就是需求这么制定的原因，需要解决哪些业务问题，带来的收益是什么。比如做个审批流程，流程交互和状态很繁琐，设计师不能只看操作的流程不顾现实业务流程的逻辑。
比如审批的领导很多，每级都要过审，打回的话重新开始流程的规章是啥样的，决定了最终产品应该制定的功能和交互。不管拿到什么需求，分析背后的业务逻辑都是必不可少的，也是 B 端设计一定可以展开分析的部分。
因为 B 端项目不存在没有目的的需求，任何规划和构思都是围绕在特定的问题中展开的。可能很多设计师会说实际情况并不是如此，工作中碰到的需求要多离谱有多离谱，都是老板/客户/产品拍脑袋想的，没有任何道理。
如果是针对一些小细节，比如按钮位置、表格列数之类的，确实可以只由个人偏好决定。但只要维度变大，面对整个产品流程、模块、项目的需求时，这种情况就会越来越少。
作为设计师，业务分析中，并不只是纠结别人和我们的想法不一致或你不认可，而是搞懂制定需求的人所理解的业务和解决方式。即使没有已经开始运转、成型的业务，决策者也会有他们自己建立的思路和理解，只是很多时候提供需求时并不会和设计师解释。这需要设计师主动去问，搞这些决策的理由，这个过程同样也是分析的过程。
在最恶劣的环境下，需求方会拒绝和设计师解释需求，可能因为逻辑复杂懒的解释，或者前期工作过程中的矛盾积累（设计师一直唱反调，解释成本过高）。这种情况分析需求会变得困难，但不是背后的业务因素就不存在，要靠设计师发挥主观能动性去和相关人员沟通。
有一定经验的设计师，但凡有了项目的目标和对业务的理解，再结合产品需求、项目场景，就必然能思考后续设计工作中的目标是什么，会遇到的阻力有哪些。
工作目标即设计要实现的内容，有抽象的也有具体的。抽象就是解决某些问题，比如满足某业务的需求、更符合主流的设计、提高用户体验的交互等等。而具体的部分，就是要交付的工作内容，具体哪些页面、图标、标注、切图等。
工作目标是无论如何都会有的，而项目后续要面对的问题、阻力自然接踵而至，只要有一定工作经验的设计师都能分析出来，很多设计师其实已经分析到了但不自知而已。比如他们会到社交渠道吐槽：
- 需求给的不够清楚，产品没时间写 PRD 和整理字段
- 项目给的时间太少了，但是要设计的页面太多
- 项目前任用的规范一塌糊涂新项目根本不知道咋下手
- 客户喜欢的设计风格很奇葩，完全不想配合
- 开发说了要直接用开源框架不会按我的设计稿还原
- 流程太复杂，感觉用户根本就用不懂
这些不就是问题？不就是阻力？设计的过程，必然会有各种各样的难题，而设计师的任务之一，就是想办法解决设计上的难题，而不是指望别人什么都准备好了给你。
基于对问题的理解，才会有后面的解决方案，比如没有完整的需求，你可以自己快速输出原型评审建立需求，设计师时间少，那快有快的做法，前面规范混乱，你怎么根据项目流制定新的规范标准等等……
在多数 B 端项目中，项目背景、相关业务、产品需求三个要素就前期分析的核心内容，已经足够支撑设计师展开具体的设计，并对成果做出充分的关联和解释了。而理想项目流程中会提到的用户、体验、竞品分析等，在 B 端项目中从来都不是必需的。只有在上面三个要素分析中得出相关的结论需要用到它们，才会开展。
比如很常见的项目是靠客户领导拍板决定的，或者就少数人使用的工具，用户的研究可能只涉及一些简单的沟通，不需要开启完整的体验设计流程。而如果没有找到能访问的竞品，并不会有什么影响。解决自己项目产品、业务的问题和竞品有什么关系？只有在项目目标是直接要和竞品展开竞争，且竞品是用得到的前提下，才有竞品分析的意义。
以上都是前期分析的部分，只要完成分析并获得结论，那么到了实施阶段，交互、规范、布局、样式的制定，就应该都有清晰的逻辑和思路了。这和设计师本身的基础能力有关，只要熟练掌握相关技能，那么完成设计的过程肯定会去遵循某个逻辑脉络，而不是做到哪算哪。
比如全局框架制定中，怎么兼顾不同功能页面、操作的需求。设计风格定义中，以品牌的角度切入还是行业的特征。界面布局时怎么做更符合业务场景，组件前后排序的依据是什么等等。
在我们过去的改版案例中，对有给过对应的分析过程，这些就是实际项目执行过程中会考虑的东西：
实施阶段可以分析的内容是最多最杂的，很多初级设计师在这个阶段完全没有思路，唯一的原因就是基础能力不足，在应付视觉部分的工作就已经耗尽全部精力疲于奔命，那当然不会产生多余的想法。
比如从项目刚开始，设计师对自己应该怎么把界面有效做出来都没信心，后面的一些页面类型应该怎么做也完全没有概念，那么就绝对不会浪费时间去思考设计以外的问题，哪有闲工夫关注背后的产品逻辑和项目流程。
所以项目分析，是在设计师能做好设计的核心工作基础之上，对设计内容意义的探索。一个人只有在吃饱饭的时候会去探索生命的意义……
最后总结一遍，项目的分析，包含的内容有前期计划和实施两个部分。
计划阶段的分析重点是认识项目的背景，看懂产品的需求，调查分析需求背后关联的业务。然后总结设计的目标、任务，以及完成工作会遇到的阻力。思考的结论决定了进一步要完成哪些工作，是否有必要做用户调研、体验分析、竞品分析。
实施阶段的分析，则是完成交互、规范、布局、界面的思考过程，你在设计的过程中根据前面的结论怎么推导的，还是单纯自己对体验、权重、美感的理解而做的决策，都是分析。区别只是是否合理，能不能够说服别人。
以上囊括了一个 B 端项目会促发的常见的分析对象，除此之外还有很多可以分析的内容，可以理解成只要你工作涉及的每一个环节、事件，都有分析的空间，因为实践是靠思考去引导的，而不是随机发挥。
二、项目分析的输出方式
用意大利设计师马西莫·维涅利的话说：
“设计是对问题的有组织的解决方案……”
如果理解了项目的设计分析是什么，就会发现可以分析的东西实在太多了。对于项目的输出来说，最大的问题反而不是没有分析能写，而是全部写进去根本写不完。
所以项目包装之所以叫包装，不是纯粹做虚假的美化，而是要有目的性得控制对一个项目的展示内容。虽然你的设计可能非常专业，但如果你把所有细节都展示出来，那么这么琐碎臃肿的包装是不会让观看者满意的。
项目包装除了展示基本的界面视觉外，还有展示 —— 界面设计的过程和相关思路，是一个需要花时间去建立的解决问题的过程演示，且包含清晰的逻辑和前后顺序。
所以创建项目包装前，要先把整个包装的展示大纲建立起来，这个大纲可以用下面这样的顺序：
- 项目介绍
- 业务说明
- 设计目标/问题
- 用户/体验分析
- 竞品分析
- 风格分析
- 界面解释
首先介绍项目是什么，然后解释你对项目涉及业务的理解，设计的目标/问题的认识，如果涉及用户、体验、竞品的分析过程就做进去，没有就不放。接着展示根据前面分析的成果，解释设计风格是怎么来的，以及具体做完的每个页面布局、组件、细节有哪些特殊的考虑。
除了先定大纲外，也可以先用文字写一篇完整的介绍，解释设计经过哪些思考过程产出出来的，然后再去拆分它们的模块形成大纲。
再强调一次，大纲的目标是为了帮助我们筛选合理的分析内容和顺序，要建立包装的前后关联，而不是前后两个部分是完全脱节的，前面说前面的，后面说后面的。或者导致分析部分内容多出了一大堆没有用的废话，比如网上很多项目包装案例 “好为人师” 的解释专业名词、概念。
当然，上方只是最通用、简单的框架，不同项目完全可以产生不同的分析大纲，比如有的项目是业务驱动的，有的项目是政策驱动的，有的是竞争驱动的，那前面计划部分的关注重点肯定就不一样，这就导致需要展示的内容和顺序注定是有差异的。
在包含多个项目的作品集中，每个项目根据各自的特点建立的大纲，必然是不同的，这样的作品集看起来是合理的，而不是套用相同的模板复制出来的 “预制菜”。
还有一点，分析的大纲只是对分析内容脉络的整理，并不是整个作品集只包含这些内容。因为一个完整的项目输出分析只是一部分，还有实施的成果展示。在一些模块之间插入、拓展只展示成果的部分是合理的。
比如风格分析上，不管是对行业、用户、VI 还是情绪板的分析，都可以拓展出不同的设计成果，比如规范中的字体、色彩定义，制作的不同设计样例，或整理的组件、图标元素等。
穿插不同的成果展示，只要不太过度，就可以丰富和完善整个项目的包装内容。这才是项目包装的真实过程，而不是为了做长强行凑内容和字数，写一堆没有人看自己都嫌弃的分析内容出来。
在整理的过程中，如果出现逻辑不自洽的地方，可以修改分析的内容，也可以适当优化设计内容，让设计更好地结合思路做展示。这都是项目包装中不可或缺的一部分，只有最终逻辑自洽，内容合理，才能表现出作为设计师的专业性，而不是原项目很多解释不清、模糊的地方全都无脑堆砌进去。
基于这种思路完成的包装，设计必然会对它的认识更深入、全面，连带的收益是，在面试中面试官让你自己介绍一下这个项目，或者问你项目的设计思路，你绝对不会回答不上来只会当场阿巴阿巴……
想要更好得掌握这种建立项目分析框架的能力，可以多花时间去看大厂写的项目复盘和总结，整理这些内容的大纲，并分析他们的合理性，你就再也不会对项目分析和包装感到陌生和害怕。
结尾
项目的分析是设计师综合能力、专业性的反映，这部分的能力属于有就有，没有就没有。作品集会诚实反映这一点，想要获得长期的竞争力，就要系统提升专业技能素养，而不是就依赖作品集包装的模板、指导。
作者：超人的电话亭
想了解更多网站技术的内容，请访问：网站技术
