B端作品集中如何做有效的项目分析 ？总监级干货来了
！

在今天的作品作品集输出、外包项目汇报上，集中监级只展示界面、有效图例的目分做法是行不通的
，还要加入文字说明
，析总来表达你的干货设计思路（Design Thinking）
，俗称项目分析 。端的项

对项目分析应该写什么的集中监级疑问和抱怨非常多，有相当一部分设计师对应该怎么解释自己的有效设计是完全没有概念的，以为网上字写的目分多 ，专业名词  、析总概念用的干货多的项目包装，就是端的项优秀案例，并以它们为样本来学习 。

所以今天的分享
，就是理解项目分析是什么，以及如何有效进行 "分析"
。

一 、设计项目中的分析是什么

从事设计行业 ，就要正视一个根本性的问题 ，我们只是 “画图的 / 美工” ，还是 “做设计”的 。

首先我们理解不同平台对设计的解释 ：

1. Wiki 百科
   ：所谓设计 ，即“设想和计划，设想是目的，计划是过程安排”
   ，通常是指有目标和计划的创作行为及活动 。
2. 百度百科 
   ：设计 ，指设计师有目标有计划得进行技术性的创作与创意活动。设计的任务不只是为生活和商业服务，同时也伴有艺术性的创作。
3. ChatGPT：设计是一种创造性的过程，旨在解决特定问题或实现特定目标。
4. 通义千问：设计的核心目标是通过理性思维和创造性方法 ，解决实际问题、满足需求、传达意图和情感 、提升用户体验或创造出具有审美价值的作品。

总结起来 ，设计包含两个部分，即计划和实施。计划就是对设计的目标做分析 ，并对后续的实施方案进行策划 。而实施就是使用对应的工具完成设计内容 ，并根据项目要求进行交付的过程。

不管在哪个领域的成熟设计，都包含这两个部分，比如服装设计师设计新品需要考虑时下潮流的趋势和风向，建筑设计师设计建筑需要考虑预算和安全性 ，品牌设计师设计 VI 需要考虑企业的文化和受众。如果缺少这些专业 、严肃的思考过程，那么设计就是无根之木，大概率无法符合现实世界的需要。

什么是现实的需要
？即需要设计解决的问题 。

国内有一档节目叫 《梦想改造家》，很好得记录了室内设计师在计划和实施两个阶段的工作过程
，从前期访问业主实地考察分析，到后期设计并解释如何解决现存问题、满足业主需求，推荐所有设计师一看 。

“设计是用来解决问题” 的 ，这是学习设计师反复会听到的一句话 ，但相当一部分同学都会把它当成正确的废话
。

因为在目前接触的工作环境里，设计的目标看起来和解决问题 “毫无关系”，只是老板 、产品经理给出需求 ，然后你跟着做
，接着再按他们的意见修改，你认为好的设计没被采纳，意见也不听等……

由此可以引申出一系列对环境的吐槽 ，总结自己是如何沦落成美工的
，根本没有分析的余地。这是种巨大的误区，任何项目的设计都包含可以分析的对象和要素，问题在于设计师有没有定位这些问题而已 。

先从一个理想的项目流程说起，首先老板/产品要做需求的制定
，提供项目说明和原型，然后设计师要在这个阶段分析业务 、用户、体验 、竞品、交互 、视觉的内容，然后再展开设计完成后续的交付
。

在这个流程中 ，分析阶段第一步是先理解业务，也就是需求这么制定的原因，需要解决哪些业务问题 ，带来的收益是什么 。比如做个审批流程，流程交互和状态很繁琐，设计师不能只看操作的流程不顾现实业务流程的逻辑。

比如审批的领导很多 ，每级都要过审，打回的话重新开始流程的规章是啥样的，决定了最终产品应该制定的功能和交互。不管拿到什么需求，分析背后的业务逻辑都是必不可少的，也是 B 端设计一定可以展开分析的部分。

因为 B 端项目不存在没有目的的需求 ，任何规划和构思都是围绕在特定的问题中展开的 。可能很多设计师会说实际情况并不是如此
，工作中碰到的需求要多离谱有多离谱 ，都是老板/客户/产品拍脑袋想的，没有任何道理。

如果是针对一些小细节，比如按钮位置 、表格列数之类的
，确实可以只由个人偏好决定。但只要维度变大，面对整个产品流程 、模块、项目的需求时 ，这种情况就会越来越少。

作为设计师，业务分析中 ，并不只是纠结别人和我们的想法不一致或你不认可，而是搞懂制定需求的人所理解的业务和解决方式 。即使没有已经开始运转、成型的业务，决策者也会有他们自己建立的思路和理解，只是很多时候提供需求时并不会和设计师解释。这需要设计师主动去问，搞这些决策的理由
，这个过程同样也是分析的过程 。

在最恶劣的环境下 ，需求方会拒绝和设计师解释需求 ，可能因为逻辑复杂懒的解释，或者前期工作过程中的矛盾积累（设计师一直唱反调，解释成本过高） 。这种情况分析需求会变得困难，但不是背后的业务因素就不存在，要靠设计师发挥主观能动性去和相关人员沟通。

有一定经验的设计师，但凡有了项目的目标和对业务的理解，再结合产品需求、项目场景 ，就必然能思考后续设计工作中的目标是什么 ，会遇到的阻力有哪些。

工作目标即设计要实现的内容，有抽象的也有具体的。抽象就是解决某些问题 ，比如满足某业务的需求
、更符合主流的设计、提高用户体验的交互等等 。而具体的部分，就是要交付的工作内容
，具体哪些页面、图标 、标注、切图等 。

工作目标是无论如何都会有的 ，而项目后续要面对的问题 、阻力自然接踵而至，只要有一定工作经验的设计师都能分析出来 ，很多设计师其实已经分析到了但不自知而已。比如他们会到社交渠道吐槽 ：

1. 需求给的不够清楚，产品没时间写 PRD 和整理字段
2. 项目给的时间太少了，但是要设计的页面太多
3. 项目前任用的规范一塌糊涂新项目根本不知道咋下手
4. 客户喜欢的设计风格很奇葩 ，完全不想配合
5. 开发说了要直接用开源框架不会按我的设计稿还原
6. 流程太复杂 ，感觉用户根本就用不懂

这些不就是问题？不就是阻力 
？设计的过程，必然会有各种各样的难题 ，而设计师的任务之一，就是想办法解决设计上的难题，而不是指望别人什么都准备好了给你 。

基于对问题的理解
，才会有后面的解决方案，比如没有完整的需求 ，你可以自己快速输出原型评审建立需求  ，设计师时间少，那快有快的做法，前面规范混乱 ，你怎么根据项目流制定新的规范标准等等……

在多数 B 端项目中  ，项目背景、相关业务 、产品需求三个要素就前期分析的核心内容，已经足够支撑设计师展开具体的设计，并对成果做出充分的关联和解释了 。而理想项目流程中会提到的用户 、体验、竞品分析等，在 B 端项目中从来都不是必需的。只有在上面三个要素分析中得出相关的结论需要用到它们
，才会开展 。

比如很常见的项目是靠客户领导拍板决定的，或者就少数人使用的工具 ，用户的研究可能只涉及一些简单的沟通，不需要开启完整的体验设计流程
。而如果没有找到能访问的竞品，并不会有什么影响 。解决自己项目产品、业务的问题和竞品有什么关系 ？只有在项目目标是直接要和竞品展开竞争，且竞品是用得到的前提下 ，才有竞品分析的意义
。

以上都是前期分析的部分 ，只要完成分析并获得结论，那么到了实施阶段，交互 、规范 、布局 、样式的制定 ，就应该都有清晰的逻辑和思路了 。这和设计师本身的基础能力有关，只要熟练掌握相关技能，那么完成设计的过程肯定会去遵循某个逻辑脉络，而不是做到哪算哪。

比如全局框架制定中，怎么兼顾不同功能页面、操作的需求。设计风格定义中，以品牌的角度切入还是行业的特征 。界面布局时怎么做更符合业务场景，组件前后排序的依据是什么等等。

在我们过去的改版案例中，对有给过对应的分析过程
，这些就是实际项目执行过程中会考虑的东西：

实施阶段可以分析的内容是最多最杂的，很多初级设计师在这个阶段完全没有思路，唯一的原因就是基础能力不足
，在应付视觉部分的工作就已经耗尽全部精力疲于奔命，那当然不会产生多余的想法 。

比如从项目刚开始 ，设计师对自己应该怎么把界面有效做出来都没信心
，后面的一些页面类型应该怎么做也完全没有概念
，那么就绝对不会浪费时间去思考设计以外的问题，哪有闲工夫关注背后的产品逻辑和项目流程。

所以项目分析 ，是在设计师能做好设计的核心工作基础之上 ，对设计内容意义的探索 。一个人只有在吃饱饭的时候会去探索生命的意义……

最后总结一遍，项目的分析，包含的内容有前期计划和实施两个部分 。

计划阶段的分析重点是认识项目的背景 ，看懂产品的需求 ，调查分析需求背后关联的业务
。然后总结设计的目标
、任务 ，以及完成工作会遇到的阻力。思考的结论决定了进一步要完成哪些工作 ，是否有必要做用户调研、体验分析、竞品分析 。

实施阶段的分析，则是完成交互 、规范、布局、界面的思考过程，你在设计的过程中根据前面的结论怎么推导的
 ，还是单纯自己对体验、权重、美感的理解而做的决策 ，都是分析。区别只是是否合理 ，能不能够说服别人。

以上囊括了一个 B 端项目会促发的常见的分析对象，除此之外还有很多可以分析的内容 ，可以理解成只要你工作涉及的每一个环节、事件 ，都有分析的空间  ，因为实践是靠思考去引导的，而不是随机发挥。

二、项目分析的输出方式

用意大利设计师马西莫·维涅利的话说 ：

“设计是对问题的有组织的解决方案……”

如果理解了项目的设计分析是什么，就会发现可以分析的东西实在太多了。对于项目的输出来说 ，最大的问题反而不是没有分析能写 ，而是全部写进去根本写不完。

所以项目包装之所以叫包装，不是纯粹做虚假的美化，而是要有目的性得控制对一个项目的展示内容 。虽然你的设计可能非常专业，但如果你把所有细节都展示出来，那么这么琐碎臃肿的包装是不会让观看者满意的。

项目包装除了展示基本的界面视觉外 ，还有展示 —— 界面设计的过程和相关思路，是一个需要花时间去建立的解决问题的过程演示，且包含清晰的逻辑和前后顺序 。

所以创建项目包装前，要先把整个包装的展示大纲建立起来，这个大纲可以用下面这样的顺序
：

1. 项目介绍
2. 业务说明
3. 设计目标/问题
4. 用户/体验分析
5. 竞品分析
6. 风格分析
7. 界面解释

首先介绍项目是什么，然后解释你对项目涉及业务的理解 ，设计的目标/问题的认识
，如果涉及用户、体验、竞品的分析过程就做进去 ，没有就不放 。接着展示根据前面分析的成果
，解释设计风格是怎么来的 ，以及具体做完的每个页面布局、组件
、细节有哪些特殊的考虑。

除了先定大纲外，也可以先用文字写一篇完整的介绍，解释设计经过哪些思考过程产出出来的 ，然后再去拆分它们的模块形成大纲
。

再强调一次，大纲的目标是为了帮助我们筛选合理的分析内容和顺序 ，要建立包装的前后关联，而不是前后两个部分是完全脱节的，前面说前面的 ，后面说后面的
。或者导致分析部分内容多出了一大堆没有用的废话，比如网上很多项目包装案例 “好为人师” 的解释专业名词 、概念。

当然  ，上方只是最通用 、简单的框架，不同项目完全可以产生不同的分析大纲 ，比如有的项目是业务驱动的，有的项目是政策驱动的 ，有的是竞争驱动的，那前面计划部分的关注重点肯定就不一样
，这就导致需要展示的内容和顺序注定是有差异的。

在包含多个项目的作品集中 ，每个项目根据各自的特点建立的大纲
，必然是不同的，这样的作品集看起来是合理的，而不是套用相同的模板复制出来的 “预制菜”。

还有一点，分析的大纲只是对分析内容脉络的整理，并不是整个作品集只包含这些内容。因为一个完整的项目输出分析只是一部分 ，还有实施的成果展示。在一些模块之间插入、拓展只展示成果的部分是合理的。

比如风格分析上 ，不管是对行业 、用户、VI 还是情绪板的分析 ，都可以拓展出不同的设计成果 ，比如规范中的字体 、色彩定义 ，制作的不同设计样例 ，或整理的组件
 、图标元素等 。

穿插不同的成果展示，只要不太过度 ，就可以丰富和完善整个项目的包装内容 。这才是项目包装的真实过程，而不是为了做长强行凑内容和字数，写一堆没有人看自己都嫌弃的分析内容出来。

在整理的过程中，如果出现逻辑不自洽的地方，可以修改分析的内容，也可以适当优化设计内容，让设计更好地结合思路做展示 。这都是项目包装中不可或缺的一部分 
，只有最终逻辑自洽 ，内容合理，才能表现出作为设计师的专业性，而不是原项目很多解释不清、模糊的地方全都无脑堆砌进去 。

基于这种思路完成的包装 ，设计必然会对它的认识更深入 、全面，连带的收益是 ，在面试中面试官让你自己介绍一下这个项目 ，或者问你项目的设计思路 ，你绝对不会回答不上来只会当场阿巴阿巴……

想要更好得掌握这种建立项目分析框架的能力 
，可以多花时间去看大厂写的项目复盘和总结，整理这些内容的大纲，并分析他们的合理性 ，你就再也不会对项目分析和包装感到陌生和害怕。

结尾

项目的分析是设计师综合能力、专业性的反映，这部分的能力属于有就有，没有就没有
。作品集会诚实反映这一点，想要获得长期的竞争力，就要系统提升专业技能素养
，而不是就依赖作品集包装的模板、指导。

作者：超人的电话亭