如何让设计师参与到你的软件项目

我参加了 Una Kravets 在 OSCON 上的演讲 “开源设计：一个爱情故事”，此前不久我采访了她。

首先，Kravets 提醒我们，我们聚集在 OSCON 是为了受到创新的启发。她还指出（我们都知道）技术领域的多元化程度还不够，而这个问题在开源世界中尤其严重。当 Kravets 谈论多元化时，她不仅仅是指性别和种族，还包括各种技能组合。

Kravets 向我们展示了一份她找到的报告。该报告回顾了 23,493 个 GitHub 项目，发现其中 75.3% 完全没有性别多样性。这让 Kravets 想起了 Malcolm Gladwell 的一句名言：“我们本可以拥有的世界比我们已经安于现状的世界要丰富得多。”

Kravets 说，我们已经安于现状的世界是破碎的。我们热爱开源和开源社区，但它是不完善的。但 Kravets 认为我们有能力让它变得更好。

为了解释如何做到这一点，Kravets 与我们分享了一个关于道路的故事。这个故事有三个角色：设计师、开发者和商人。

商人说：“我们需要从 A 点到达 B 点，” 他告诉了开发者。开发者说：“好主意，让我们用这项新技术来构建它。” 然后两人找到了设计师，她说：“让我们在海岸边修建道路，这样人们就可以享受旅程。”

这个故事的寓意是什么？多样性创造更好的项目。那么，为什么设计师不参与开源呢？

Kravets 从两个方面回答了这个问题

1. 因为许多设计师抱有这样的想法，即他们的工作必须获得报酬。我们必须反对为免费工作是不好的这种观念。
2. 第二个原因是“博物馆效应”——人们害怕触碰东西和破坏东西。

然后 Kravets 提出了两种鼓励设计师参与开源项目的方法。

鼓励更开放的设计/开发工作流程

不要独自设计，Kravets 说。在开放环境中进行设计，以便每个人都能在过程中收集反馈。如果你让设计师独自工作，当她带着最终产品回来时，她可能会对反馈和修改请求感到沮丧。相反，要求设计师作为团队的一员在开放环境中工作。（Git 可以作为一个起点，Kravets 说。）

Kravets 在 GitHub 上创建了 gulp-starter-env，以便为设计师提供他们可能需要完成工作的工具。使之成功的下一个关键是分享兴奋感。因此，当 Kravets 的设计师团队弄清楚如何推送到 git 时，她与他们一起庆祝这些胜利。告诉设计师她必须学习编码会让她产生抵触情绪，而与她分享你对代码的热情会让她感到好奇。这就是我们想要做的，Kravets 解释道。

培养设计参与

对于 Kravets 的团队来说，这很容易——因为他们已经在使用 GitHub 并且对此感到兴奋。但是我们如何与其他团队一起做到这一点呢？为此，Kravets 为我们提供了 CARE 首字母缩略词。

沟通 (Communication)

这就像简单地告诉人们我们想要他们的帮助一样简单。在 GitHub 中，我们可以将问题标记为 “design”，以便向设计师展示他们可以处理的问题。

我们还可以创建项目看板。这些看板可以包含有关设计师如何参与的所有信息，并列出我们的设计标准（例如颜色、样式指南等）。

使用 GitHub，我们可以创建一个“清单”，作为一个可视化方式，让设计师参与到我们的项目中，并帮助他们可视化他们的进度。

最后：使用大量图片！设计师是视觉化的，这些图片可以帮助人们了解事物应该如何运作。

可访问性 (Accessibility)

问问你自己：“人们可以开始参与我的项目吗？” 始终确保有“入门”文档。“Readmes” 在 git 上通常是无用的，因此让你的 Readme 更容易访问和更有帮助。假设阅读它的人没有编码经验。创建一个词汇表来帮助新的参与者。在开发过程中，我们都使用行话，但新手并不理解所有行话。

Kravets 做了一项非正式研究，发现拥有网站、文档和演示的项目表现出更多的多样性。而具有更多多样性的项目更有可能拥有文档、网站和演示。因此，文档增加了多样性，而多样性增加了文档。我发现这很有趣，因为我是一个项目（Koha）的女性文档经理，在我开始参与之前，该项目没有完整的 manual。

尊重 (Respect)

设计建立社区。我们可以从 logo 中看到这一点。Logo 创建了一种视觉资产，人们可以围绕它聚集。Kravets 向我们展示了一个 GitHub 线程，其中一个社区试图一起设计一个 logo，但事情变得非常糟糕，并开始吸引喷子。尊重不仅仅是吸引设计师所需要的；它也是保持开源项目持续运行所需要的。

同理心 (Empathy)

开源是关于人的！我们应该像对待家人一样对待贡献者。我们的社区中存在一种争论文化，在这种文化中，技术上的正确性比倾听想法和团队合作更重要。

为了结束她的演讲，Kravets 建议我们为我们的社区建立反馈指南

• 问而不是说：“你为什么决定……”
• 具体一点：“当你在调用……”
• 解释你自己：“查看这篇博客文章……”
• 提供解决方案：“也许尝试……”
• 避免夸张：避免使用 “从不”、“不” 和 “不要”
• 使用表情符号：因为它们让一切都变得更好

本文是 OSCON 2015 的 OSCON 系列 的一部分。OSCON 涵盖了所有开源内容——全栈，包括你每天工作中使用的所有语言、工具、框架和最佳实践。OSCON 2015 将于 7 月 20 日至 24 日在俄勒冈州波特兰举行.