如何在您的软件项目中 привле设计师

我参加了 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 中，我们可以将问题标记为“设计”，以便向设计师展示他们可以处理的问题。

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

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

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

可访问性 (Accessibility)

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

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

尊重 (Respect)

设计建立社区。我们可以从 логотипы 中看到这一点。логотип 创建了一个视觉资产，人们可以围绕它聚集。Kravets 向我们展示了一个 GitHub 帖子，其中一个社区试图一起设计 логотип ——但事情变得非常糟糕，并开始吸引 тролли。尊重不仅仅是吸引设计师所必需的；它也是维持开源项目运行所必需的。

同理心 (Empathy)

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

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

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

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