🔥 Search Hot Tweets

Vercel 的顶级产品设计师分享了他的 AI 时代设计流程： 我总算摸透自己这套全新的设计流程了…… 没错，现在我就是用它随手记下这些想法的。第一步，就是随心口述表达。可以是和同事的讨论，也可以是自言自语，甚至就按着语音输入键，结合手头掌握的所有信息，想到啥说啥，对着要解决的问题天马行空地琢磨。我最常用的语音工具是 —— 有时候我甚至都不说明粘贴这些内容的目的，只一句 “这是文稿，你自己梳理”。如果是和别人的对话，我会把通话文字稿一股脑丢给 Claude，不加整理、不分类别、也不额外补充背景，完完全全把项目相关的所有信息都喂给它。 目前我用录音工具做这件事，但说实话，如果有专门的工具适配这个环节，我还挺想试试的。 另一款工具也挺好用，但对我来说 Notion 用起来更顺手，毕竟团队所有的文档都存在这里。 这一步里，Claude Code 的作用特别关键。我和它反复沟通、补充背景，它会抛出不少有价值的问题。而在描述问题的过程中，我自己对要解决的问题也会理解得更透彻。 我会顺着问题不断深挖，把 AI 当作我的研究助手，同时给它分配子任务：让它去做网页检索、生成 CSV 表格、撰写相关的 Markdown 文件，还会让它从我能访问的其他渠道调取相关文档。 说白了，这一步就是大海捞针，或者说，先找到那些可能藏着 “针” 的 “草堆”。 这曾是我最抵触的一步，如今却发现它至关重要。 我不是指 UI 视觉设计，而是应用架构、交互逻辑、文案细节、页面布局，以及和现有产品的融合适配 —— 这些能让产品用起来得心应手的设计核心，AI 都搞不好。AI 的设计能力其实糟透了。 但我发现，Claude Code 这类工具的 “糟糕设计” 反而有个大好处：它能给我一个绝佳的起点。 我不用再面对空白画布苦思冥想，也不用囿于现有产品里不尽如人意的功能，而是从一个功能可行但设计拉胯、落地粗糙的版本开始。 接下来，精彩的部分就来了。 我拿着这个设计糟糕的产品雏形，用最挑剔的眼光挑刺、吐槽，专挑漏洞猛批。没有什么建设性的建议，只直截了当说 “这也太烂了，把 X、Y、Z 这些问题改了”。 我会揪出所有边界问题、所有极端场景，找出遗漏的页面、缺失的错误状态、不清晰的悬停交互，厘清信息的取舍标准，然后把所有冗余的内容大刀阔斧删减，精简到最核心的状态。 但实则设计一塌糊涂。AI 的设计思路太 “堆砌” 了，会把各种颜色、组件、图标、标题、分类卡片一股脑往页面上塞，活像在页面上乱喷东西。做出来的东西，外行人看着像个成品产品， 放在以前，这样的设计基本就是产品死刑，根本没法挽救 —— 为了修正这些糟糕的设计决策，付出的成本实在太高了。 但现在，修正这些问题的成本几乎为零。我一天之内可以推倒重来十次，把这个糟糕的雏形砍到只剩核心需求，再花几个小时重新搭建。 这个粗制滥造的框架、漏洞百出的雏形，就像新事物诞生前的灰烬，而我的工作，就是从这堆灰烬里找到新生的可能。 这时我会以创意总监的视角，开始标注修改、添加注释，梳理信息的呈现逻辑，也会因此豁然开朗：想明白如果设计得当，这个产品实际用起来会是什么体验。 在完全不碰传统设计工具的前提下，把产品的应用逻辑、整体架构和 UI 界面打磨到极致。这一阶段我会用到这类工具 —— 直到产品能在合适的时机呈现合适的信息，信息架构初具雏形，使用起来流畅顺手，具备了一款产品该有的所有核心功能。可即便到了这个阶段，产品看起来已经 “落地可行”，甚至有成为好产品的潜力，它的设计依然不够成熟，还有大量优化空间。 毕竟，文字和语音作为设计媒介，实在太笨拙了。没法精准打磨细节、优化体验、设计图标，没法保证组件的统一性，也没法理清所有功能的关联、组件的复用逻辑，以及产品在整体生态中的适配性。 到了这个阶段，AI 的问题会层出不穷：新增一个功能，它会随手加新组件、创全新的按钮样式，记不住已经做好的元素，最后让原型变得臃肿不堪。 我总想在这个阶段继续打磨下去，但心里清楚，这一步的天花板就在这，无休止地耗下去只是徒劳。 但这一步的价值依然很大：能快速获取利益相关方的反馈，了解用户可能的交互方式，让团队成员参与讨论，从团队视角推动产品思路的落地。 一旦团队成员能清晰看到我的设计方向和落地思路，就该彻底抛开这个 “灰烬雏形”，进入下一阶段了。 前五个步骤下来，能得到一个有意思的产品雏形，但里面满是无用代码、模糊的设计决策，以及对产品走向的错误判断。 这一阶段，我会让 Claude 新建一个文件夹，生成一系列 Markdown 文档，记录产品的背景、开发历程和设计约束 —— 这些内容会为后续的产品开发提供重要参考。 说白了，我相当于重新从零开始，但会结合之前的口述稿和现有代码，打造一个更完善的产品版本。同时，我会把能想到的所有产品状态都截图保存：包括各种功能变体、极端场景，以及所有想要进一步精细化设计的细节。 而这一步，正是我三个月前设计流程的起点。现在想来，真的太不可思议了。 我带着这些截图和所有背景资料，绘制用户流程图，然后打开 Figma，开始真正的专业设计：启用自动布局、遵循过往的设计规范，搭配色彩、复用设计系统、规范排版和设计变量…… 这些经典的设计步骤，一个都不能少。 说实话，经过前面一系列高效的打磨，这一步会让人觉得节奏很慢，但它对打造高质感的成品来说，必不可少。 目前这里还有个明显的工具缺口：如果能把产品里所有标准化的元素直接转换成对应的 Figma 页面，效率会高很多。但我暂时还不敢信任这种 “转换工具”，因为进入 Figma 后，我还会有大量的设计探索，这是工具无法替代的。 在 Figma 里，我可以放开手脚探索：尝试不同的交互逻辑、文案状态、页面布局，把之前在 AI 阶段难以实现的细节都落地。AI 阶段的高难度操作，在 Figma 里会变得轻松，反之亦然。 我发现，在这个阶段，我最容易进入心流状态，能探索最多的设计可能性，也总能想出之前从未考虑过的创新解法 —— 因为此刻我的设计媒介是视觉设计，而不再是单纯的语言表达或功能梳理。 设计的同时，我会随时分享截图、制作 Figma 原型，和团队同步进度，确认设计方向是否正确。 “别关注 UI 视觉，重点看功能逻辑。”必须说一句：在进入 Figma 之前，所有的 UI 设计都很粗糙，我和团队分享时也会反复强调这一点： 也正是在这个阶段，我能以更自由的方式验证之前未探索的想法，最终产出的设计成果，在 Figma 里的呈现形式不再像过去那样繁琐 —— 我发现自己不再需要设计那么多页面了，因为大部分创意构思，在前面的阶段已经完成。 而最终从 Figma 里出来的设计成果，质感远非 AI 能企及。 接着，我会带着所有的设计文件和背景文档，在这款工具里开启新的对话 —— 这依然属于规划阶段。 这一步，我会精准梳理项目范围，结合新的设计原型，理清所有待解问题，也会核对设计原型是否和之前梳理的背景信息有冲突。这种冲突大概率会出现，但必须梳理清楚，才能推进后续工作。 说真的，这是整个流程里我最不喜欢的一步。 Figma 的 AI 功能目前还太弱，单靠截图根本不够用，但眼下我也没有更好的办法。 更希望能把原型的 JSON 格式文件交给它，让它能识别原型里的所有状态。理想的状态是：我能把产品截图、所有组件名称及截图、完整的组件结构、所有文案、色彩变量，以及包括截图在内的所有相关信息，都传递给 AI； Figma 做用户流程原型很方便，但面对复杂的用户交互、列表类元素，或是任何数据驱动的动态内容，就显得力不从心了。我依然想继续用 Figma，但迫切需要一种高效的方式，把里面的设计数据传递给 AI，让它辅助后续的开发落地。 我觉得，Figma 现有的开发者交付功能其实大有潜力可挖。我想和 AI 针对功能的落地方案展开沟通、标注细节，甚至希望它能主动针对我的设计文件提问，把设计和它已有的项目背景结合起来，还能指出设计中可能存在的漏洞和不可行的地方。 就像我平时和资深开发沟通的样子。 等所有设计方案敲定，做出一个功能完善、体验流畅、落地性强的原型后，就进入第九步。 我始终认为，优秀的资深开发者是无可替代的，目前 AI 还做不到这一点，这一步的重要性依然毋庸置疑。 性能优化、技术落地、接口对接、代码架构梳理、同步其他开发进度、融合其他在研功能、选择最优组件…… 这些工作都需要开发者的专业积淀和项目全局视野，AI 根本无法企及。 我自己没法把代码推到生产环境，其实除了一些小的调整和 UI 修改，我也不该碰生产环境的代码。这一步的工作流程，和过去其实很相似：我把设计成果交给开发者，由他们在生产系统中落地开发。 这部分和传统的设计流程几乎没差别，我把设计交付给开发，他们在正式的产品环境中实现。 当然，如果是做个人网站或自用的小项目，这一步可以省略。如果只是营销类网站，不涉及百万级用户和高额商业风险，设计师完全可以自己编写前端代码落地。或许未来行业会变，但我还是更愿意把工作交给专业的开发者 —— 他们有扎实的技术背景，能预判风险，也知道出了问题该如何解决，交给他们更让人放心。 唯一的不同，在于前期规划和交付给开发者的内容。不再是单一的静态流程和设计稿，开发者拿到的，除了静态设计稿，还有一个可交互、一体化、体验流畅、高度贴近实际产品的原型。这个原型能在任何电脑上运行，能在各类设备上测试，我们还能回头借助打造原型的 AI 继续优化设计，而不用牵扯到复杂的生产代码。 依然是一个大胆构想、寻找创作心流的过程。我不确定这套流程能沿用多久，工具会更新、流程会调整、产品的复杂度也会变化。但把这些步骤拆解开来细看会发现，这本质上依然是设计——依然是一个探索不同解决方案的过程， 唯一的变化，只是使用的工具不同，以及工具的使用顺序不同而已。