打破设计师与程序员之间的鸿沟

迷你设计课

前几天有两篇设计文章，观点都跟“Figma 阻碍了设计师和程序员协作”相关，通俗地举个例子：设计师在 Figma 里实现外观和交互极其精准的组件，然后程序员用代码再重新实现一次外观和交互极其精准的组件，傻吧？

明显浪费时间，两个流程交接还容易出错

---

文章一是“打破 Figma 成瘾”
https://t.co/daXp0Jl76w

作者是独立产品设计师，他的文章源自“Rework 重来”另一位作者 Jason Fried 的抱怨，说他无法理解为什么公司在开始构建任何东西之前，都会在 Figma 中设计数十个像素完美的屏幕…这可能是当今软件开发中最无效、最浪费的做法

作者建议产品团队：

• 及早开发，然后再优化设计
  
• 避免过多预测设计、过多设计不确定的问题
  
• 确保设计师和程序员同步工作
  
• 让程序员不担心完善设计带来重复劳动
  
• 让设计师不担心低质量交付
  
  作者也说明，Figma 擅长处理怎么显示、而不是怎么工作的的问题：
  
  
• 如果想用 Figma 制作高保真原型来打动投资人，做吧！
  
• 在营销页面、创建突破界限的新设计时，Figma 的高保真设计能方便团队快速尝试更多设计方案
  
  ---
  
  文章二是“设计与工程之间的鸿沟”
  https://t.co/LLupecKDhK
  
  作者是设计公司的联合创始人，这篇文章从更为宏观的层面，解释了现在产品设计开发中通行的“瀑布式”模式的缺点和解决方法
  
  因为设计和工程/开发受到各自工具的限制，严格地被分隔为两个阶段（注1），两者交接的设计交付过程，往往是产品团队各种协作问题的根本原因：
  
  
• 设计师构建的复杂原型与程序员构建的复杂系统完全无关，这使工作加倍而开发质量堪忧
  
• 如果设计师不能参与开发，也会在开发中丢失关键设计
  
  作者参照他们和不同团队协作的经验，提出了 5 个建议：
  
  
• 压平瀑布。设计师和程序员更多地共同工作，让设计师参与更多后期开发，让程序员更多参与前期设计（注2）
  
  
• 让代码也成为设计工具。Figma 可以做静态设计；而那些动态的、复杂的组件，就没必要在 Figma 里“假”实现一次、再用代码“真”实现一次
  
  
• 像开源项目一样运作。用设计系统和共享组件来加速设计和开发过程，但使用开源软件的方式，开放地维护和协作它们，避免它们掌握在少数设计师手中、反而拖后腿
  
  
• 通过在设计过程中的自动化，提高设计工作可见性。比如自动生成元素、自动输出更标准格式的设计交付物，这些自动化能解决设计师的时间，也让程序员更直接地了解交付物（注3）
  
  
• 像农民一样计划时间。农民靠天吃饭，每天计划第二天的行动。作者建议多创造、少提前估算和规划任务，随时调整，不断优化
  
  ---
  
  随便说几句
  
  估计推特上的多数设计师既不会喜欢这两篇文章，也不觉得这种该产品总监操心的事跟自己有什么关系
  
  这么说吧，好设计师是能发现问题并解决问题的人，现在已知的大问题是设计交付效率很低、出错机会很高，如果你作为设计师能为自己和团队提高设计交付效率、减少出错机会，升职加薪养小三的目标就近了很多
  
  而推特上的独立开发者、小创业团队的老板，我也建议各位琢磨一下这两篇文章
  
  各位可能更喜欢先做开发、再找美工美化一下的研发流程，而实际上这种退而求其次的流程不见得多管用。如果能在设计协作流程上做一些调整，像前文所说一样更平行地和设计师协作，效果肯定好过事后找美工描个皮
  
  ---
  
  注1：
  
  即使按照敏捷、精益、Sprint 等等方法进行更灵活的项目研发，研发过程中设计和开发之间也往往是两个独立的瀑布阶段
  
  注2：
  
  这是我通常建议客户的做法，也是之前创业时我们自己团队的做法。小公司、小团队在这方面有天然优势，很多时候大家一起吃饭、唱歌就能很好地催化设计师和程序员协作（别搞团建，那是大公司的破事）
  
  注3：
  
  这也是现在 Figma 使劲发力的方向，在 2023 年的 Figma Config 大会之后，很多设计师抱怨今天的 Figma 强迫设计师要学会像程序员一样思维、说 Figma 变得像可视化的编程工具……都可以看做这种自动化思路的具体实现
  
  Figma Config 大会还留下了一个伏笔：用 AI 自动生成设计。这个 AI 很多功能还不得而知，不过可以预见，它生成出来的设计也更加自动化、更便于交付