
在开源世界里,工程驱动的流程占据了主导地位——快速反馈循环、终端工具、Git工作流,这些都构建了透明开发的基石。然而,一款真正杰出的软件,离不开能够赋能用户的优秀体验。正是基于这一信念,我将这个话题带入了Canonical的“开放设计”倡议中。最理想的讨论场合,莫过于在柏林举办的FOSS Backstage 2026大会上。
为了深入探讨,我组织了一场汇聚开源领域顶尖设计师与工程师的圆桌对话,邀请了四位嘉宾:GitHub高级设计总监Glòria Langreo、Open Source Design核心维护者兼Home Foundation(Home Assistant)设计师Eriol Fox、以及Canonical工程经理David Edler。以下是我从题为《在工程主导的环境中导航》的讨论中收获的精华。
最常见的误区之一,是认为设计师和开发者需要彼此独立的隔离式工作流。Glòria直接反驳了这种观点:在GitHub,团队采用EPD(工程、产品、设计)一体化模式,步调一致地推进工作。最终用户并不在意你内部如何分工,他们只关心最终产品。
“根本没有所谓的‘开发者工作流’和‘设计师工作流’之分……我们应该努力将它们融合,让二者几乎无法区分。”——Glòria Langreo
实现融合的关键,是将设计直接嵌入已有的工程循环中。Eriol分享了一个案例:在标准工程QA流程中新增“设计QA”环节,使得代码审查变成了双方共同探讨的协作空间,彼此从不同视角理解“通过”的标准。David从工程管理角度表示赞同,他认为在执行任何PR合并前,设计QA是必不可少的步骤——设计师必须核实最终实现是否忠于原始设计意图。
设计绝非最后才添加的“抛光层”。如果体验出了问题,就必须像修复糟糕代码一样立即处理,而不是等到最后。
文化冲突通常源于对另一方所面对的限制缺乏理解。例如,Glòria提到,设计师可能因为一个看似简单的UI筛选器被后端数据模型阻止而沮丧,进而错误地认为开发者“懒惰”。解决之道?设计师需要扩展技能,去理解架构和数据模型的实际运作方式。
同样,工程师在设计稿中总会发现边缘情况。双方需要建立一种平等批评的文化——在无惧氛围中坦诚反馈。沟通至关重要。但在开源社区中,异步协作是常态,面对面的会议很少。Eriol提出了一条创新思路:
“我一直以撰写优秀文档的方式来组织我的设计文件。”——Eriol Fox
这意味着将设计文件视为文档。通过在设计稿中加入版本控制、日期记录和决策日志,设计师就能用开发者尊敬的语言说话。共享工作空间和规范能消除摩擦,使团队更高效地知晓做出了什么决策、如何做出以及为何做出。
在那些设计可能被视为“次要于发布功能”的环境中,如何证明其影响力?答案很简单:把产品放到真实用户面前。据David说,让工程师与研究员或设计师一起参与用户测试,会带来巨大的动力。亲眼看到别人在使用工具或产品时挣扎,会让你立刻想把它做好——这一点在座嘉宾都有切身体会。
Glòria分享了一个例子:团队观察到一位视障用户在注册流程中遇到的困难后,第二天清晨就被工程团队优先处理了无障碍问题。Eriol则提到,一位工程师参与肯尼亚实地测试,在弱网环境下对应用进行压力测试;结果这位工程师彻夜兴奋地根据新视角编写用户故事(希望他后来也补了觉)。
除了用户测试,Glòria指出,UX工作——例如标准化模式、构建设计系统——本质上是系统思维。当开发者意识到标准化UI组件意味着可以删除遗留代码、加速扩展并减少技术债务时,获得工程支持变得容易得多。
打造卓越的开源软件,需要优秀的工程和深思熟虑的设计并行。前进的道路建立在相互好奇与协作之上。
致所有阅读本文的工程师:不要害怕寻求设计输入,主动询问用户需求,参加设计会议。致设计师们:不要被技术门槛吓倒。放低你的学科吊桥,走进工程空间,观察他们如何工作,并做出真诚的贡献。正如Eriol所说:“我们不是对手,而是同一支队伍。”只有双方携手,开源才能真正释放其全部潜能。
关注微信号:智享开源 ,及时了解更新信息。
原文链接:https://ubuntu.com//blog/decoding-design-how-design-and-engineering-thrive-together-in-open-source
| 投稿作者 | 作者网站 |
|---|---|
你必须 登录 才能发表评论.
| 微信捐赠 | 支付宝捐赠 |
|---|---|
![]() |
![]() |
扫码关注公众号:智享开源

[blog_mailer_subscribe]
还没有任何评论,你来说两句吧!