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

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

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

培养设计参与

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

沟通

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

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

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

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

可访问性

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

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

尊重

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

同理心

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

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

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

本文是为 OSCON 2015 撰写的 OSCON 系列文章的一部分。OSCON 是关于开源的一切——完整的堆栈，包括您每天工作中使用的所有语言、工具、框架和最佳实践。OSCON 2015 将于 7 月 20 日至 24 日在俄勒冈州波特兰举行.