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

在今天的作品集输出、外包项目汇报上,只展示界面、图例的做法是行不通的,还要加入文字说明,来表达你的设计思路(Design Thinking),俗称项目分析

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

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

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

相关阅读推荐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、项目分析的输出方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

结尾

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

别忘记,想要 B 端设计能力大幅变强,就来参与付费大课了  👉 https://pro.uisdc.com

欢迎关注作者的微信公众号:「超人的电话亭」

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

收藏 55
点赞 47

复制本文链接 文章为作者独立观点不代表优设网立场,未经允许不得转载。