体验设计 on Hi, I'm 5key

设计师的 2024：边界在消失，2025 该怎么走？

Sun, 22 Dec 2024 00:00:00 +0000

TL;DR

2024 年设计行业经历了两个本质变化：体验设计师向产品设计师演化、AI 在敲打设计的边界。

本文是我对 2024 的复盘和对 2025 的判断，也宣布了我从「OFF UX」专栏到「OFF DESIGN」专栏的品牌升级：从聊体验设计走向跳出设计本身、从产品视角看设计。

2024 年设计行业的本质变化

每到年末，我都会写点东西，总结这一年的起伏。总结，不只是为了回顾，而是为了看清下一步的方向。今年也不例外。

但是，今年的总结似乎又有些不同。2024年的设计行业，已经不再是过去那种按部就班的延续，而是在经历一次显而易见的本质变化。

过去，我们总以为设计行业会一年一年地稳步发展：工具更高效了，流程更完善了，用户需求更复杂了…

然而，事实是，变革早已悄然发生。边界正在被打破，规则正在被改写，连角色的护城河也开始崩塌。

今年，这些变化变得尤为明显，甚至显得近在咫尺。设计行业的边界正在模糊，角色的护城河正在被削弱，连游戏规则本身也在被重新书写。

这种变化不像以往那样渐进，而更像是一次推倒重来的重建。那些曾经熟悉的技能优势、行业规范和职业分工，如今似乎都站在了不确定的边缘。对于设计师来说，这不仅仅是工具的升级，而是一次重新思考自身角色与价值的挑战。

最近，我特别想和大家分享两件事情。它们看起来没有太大关联性，但仔细想想，变化其实早就在我们身边发生了。

01. 体验设计师 → 产品设计师

LinkedIn 上，一位朋友的岗位从「体验设计师」改成了「产品设计师」。他发了一条动态，说这并不是他的个人行为，而是公司的一次整体的调整。

原因很简单，公司希望大家别再沉迷于自己的一亩三分田了，别再只盯着设计细节、搞专业，而是把目光更多地放在业务价值思考上。换句话说，设计师要从「体验设计」转向「业务设计」。

Title 的变化只是表象，背后是公司对设计师期望的彻底重塑。 过去，体验设计师讲究的是“以用户为中心”，可企业的视角可不一样，它更在意的是设计为企业带来的增长和利润。

企业需要的是一个「利润中心」，而不是一个只烧钱、不赚钱的「成本中心」。

设计师的角色也随之发生了根本性的转变。从「体验设计师」到「产品设计师」，意味着设计师不仅要画界面、做优化，还得能想清楚：这个设计能不能提高转化率？能不能直接带来收入？

这背后是企业策略的转变，用更直接的话说，设计师不仅要设计“看得见的好”，还得为“看不见的利润”负责。这不仅仅是一个岗位名称的变化，而是设计行业的一场结构性调整。

02. AI 在敲门，边界在消失

上个月，我开始用 Cursor 和 Windsurf 做一些小工具。刚开始是写写脚本练练手，后来干脆用它们解决工作中的一些琐碎问题。就这样，一不留神，做出了 20 多个工具，这效果实在有点不像话了。更别说更为强大的 Devin，对于设计师来说，我们好像真的不需要工程师了。

过去，设计师不懂代码，这是个绕不过去的槛。很多时候冒出一些好点子都卡在“实现不了”这一步。

但现在，AI 工具把这道门槛给直接拆了。只要你有想法，它就能帮你把想法变成产品。AI 不只是帮你提升效率，更是在改变你的工作边界：设计师可以写代码，工程师可以设计界面，产品经理甚至能用 AI 生成原型。

更关键的是，这种能力不再只是“少数高手的特权”。AI 工具的门槛越来越低，工种之间的界限也越来越模糊。 设计师、工程师、产品经理原本泾渭分明的角色，现在正在被重新定义。

这才是最让人不安的地方。当角色之间的护城河被填平，接下来会发生什么？答案可能比我们想象的要快得多。

看似毫不相关的两件事，实际上指向了同一个方向：设计行业的角色边界正在消失。

一方面，设计师的职责边界正在变化。过去，我们只需要关注用户体验和设计本身，但现在，企业希望我们把目光放得更远一些，思考设计对业务的直接价值。设计师不只是画图的，更是业务的推动者。

另一方面，AI 让我们的能力边界得到了无限扩展。不懂技术？没关系，AI 补上这块短板。曾经因为技术限制而束手束脚的事情，现在只需要一点想法，再交给工具去实现就行了。我们不再只是设计师，我们可以做更多。

不过，别高兴得太早，这件事对所有人都是公平的。设计可以跨界到研发，研发也可以跨界到设计，而产品经理甚至可以抛弃所有人，把问题直接转化为需求，再利用 AI 生成完整的解决方案。

从 PRD 到设计稿，如何避免设计遗漏带来的坑？

Sun, 08 Sep 2024 00:00:00 +0000

TL;DR

“丢三落四"几乎是设计师绩效中最常被吐槽的问题，但很多时候不是设计师不细心，而是缺少把 PRD 系统转化为设计的工作方法。

引入 DRD（设计需求文档）这一中间层，把 PRD 中的业务需求拆解为完整的设计任务清单（含状态、流程、异常分支），可以系统性减少设计遗漏。

篇首语

本期文章的这个话题源于与一位设计师的咨询。前段时间她刚刚经历了一次与主管的阶段性绩效 review，结果却让她有些失落。

她的主管给了她一个不太理想的评价，这其中有一点是日常做设计的过程中，总是会出现一些丢三落四的问题。要么是界面流程有遗漏，要么就是某些特殊状态没考虑清楚。无论是对接的业务方还是直接主管，都提到了这个问题，认为这个问题对项目的整体质量和速度都带来了一些影响。

对于这个问题，这位设计师她自己其实也有意识到，但还是会觉得有些委屈。在日常工作中，新需求一个接一个，很多时候产品需求文档也都还只是个初稿就提给设计了。加上项目的时间都十分的紧张，的确会出现一些考虑不全面的问题。

设计的前期其实都还好，但一旦进入到设计评审环节，研发团队加入进来后很多问题就都暴露出来了。而作为设计师提案者，自然也受到了大家的很多质疑。这些问题更多是由于PRD的不完善引起的，但最后却落在了设计身上，似乎一切问题都成了设计的责任。

这种情况我相信应该很多设计师都曾遇到过。当我们从 PD 手上接过产品需求文档开始进入设计时，方案的合理性和逻辑问题就不可避免的转移到了设计师身上。如果我们在设计的过程中没能发现问题，那么一旦设计稿输出了，无论是产品的功能还是使用的体验，作为设计师我们都会有不可推卸的责任。

如今的产品，复杂度越来越高，特别是哪些涉及到特定的业务逻辑的产品设计，难免会在设计的过程中遇到一些考虑不周或有所遗漏的情况。面对这样的情形，想要完全避免错误的确是件很难的事情。但我们还是可以借助一些流程和方法来尽可能的帮助自己减少这些问题的发生。

在本期的文章中，我想从产品需求文档（PRD）和设计需求文档（DRD）这两份文档出发，来和大家聊一聊在设计过程中的一些思路和方法，帮助我们能够更好地把控设计过程，在设计交付的时候更好地应对来自各方的挑战。

PRD vs DRD

在我们日常的设计工作中，很多设计师会遇到“设计遗漏”的问题，实际上，这种问题与两个非常重要的文档密切相关：PRD（产品需求文档）和 DRD（设计需求文档）。

对于设计师而言，理解这两类文档并做好 PRD 向 DRD 的转化非常重要，它将直接影响到我们的设计能否完整且准确地满足产品需求，避免设计遗漏的发生。

PRD 和 DRD 有什么区别

PRD 是我们在设计工作中最常接触的一类文档，产品经理会从业务和市场的角度描述产品的需求，在PRD 中详细列举产品的目标、功能、用户场景和技术约束。有些产品经理还会附上一些自己线框图，来表达自己对产品设计的一些想法。

在 PRD 文档中，虽然产品经理详细的描述了需求，为设计师的工作提供基础方向，但它始终不是专门面向设计师的交付。大家可以想一想，对比我们在设计交付给研发环节时的设计说明文档，其实 PRD 对设计工作的“友好度”是很差的。

这就意味着，如果我们的整个设计过程是完全依赖 PRD 去完成，这个过程是并不顺畅的，因为它的“格式”与我们的设计工作并不兼容。

为什么会出现这种情况呢？这里有非常核心的一点，PRD 是从产品和市场的视角出发，描述的是业务层面的需求，它所关注的是产品要实现什么功能、满足什么样的用户群体以及如何推动业务目标的达成。

如果设计师完全按照 PRD 所描述的功能需求一步步执行，那么在设计过程中很可能会遗漏掉一些关键的设计细节，或者由于对需求的理解不够深入而产生考虑不周全的问题。这是因为 PRD 仅仅提供了业务层面的框架，忽视了设计中的需求，这就是为什么设计工作中经常会出现设计遗漏的原因之一。

而设计需求则是完全是从另一个视角出发，更多地关注用户体验、交互逻辑、视觉设计等细节问题。可以说，PRD 是宏观的方向，而设计需求则需要更微观和具体的落地。所以，如果我们只是单单对照着 PRD 去进行做设计，就会容易遗漏掉一些关键的设计细节或是思考不全的问题发生。

阅读全文

以上内容节选自OFF DESIGN 专栏 45 期文章「从 PRD 到设计稿，如何避免设计遗漏带来的坑？」。

💡 延伸阅读：

设计的业务价值表达：设计的意义，得用业务语言讲明白

业务思考的起点：业务思考力，设计师跳出执行的起点

欢迎加入我的知识星球，阅读本期文章全文内容以及过往所有文章。

半年过去了，AI 设计的进展如何?

Mon, 04 Sep 2023 16:34:56 +0000

⚠️ 本文已有更新版本

这篇文章发布于 2023 年 9 月，是我对 AI 设计的早期观察。我在 2024 年 6 月写了一篇更深入、更全面的更新版：一年过去了，AI design 的进展如何？，建议优先阅读新版。

篇首语

今年年初 AI 浪潮席卷了整个科技互联网领域，从海外的 UIZard 到国内的即时设计、MasterGo，大家都在不断尝试探索新的模式将 AI 与 UI 界面进行结合。我也一直都在密切关注着它对设计行业所带来的变化，特别是在界面设计领域。

时间一转眼已经到了 9 月，尽管前面提到的这几家公司在文生 UI 领域都投入了大量的资源和精力，也获得了一些初步的成果，但就目前的结果来看AI 在界面设计方面依旧处于一个比较初级的阶段。与此同时大家可能也会发现，这几家公司对这方面的发声也在慢慢变少，整个领域似乎进入了一个相对沉寂的时期，这股热潮似乎在默默的消退。

上周与一位老同事喝咖啡，一起深入探讨了一下当前 AI 设计的能力进展、现实中客户的真实需求以及未来的发展趋势。回来后我又重新整理了一下思路，想在这篇文章中，与大家分享一些我对当前AI 界面设计的思考和想法。

UI 界面设计的复杂性

与创意设计领域中Stable Diffusion、MidJourney 飞速进化相比，AI 在 UI 界面设计上的能力进展显然是缓慢的。

创意设计侧重于高概念的构思发散，而界面设计则是深入到具象的业务实现。这也就意味着从产品逻辑到交互模式，都是需要基于深入的用户洞察和对业务逻辑的细致理解。

这种差异化和复杂性为 AI 在界面设计方面的发展带来了巨大的挑战，迫使我们需要做更多深入的研究和基础建设才有可能获得实质性的进步。这里我们可以展开细说一下：

01. 业务导向的多维度设计

UI 界面不仅仅是产品功能的呈现，它还更需要综合用户需求、数据反馈来进行设计从而向达成业务目标前进。

这也就意味着在设计的过程中我们不仅需要关注产品的界面美观和使用体验，还需要考虑如何结合这些背景信息来进行产品的设计。这就让设计变得不那么“纯粹”，也没有足够明确的规律可遵循，更多的依赖于人的判断。

02. 复杂的设计目的性

相较于创意设计，UI 界面设计的目的性会复杂得多。每一个界面都可能需要满足用户不同场景下的多个诉求。

例如，一个电商平台的商品列表页不仅要向用户直观地展示具有吸引力的商品，还需要向用户提供商品的筛选 & 比价、加购 & 凑单以及平台的功能导航等不同场景下的用户使用路径，而这些功能在不同的状态下可能还会存在不同的逻辑。

这些需求的层层叠加会让产品的界面设计变得异常复杂，这就要求设计师在界面的布局和功能分配上进行精细的权衡，确保用户在不同的场景下都能快速找到自己需要的功能模块并完成后续的操作。

03. 通用与特定的设计标准

就像之前在设计系统的话题中我们一直讨论的，不同的行业和具体的业务中，都会存在其特有的设计需求和习惯。比如金融类产品中需要强调正式感和安全性，而社交娱乐型产品则更关注轻松、互动性的交互氛围。

系统级的设计系统为我们提供了普适性的界面设计原则和交互标准，但它无法为特定的业务提供具象的设计指引，更别说体现产品的品牌特性和“人设”了。这也就要求设计师针对于特定的行业、用户进行深入的研究，定义出符合业务的品牌特性。

04. 持续迭代的设计过程

产品的界面设计并不是一次性任务。它需要随着技术的进步、用户需求的变化以及市场环境的演变，来进行界面设计的不断优化和更新。这不仅仅是为了提供更好的产品使用体验，也是为了适应业务的发展和变化，确保产品始终保持竞争力。

成为架构型设计师

Thu, 14 Jul 2022 16:34:56 +0000

设计师是我的第一份工作。从 2003 年毕业后的第一份工作在一家网络公司，从界面设计到 Flash 动画再到跑客户、贩卖 3721 网络实名，几乎和网络建站相关的工作全都得做，当然，那个时候对设计的要求并没有那么高，我们都被称之为美工。

一晃快 20 年过去了，伴随着中国互联网行业的高速发展越来越多优秀的人才进入到设计领域，设计已经成为一个非常有深度专业工种，设计师也已经成为互联网企业最为重要的专业力量之一。

上一期的文章里，我们在设计系统的话题中聊到通过「规范沉淀」「物料管理」「场景消费」三个方面来优化在产设研（产品、设计、研发）环节的工作模式，也提及了一个新的、也是非常重要的角色 – 架构型设计师。关于这个新的角色，上周分别与两位会员读者在设计团队能力建设的话题中也多次聊到。所以这一期我想正好顺着话题和大家聊聊什么是架构型设计师，以及如何成为架构型设计师。

TL;DR

架构型设计师不直接画界面，而是通过构建设计系统、管理设计资产、推动设计运营，让整个团队的设计产出标准化、规模化。这是设计系统时代设计师最重要的新职业方向。本文系统介绍架构型设计师的职责、素质要求、以及和「产品型设计师」的分工边界。

设计师 Job Title 的变迁

交互设计师 & 视觉设计师 ➔ 体验设计师 & 创意设计师

2008 年加入阿里时，设计团队内将设计师主要分为交互设计师和视觉设计师两类。交互设计师负责与产品一起实现承接商业需求、制作产品原型，再交由视觉设计师进行设计稿的最终输出并交付给开发工程师。

这样的分工一直延续到了 2015 年左右，阿里开始逐步对设计师的 Job Title 进行调整，由原来的交互设计师和视觉设计师调整为了体验设计师和创意设计师，并在 2017 年基本完成了全集团设计团队的调整。

相较于之前交互 & 视觉的定位，体验设计师在原有交互能力基础之上增加了对视觉、商业意识、用研等综合能力的要求，期望能够培养更加一专多能的设计师。这个变化在当年其实让很多设计师感觉到有些“难受”，特别是一些视觉、交互能力均较平的同学来说，对于未来的职业发展方向迎来了第一个较大的困惑和挑战。

不过在我看来这个调整是合理的，也是必然会发生的。互联网在发生着巨大且快速的变化，这也势必导致设计师的工作流程发生变化，以前的工作模式已经已经无法跟上业务的高速发展。到如今时间已经过去了 6、7 年，这种“不适感”在设计行业内已经慢慢消失了，两个新的岗位角色逐步进入正轨，找到了各自的发展方向也延展出了很多新的领域细分能力。

架构型设计师 & 产品型设计师

时间推移到 2018 年，我终于筹建了阿里集团的设计中台团队，为各业务设计团队提供设计过程中的工具及能力服务。在与大家的合作过程中，我发现一些自然而然在发生的变化，业务线的一些设计师已经开始逐步跳出原有岗位的定位，以更加综合、系统化的方式进行思考和工作推进，这个时候已经出现了一些“架构”的雏形了。

在思考并参与了一段时间后我向设计委员会做了一次汇报，尝试提出新增架构型设计师这个新的岗位。可惜的是在当时无论是团队建设还是整体的环境还不够成熟，这个提议并未通过，所以只能暂时的放一放。

不过这倒是不影响我自己继续去尝试，在接下来的日子里我在负责的四个业务中进行了一番调整，为每个业务团队增加了一个架构型设计师的岗位，开始将我之前对设计系统的思考付诸于尝试。虽然这个新增的岗位也是在大家不断的摸索、试错中前行，但新的工作模式为大家打开了新的思路，也带来了非常多正向的结果产生。

什么是架构型设计师

一提到架构这个词，大家很容易就联想到软件开发领域，设计领域也会有吗？过去这个概念可能与设计无关，但现在乃至未来它一定是存在的。当然，我们大家目前在这个领域都还是在边摸索边做，还达不到架构师的程度，所以我会先称它为架构型设计师。

和大家聊起这个话题时，我发现有些设计师会将这个角色理解为专业型的 Leader，精于设计、懂用研、能做好项目管理，也能够在专业角度上带团队。这种从能力项的定义的视角我认为还是在过往的思维模式里，不太准确。

「设计」作为业务生产中的一个技术工种，它在保障专业能力不断精进的同时，还需要确保业务生产的有效性和确定性，从业务视角去看团队的整体作战能力及专业能力的先进性。

基于以上这些背景信息，我会这样定义架构型设计师：

架构型设计师是设计团队专业能力的推动者，基于公司业务发展规划并构建精深的专业能力及高效的协作模式，协助设计团队为业务生产提供高质高效的设计专业能力。

架构型设计师不一定是团队管理者，Ta 会将更多的精力放在专业能力建设而不是人事工作；架构型设计师也不一定是一个人，Ta 可能是一个独立团队或是几位设计师组成的虚拟小组。

架构型设计师的职责

之前的专栏文中中我给大家画了这么一张图。我将它 zoom out 一下放到整个业务的生产流程中，架构型设计师的工作就围绕在这设计的前、中、后环节来开展。

在整个业务生产流程中，架构型设计师的核心工作主要会围绕以下三层来进行：

设计模式库与设计组件库到底有什么区别？

Thu, 14 Jul 2022 16:34:56 +0000

TL;DR

设计组件库（Components）像做菜的单个步骤（切菜、焯水、炒制），是解决单点操作的工具；设计模式库（Patterns）则是把这些步骤组合起来完成"做一道小龙虾"的完整方案。

组件提供基础能力，模式提供业务解法，两者缺一不可。

设计系统（Design System）中有两个重要的概念，设计系统和设计模式。对于这两者之间的区别，很多人都比较困惑。其实用一个例子就能很好的解释，比如大家都喜爱的小龙虾 🦞。

用一个例子来解释

小龙虾好吃，但真做起来并不是所有人都会。不过你可以在各类美食应用上看到它的「制作 SOP」，大致会有以下这些步骤

制作小龙虾 SOP：

去虾线
清洗小龙虾
准备小料
下龙虾过油
加入小龙虾调料翻炒
加入啤酒闷煮
.…

你不一定懂小龙虾的制作方法，但刷个小龙虾一听就能明白，把这些步骤组合在一起，你也能做出一盘色香味俱全的小龙虾了。

设计系统中的 SOP：

在设计系统中，每个组件就像 SOP 中的某个步骤，是解决某一个具体操作的方法，而将这些组件组合起来处理一件事情或任务，就是我们所理解的 Pattern 模式库。

所以，洗小龙虾、过油它们都是“组件”，做小龙虾是“模式”。

如果十三香小龙虾已经成为一个行业标准，大家做得基本完全一个样，那么小龙虾也可以被进一步的收敛，成为你做晚餐的一个标准“组件”了。

当然，如果你家的小龙虾和别人有些差异，比如重甜、重辣、或者说是三分熟（😁），那它的做法就具备较强的特色，成为你的业务级设计模式了。

设计系统延展阅读

💡 延伸阅读：

推行话术：如何向你的主管和团队介绍 Design System 的重要性

深度案例：如何规划 B端设计系统？深度解析 AWS CloudScape

学习路径：设计系统学习指南 - 国内外 Design System 案例解析

决策机制：设计系统中的决策树：让设计决策更简单