所以，究竟要怎么做UX作品集

原文地址
阅读时间：2020.9.26

说在前面

想象一下这样的场景。

周一早上，你发现日历几乎已经排满了会议，只有下午1个小时来做设计，还要赶晚上的设计汇报。这时突然收到招聘团队安排的5个作品集的点评任务，而且明天就是 Deadline 🤯 于是你决定6点吃晚饭时花个10分钟搞定… 但却发现每个作品集的“设计过程”都详细得像是硕士论文——密密麻麻的文字，各种翻转的手机模型，各式各样的设计方法论作为大标题横亘在中央，直接甩上一个旅程图，两个角色模型，三个流程图，四张视觉稿…

“好咯不要再闹了，请问这是什么”，饭都吃完了，你还是没看懂第一个作品集的第一个项目在讲什么。

Say no more, 这个人就是我，也是我第一次收到点评作品集任务的场景。我发现我并不是一个人，其他设计师也是在繁忙的工作中挤出一点时间，来浏览并点评好几个作品集。

当时我点评作品集的数量不多，脑里没有系统的评判作品集”好or坏”的标准。直到今年，我看的作品集足够多，脑里逐渐拼凑出典型作品集的“范式”，以及典型的“错误”。

“是时候了”

我决定根据自己看过的30+个作品集，加上其他设计师的反馈，尝试从作品集点评人 (UX Portfolio Reviewer) 的角度出发，剖析我在评审作品集时的 😥 崩溃瞬间，以及对候选人的期待。

关键词： #ToB业务 #用户体验 #软件设计 #产品设计师 #交互+研究+视觉

01. 十秒决定去留

把作品集开篇当做“电影预告片”：让观众知道认识主人公，并激起购票进场的期待。

清晰地介绍自己

开篇开宗明义介绍：

• 你是谁，如何自我定位？
• 具备什么核心能力？/ 最擅长做什么？
• 现在/过往经历的闪光点？

凝练地描述项目

直接把挑选出来的项目放在首页：

• 一句话描述项目是什么
• 项目的类型：UX/工业/服务/装置/品牌/影片/…？
• 项目的性质是什么：学校/个人/实习/客户项目/…？
• 你的主要角色和责任

方便点评人扫视作品，挑选重点项目进去看，比如，投应届或实习的岗位，我首先会挑UX+实习的项目。

精妙地呈现封面

直接把项目产出最精彩的设计放在封面，我会默认认为封面=项目的产出

• 不要单放一个Logo（曾经看过单一个硕大的谷歌Logo作为封面，以为是实习项目，结果是个人谷歌冲刺练习）
• 不要单放文字
• 不要放过程的草图
• 不要放莫名的插画

→ 案例

[updatinng…]

| dannpetty.com

直接介绍自己的能力，以及服务过的客户；项目都是最终成果图 | | | :—- | —- | | https://purplerockscissors.com

项目名+一句话介绍+成果图+CTA | |

**

02. “文字”也是设计师的作品

UX设计师在实际工作中，不仅产出设计稿，还需要撰写很多“文字”，并和团队对齐和打磨。

作品集的“文字“包括问题声明 (Problem Statement)，项目目标 (Project Goal)，设计目标(Design Goal)，研究洞察(Research Inights)，设计概念(Design Concepts)等等。

但是在看作品集时，我看过很多没有深究原因的、缺乏上下文的、未经斟酌的、只有Bullet没有Point的文字；或者写得过于细节，但不提取中心思想的大段落。

事实上，从打开作品集的那一刻起，我并不会看设计稿，而是寻找这些核心信息。如果这些信息缺漏或隐藏、模棱两可、含糊不清，或者让人摸不着头脑的，我会默默地在心里扣分✍🏻，直到扣到不及格… 就会默默关掉。

所以，请仔细打磨这些文字！

问题声明

• 有没有清晰直接的问题声明
• 有没有偷偷把解决方案塞进问题声明 🙂
• 框定的问题有没有浮于表面，还能有问“why”的余地吗
• 框定的问题会不会过于宏大（比如移民的身份认同）

设计目标

• 有没有清晰直接的项目&设计目标
• 目标是否和框定的问题脱节

研究洞察

• 有没有清晰直接地声明研究的洞察
• 洞察声明是否能推导“我们应该如何做”
• 洞察声明有没有和用户痛点&需求联系在一起
• 有没有能将“用户痛点+需求+设计建议”这个package有逻辑地联系，作为单独的模块，并高亮地呈现

遇到很多情况是研究洞察就是一句单薄的话，甚至是一个宽泛的词… 但我理解的研究洞察是一个揭示因果逻辑的过程，是综合了前面的研究，得出了“设计师的观点”，也即“作为设计师，我认为我们的方向应该是… 因为…”。

设计概念

• 有没有强有力地声明“我们想通过什么方式，来解决什么问题；具体来说有三个方法”
• 如果概念过于复杂，有没有用图像化语言呈现

遇到一些情况是一上来就铺设计稿，从登录页到缺省页事无巨细… 但我没看到这些设计稿表达了你什么设计概念，也即设计师采用了什么方法来解决上面提到的问题。

→ 案例

[updatinng…]

http://simonpan.com/work/uber/ 清晰地阐明设计概念
http://lifeofpai.com/work/box-annotations 超级清晰的项目概括，自己的角色和团队，每个部分都写得非常明确不含糊

03. 讲好一个故事

上一次我由衷感慨“这真是一个好故事”是看美剧“This is us 我们这一天”的第一季第一集，40分钟就好像看了一部电影🍿 超爆好看！我也一直在学习怎么讲好一个故事，链接我之前写过的相关文章，这里给几个小建议。

Mapping ‘Design Thinking’ to ‘Narrative Arc’ ↗ Storytelling ↗ EDT WS Week 4 - 汇报设计故事 ↗

先让人读懂，再吸引人读深

大多公司都会强调“设计不能仅展示设计结果，还要有过程”… 这导致了很多作品集都以Case study的形式呈现，巨长，巨多细节（是我们的锅）。但！至少我，是不会一字一句看完全部的，只会快速跳读。如果我遗漏了原本有的重要信息，只能说抱歉☹️

所以我建议：在一开始就把设计过程中的结论从头到尾讲一遍，之后再写“How I got there”。

开头就把框定的问题，制定的目标写出来，通过什么样的用户研究得到了什么洞察，通过头脑风暴和用户测试，最后得到的设计概念是什么，最终设计方案是什么… ——把这些关键的“故事节点”直接摆出来，让点评人从高维度地理解整个故事的脉络，5-10分钟就可以读完。

对于详细的过程，可以在这个作品下面，甚至链接去博客，详细陈述设计过程。如果点评人对其中一个部分感兴趣，就会往下深挖，比如“这个洞察很有兴趣，背后的研究过程是怎样的？”，“这个设计方案很特别，背后的原因是什么？”等等。

强调“你”的角色和贡献

我留意到点评留言最高频出现的是：“我不知道这位候选人真正擅长什么”/“我不知道哪部分是这位候选人的贡献”。很多人没有强调自己在项目中的角色和贡献，甚至感觉是站在第三方的角度没有感情地复述了一遍设计过程。记住这是“你自己的作品集”，而不是“小组的作品集”。

1. 角色，指的是交互/研究/视觉/项目经理/其他。
2. 贡献，指的是能够被清晰阐明的、具体的产出，“存在在项目团队”≠“有贡献”，“模糊的无法被明确呈现的想法”≠“有贡献”。比如，用户研究是由你主导的吗？设计洞察是由你的主张发展出来的吗？设计概念是由你发展出来的吗？交互流程是由你主要梳理的吗？高保真视觉是由你主导的吗？你具体的产出是什么？

甚至可以把作品集想象成晋升作品集，里面仅仅只呈现自己的产出。如果自己的产出非常接近最终成果，那很好；如果自己仅在前期产出了想法，当然也可以展示，并且展示自己的想法和最终成果的异同，背后的原因是什么。

所以我建议：与其强迫自己为了保证“设计过程的完整性”而加了很多不是自己贡献内容，倒不如把作品集当成“你的故事”，清晰地写明白“我主导了…”/“我主要负责…”/“最后的成果是…”，让点评人知道你的长处。

如果在一个项目中，自己对用研没有啥贡献，那就简单带过，Who cares? 你可能在交互设计上出了很多方案，主导了设计的讨论，这就可以展开谈谈：你如何从队友得到的用研洞察出发，去探索设计方案和做设计决策。

用视觉吸引人

在读懂了你的故事之后，点评人就会快速地往下滑。除了短而清晰的标题，点评人基本会以图作为停留的锚点，比如看到用户研究的现场图，会停下来看看过程；看到旅程图，会上下滑动看看上下文和得出的结论；看到图表，会尝试读懂图表传递的信息……

最重要的，对于最终的设计方案，有没有以故事的方式逐步呈现，有没有放高清大图（看过很多把设计稿放进45°倾斜的电脑/手机模型里，我根本看不清里面的细节）

所以我建议：在每个重要节点，用视觉来吸引点评人停留；最终设计方案要呈现最高清的图片，能点开查看大图那种，甚至有视频串起整个故事。（99%概率我会点开视频）

探索过程&决策时刻

在实际工作中，设计师每时每刻都在做大大小小的决策。比如为什么选这个设计方向，而不是其他？为什么用这个交互范式，而不是其他？甚至… 为什么用这个图标，而不是其他？为什么用这个色号，而不是其他？

所以我建议：高调地呈现 & 清晰地陈述你做了哪些设计探索，收拢成几个方案，每种方案的优缺点是什么；你和谁沟通过程，决定采用什么方案，为什么选择这个方案，有什么妥协？

展现探索过程和决策时刻，都能让点评人理解你的思维和做事方式——这比自己在简历写一句“我是一个善于多角色沟通并推进项目落地”要有力得多。

失败的教训&成功的经验

98%的作品集都是“成功的项目”，Hooray! Happy Ending 🤡 但其实… 我完成一个项目，或者一个迭代, 甚至一个功能，我会反思“啊如果我那样做可能会更好”。事实上，时常复盘，甚至和设计团队&项目团队做复盘，对个人的成长很有帮助。

所以我建议：在项目过后，呈现你对项目流程、团队合作、人际沟通、设计决策等等的思考和新的理解；如果失败了，为什么会这样，你尝试了哪些解决方案？如果再让你做一次这个项目，你会有哪些改变。或者项目成功了，你认为是哪些关键因素推动了这次成功等等。

比起一个“100%理性的设计师”，我更希望看到一个“真实的你”，因为你首先是“人”，其次才是“设计师”。我会关心“你怎么思考这个设计决策，即使这是团队的决定”，“做完项目，你感觉怎么样”，“你认为你哪里做得好，哪里有待改进”等等。

→ 案例

[updatinng…]

https://uxdesign.cc/applying-ux-research-to-a-small-e-commerce-website-a-case-study-89e4b6a1cd2f 开篇快速讲述关键要点，再慢慢展开叙述
http://simonpan.com/work/amazon-prime-music/ 明确自己的角色和责任；用具体的产出呈现自己的贡献
http://simonpan.com/work/uber/

开篇介绍完整的故事，再展开详细过程 | | | https://youtu.be/zZ5B6JfdDVQ

呈现多种方案，并分析利弊 | | | http://lifeofpai.com/work/box-annotations

多方案的探索 | |

参考

• thatbook.com
• http://simonpan.com
• https://www.youtube.com/c/femkesvs
• https://www.casestudy.club/case-studies
• https://www.casestudy.club/journal/ux-designer-portfolio

作品集自查清单

设计概念
- [ ] 有没有强有力地声明“我们想通过什么方式，来解决什么问题；具体来说有三个方法”
- [ ] 如果概念过于复杂，有没有用图像化语言呈现

设计方案
- [ ] 有没有用故事一步一步地呈现，而不是一股脑平铺设计稿
- [ ] 有没有用最高清的大图呈现设计
- [ ] 不要用任何多余的模型
| | 故事 |
- [ ] 有没有首先提供故事的梗概，再展示设计过程
- [ ] 有没有强调自己在项目中的角色和贡献
- [ ] 有没有适当用视觉元素引导注意力
- [ ] 有没有展示探索和决策过程
- [ ] 有没有反思项目失败/成功的经验
|