UIUX设计作品集，该怎么写既优雅又有效？
抱怨不会写作品集分析的情况有不少，基本每周都有人反馈，已经成为设计行业世纪难题了。
所以今天针对这个问题，来解释下新手或者初级UI设计师，作品集的前半部分析内容，具体应该怎么写才好。
写作品的分析，首先要知道为什么需要分析，不是因为 “大家都写所以我也要写” ，要从根本上理解，才能做出让人信服的内容，而不是变成毫无营养深度的 “小学生作文” 展示。
之所以 UI 行业非常注重分析内容，核心的原因就是——UI 设计太简单了。
不仅做界面门槛低，界面的美观度在今天对项目的正面影响也越来越小，尤其是在以“又不是不能用”为指导思想的B端领域。所以企业为支付UI设计师高昂的人工成本时，自然需要设计师产出的界面不仅是为了好看，而是要解决项目中存在的实际问题，带来更大的收益。
而解决问题这句话，从刚开始学设计就开始听，听到入行，对于大多数新手来说和 “正确的废话” 没有区别。所以我们必须要发现问题在哪里，什么是解决问题。
我们陆续做的一些改版案例其实就是在做解决问题的演示，比如前几天改的腾讯云的产品导航，就是解决原有信息设计不合理导致的检索、操作效率低下的交互和体验问题：
点击阅读：这次终于要对忍了很久的腾讯云下手了
还有很多其它的实际案例，感兴趣的就要在超人的电话亭公众号里往前翻了。
要注意的是，用设计解决问题，最重要的就是先学会发现问题，而这恰恰是多数设计师最欠缺的思考能力。比如之前我们做过的一个评论里备受争议的改动，优化表格页的筛选框。我把顶部都罗列出来的选项都收纳进了下拉菜单里，需要通过二次操作才能选择这些选项。
点击阅读：多年的B端交互设计经验分享，4个原则帮你提升使用感
光看设计稿的情况下，改后有提升筛选效率嘛？当然没有，筛选的操作明显变麻烦了，本来很简单的操作步骤还变长了。那为什么需要那么改？因为业务方，或者说用户明确的吐槽了进入这个页面首要目的是看下方的表格，筛选操作八百年用一回，而原设计在正常显示中占据了大半屏，完全不符合使用需要。
所以摆在面前的解决方式就很清晰了，必须要减少筛选区域的高度，即使牺牲它的交互性也没关系，因为它没有“那么重要”。
再比如之前改过的淘宝商家端千牛的商品表单页面，原有类目属性的表单排列形式，即缺少排序逻辑，又很难辨识和交互，也和前端的三列式展示样式不一致。
所以解决的方式就是把标题和输入框拆分，让标题独立成一行且左对齐更好被浏览和读取，同时改成3列和前端的展示效果对齐，保证编辑人对展示出去的结果又预期。
还有一个AI绘图工具StableDiffusion的标签栏改版，原有标签栏展示词汇完全是堆砌型的，要靠手动自己去换行，并且语法中一些特殊的应用没有像常规代码编辑器一样高亮，导致标签数量较多的情况下即难调节又难阅读。
点击阅读：AI工具Stable Diffuion体验改版优化
所以在改动中为它增加了自定义分类，通过换行即可增加新分类。同时为语法中不同关键的用词进行高亮，提高阅读性和可维护性。
所有改版案例都是围绕在发现问题的基础上进行的，通过发现问题，思考解决方案，再在实施的过程中 “顺便” 优化视觉，最后给出解决的成果。
类似上面这些案例，总结起来，就是项目中设计可以解决的最基础的问题类型。比如：视觉样式、交互方法、使用体验、信息展示等等。这些问题不需要经过太复杂的分析，就可以通过个人的专业能力和经验进行主观分析得出，并给出让人信服的理由和结果。
但这些问题放在整个项目的框架里，层级并不高，自然分量也不够。所以我们向上探索，再上一层的问题可以总结成业务需求、用户特征、技术限制。
业务的需求就是产品面关联业务所产生的需求，比如一个多人编辑的员工绩效考核页面，或者一个包含了非常多字段和状态变更的卡片，设计它之前优先关注的应该是业务的逻辑和流程，这是需要花时间做总结和分析的。
而之所以这一级中没有写产品需求的原因，就是因为B端所有产品需求理应从业务需求中转化而来，分析产品需求的本质也是理解业务需求。
点击阅读：奇怪的绩效考核表单页面优化实例
点击阅读：简单的列表卡片优化分享
用户特征，就是对产品用户进行的相关调查和研究。和C端不同的是，B端用户的研究更多不是集中在体验上的（除了SaaS类），而是使用效率上的。因为体验不太好，对于内部项目而言根本不是什么问题，但是因为产品的设计不符合用户的认知和行为模式，导致效率低下和出错，就是很严重的问题（降低利润）。
所以对于企业想看的用户特征，是集中在解决产品和用户 “兼容性” 上的，而不是围绕用户生辰八字和家长里短的专研……
所以用户调研，必然都是和产品相关联的调查研究，比如指定产品相关命题的访谈、问卷，或者可用性相关的测试和研究。有效的调研结果，必然可以对产品的设计产生指导作用和正面影响。
最后一条技术限制，就是设计如何基于开发的效率和限制上提出有效的方案。B端项目中，开发权重必然是远远高于设计的，这是成本和产出决定的，所以设计在这一环要提供价值，就必须是设计方案基于技术做“妥协”，而不是以强推设计追求为荣（除非能证明推进后的商业效益）。
比如，使用第三方技术框架下怎么制定出一套即符合框架规范又满足项目品牌需要的规范，在有主题切换的问题下如何配合开发制定一套高效专业的 Deisgn Token，或者甲方需要实现的复杂可视化动效如何快速测试方案并让开发落地等等。
上面提到的三个问题，虽然层次上升了，但依旧是项目的局部，还可以再往上追溯，那就是企业战略和竞品认识。
企业战略就是企业对这款产品发展的计划，包含了公司对当前市场的分析，和对市场机遇的理解（虽然不一定是准确的，但公司打算那么做了）。所有业务需求、用户对象、技术要求，都是通过企业的战略引发出来的，就像要做一款面向小微企业使用的 OA 工具，不会蹦出大数据处理的技术要求，或面向大型跨国企业高管的用户群体。
而竞品理论上也是战略确定后才要考虑的因素，之所以放在同一级，是因为国内企业对竞品的重视度远远比你们想象的大，即使在人人都是产品经理等网站中搜索排名第一的关键字都是竞品分析。
原因是国内的B端市场环境竞争非常的激烈，而且很多行业增长不够快，接近零和的状态，导致产品的发展战略受到竞品的大量干扰。很多B端产品的实际战略就是，在同一个赛道中超越竞品。
而竞品分析要找出的问题，就是要找到竞品在设计相关的要素中存在的优势，如何在设计领域中给出追赶或者超越它们的方案。
当然，如果你的产品仅仅是内部产品，那么就没有研究竞品的必要。
总结起来，市场和企业想看到的分析和解决的问题，就包含下面这样的结构：
上面的结构，和用户体验五要素逻辑是一样的，只是我们用作品集分析的思路来做的话，并不适合直接套用五要素的框架，因为五要素被用的太多，而且太啰嗦，会让分析内容看起来非常的刻意和死板。
有了项目问题的来源，下面就要开始具体的进行项目分析内容输出的计划了。
每个项目都应该有一个自己的分析输出流程，并一定是完全遵照实际项目流程里的所有分析内容。因为分析要输出，就需要包含 “逻辑”，也就是前面写的东西，得和后面的内容关联上。而很多作品集的分析内容之所以是堆砌，就是因为它光在前面分析挖坑，但是后面不填，那写得再多也只是凑字数。
而结构内的内容也不是让你全盘照搬都写出来的，而是要学会如何根据具体项目筛选出必要的内容，再结合到你的项目包装中去。
这就需要再每次项目输出前先写个具体的大纲，然后再开始做后续的设计，比如：
项目和战略目标介绍
问题发现 - 同行业内竞争对手，以及竞品的设计相关优势点A、B、C，后面要总结
问题发现 - 业务需求包含的主要设计目标，模块A、B包含非常复杂的逻辑和流程，需要展示出来
问题发现 - 用户对老版本产品的可用性分析，使用用户体验地图和访谈，总结出模块 A和B的问题
方案展示 - 构建项目框架，展示产品地图，优化项目结构来解决业务和体验中发现的一部分问题
方案展示 - 交互流程搭建，展示原型和流程，构思模块 A、B的交互解决思路
方案展示 - 视觉风格展示，根据企业战略和品牌发展，以及一部分对用户的认识，搭建对应的情绪版和设计规范
页面展示 - 模块1，解决部分视觉、交互的xx问题
页面展示 - 模块2，解决交互，信息展示上的xx问题
页面展示 - 模块3，解决交互，体验上的xx问题
……
不同项目搭建的大纲必然是有很大差异的，有的项目有竞品，有的完全没有竞品。有的项目是迭代有老项目对比，有的项目是全新的项目，由客户指派。
但是不管项目怎么变，大纲的目的都在于有针对性的去思考项目可以挖掘的问题，并像写小说一样的在前期内容中埋坑在后面填坑。
这也是一个很好的检验，如果你完全分析不出任何问题，要不然就是你自己的基础知识水平是不足的，没办法支撑你用比较专业的方式来解决问题，只是跟着模糊的感觉做设计或是“模仿”。或者你对项目的业务不够熟悉，根本不清楚业务会有哪些体验、交互、设计上的痛点存在。
其中，业务一定存在需要被解决的问题。因为任何业务都仅仅只是一种抽象的概念，它要转化成可视且可以交互的界面实体，就必然有合适的标准。比如一个政府部门使用的严肃系统和一个面向互联网团队的泛文档工具在设计中就存在截然不同的要求。
而缺失基础知识和业务理解这两部分能力，就必然导致整个项目的包装是空洞的，一看就知道设计师相关分析能力的不足（不会有别的解释）。
遵循这个结构带来的另一个帮助，就是确定分析内容的边界，可能你的项目实在没有什么值得描述的问题，或者你能想到的问题点也就这些了，那么其它你给不出解决方案的问题就全都 “不是问题”，没有去写入的必要。也不要为了凑字数去强行加入一些别的作品集里写的东西，比如整了个埋点统计、数据分析、双钻模型、SWOT 分析等等，然后再在里面科普这些专业知识点是什么，为什么重要……
还有一个你们很难发现的细节，就是为了做项目的包装，不是项目做什么样你最后贴啥图，而是在规划了输出大纲和解决哪些问题以后，是可以根据这些目标去修改原图以满足解决方案需要的。也就是项目设计根据包装的需要做改动和筛选，逆向补全，这才是最有效的项目包装思路。
最后总结一遍，输出作品集的分析内容，就是实现找出问题并解决的闭环。从对项目的不同层次分析，提炼出项目的问题，然后再以这些问题作为起点，制定项目包装的大纲，并在大纲中添加能给出的解决方案，再对难以满足解决方案需要的设计稿进行逆向调整。
可以看我们两个分析更完整的案例作为参考：
B端交互框架改版 - 我用即时设计改了即时设计页面
超肝交互改版 | 飞书多维表格交互改版全流程分享
结尾
关于分析的介绍写起来比较挣扎..... 因为涉及的情况和场景太多，很难用一个标准的答案或者给你们一个通用的结构。分析的专业性是靠日常积累出来的知识和经验组成的，绝对不是套路化写作或者 GPT 可以给你生成出来的。
这篇内容的作用就是为了让你们知道分析的价值是如何体现的，以及专业的项目包装是怎么组织内容的，如果无法实现相关的要求，那就宁愿删减也好过画蛇添足，把精力更多花在作品界面本身的质量完善上，以免作品集最后的效果一无是处，自己都不忍直视。
后面我会进一步提供作品集分析的具体案例，想要成为案例的同学可以在微信上给我们发布自己的作品集。想要快速积累这些必要知识的话，建议参加我们下期的B端设计全能班。
课程介绍：今年最后一期｜B端产品设计课开启招生
我们下篇分享再贱~
