来源:站酷 作者:DATS设计翻译组
最近我和Dribbble公司坐在一起谈论他们的设计和发展历程，该公司是InVision的客户，也是我钟爱的用户之一。如果你不了解Dribbble公司，那么就听我说吧，这是一个只能通过邀请才能进入的专门针对设计师的社交平台。设计师能在这里展示和讨论自己的作品，获得回馈，取得支持，同时与社群中的其他设计师进行交流。今天我特别激动地告诉大家，现在你可以通过InVision与Dribbble公司面进行对面交流。
我和Dribbble的联合创始人Dan Cederholm和Rich Thornett，谈论了Dribbble是如何通过一个小团队来运营一个大型的、各种观点互相交织的社交平台的。另一个问题是如何既达到商业目标又同时维持在社群中的信任感。
问：在Dribbble设计团队是如何组建的?
Dan: 我们是一个6个人的公司，Rich和我负责设计。把设计从其他产品团队分离出来是很难的。其中有许多合作和交集，可能因为我们团队非常小，所以每个人的办公区都挨得很近。
我们没有庞杂的公司结构，岗位非常灵活。例如，当某个想法迸发后，我们就一起协作，从视觉和实用两个角度将其展现出来。
Rich: 设计，产品信息结构和开发都是我们工作的一部分。我负责管理所有的问题，软件漏洞，可能实现的各种想法，将要搭建的各种事物，以及开始准备进行的项目。我要保证每个点都要符合我们产品的计划和愿景。
问：你们的工作流程是什么样的?
Rich: 我们使用GitHub(全球最大的社交编程及代码托管网站-译者注)来进行公司的合作项目，无论它是一个专题节目，或是一个既视感的想法，甚至是一次采访或者交谈，我们都会这样操作。这是一个定义我们讨论问题的方式。
我们同时利用GitHub和Slack(是聊天群组 + 大规模工具集成 + 文件整合 + 统一搜索-译者注)来建立自己的知识库。这是我们公司企业文化的主要部分：那就是怎样进行沟通，从哪开始我们的设计和项目。
在项目管理方面，我们用Waffle(一款相片镶嵌软件-译者注)作为第一层铺垫放置在GitHub上--它能显示出有关GitHub的柱状图信息，这样我们可以用鼠标在单个任务文件周围移动即可以显示其进程和我们需要注意的地方。
我们做的每个项目都会收到大量的评论，评论的方式通常是在GitHub里“拉请求”(pull request)，然后将这些“请求”拖进Waffle 中的“需求评估(Needs Review)”菜单栏里。在此时，我们将对pull request中提出的某个问题一起研讨解决方案。如果有必要的话，我们将返回绘图板重新操作。或者在做了一些改变后如果我们很满意，我们将会部署和合并。
对于我们的远程小团队, InVision's Liveshare一直是一个非常有用的和有趣的功能，能够直观地讨论相关设计。这感觉就像我们拿着记号笔围坐在一起，时刻准备迎接各种反馈。
问：设计文化又是什么样的呢?
Dan: 我们乐于在私下进行一些尝试，如果不好，也不怕将设计稿丢弃。这对只想完成任务并将项目上线的人来说这样做可能有点冲动，，但是我们想带着批判眼光审视设计。
虽然我们只是一个拥有相同目标的很小的设计工作团队，但其实只有我本人在从事视觉设计。
Rich: 我们一般是这样做的,Dan将其设计好的视觉效果分享给我，然后，我会提出自己的观点和意见，即使我没在第一时间参与到这个设计。
Dan擅于接受反馈，然后会拿出更牛的设计，或专门针对那些批评性建议的设计。
我能直接从视觉角度看出设计上的问题，但不能创建一个解决方案。而其他人可能不具备这种视觉审视的能力，但却能对设计提出有的放矢的建议——我们都是就事论事。
Dan: 不是所有的程序员都可以将设计改善进行视觉化处理。如果你经常收到来自某人的意见，然而你若不重视这些意见，长此以往，这将成为一个问题。
我始终知晓最终的产品总会比预料的好。
Rich: 对那些不受欢迎的反馈，Dan和我会使用一个安全词。比如他会说，“我喜欢你的活力四射”，
我就知道此时可以省略一万字了。
在刚开始遇到这类情况的时候，我们俩可以坐在沙发上盯着相同的屏幕交流讨论很长时间(唇枪舌战个几百回合)。后来我们终于能够商讨出一种设计风格，Dan负责设计，我负责编写，此时才注意到哪种风格是我们的真爱，哪种风格是我们嫌弃的，我们需要在哪些方面做出改变。
尽管我们是从不同角度出发看待事物，但是我们有着相似的鉴别力。所以即便我们的想法出现分歧，也能使大部分事情在收尾时有一个皆大欢喜的结果。我们很幸运，透过相似的镜头看世界。
问：你们作为一个小团队会面临什么样的挑战?
Dan: 遇事就纠结。我们不仅仅是写代码和做设计，还要管理企业，根据需要引入大量项目。
近期我们开始考虑把我们不喜欢做的业务委派给其他员工来做。
Rich：这个管理模式的切换是最大的挑战——你得决定哪些事情要由自己掌控，以确保事情朝着预期目标顺利发展;哪些事情可以放权给其他小伙伴，让他们觉得有足够的授权。
我们正在试图弄清楚这个掌控和放权的界限该如何判定，我们将继续做好工作，同时有效地沟通，尽可能多的给团队小伙伴委派项目。毕竟，他们在这里也做出了贡献，也希望能在工作上留下浓墨重彩的一道印记。
这个管理模式的切换是最大的挑战——你得决定哪些事情要由自己掌控，以确保事情朝着预期目标顺利发展;哪些事情可以放权给其他小伙伴，让他们觉得有足够的授权。
问：新功能的设计流程是怎样的?
Rich：一切都从谈话开始。我们总会记录我们说过什么，比如这个功能要实现的目标和它预期样子，所以我们从来不会忘掉曾经谈论的内容。我们会在GitHub上记录了所有这些信息，以便让分配到这些任务的人知道它的来龙去脉。
一般我们的流程是开发最先，UI随后——我们通常不从原型开始。你在脑海中总会有一个影像，但我们通常只是先从流程和一些文档下手。一旦开发人员准备就绪一些东西，他们会要求出CSS模型或者要求Dan做视觉图。
Dan: 像在开发人员很忙但我却没事做的时候，我会自己先做一些功能的原型，但大多数时候，就像Rich描述的一样。
Rich：较大的功能和一些跟用户有交互的新功能，会被最先建立模型，而那些视觉稿则是为了验证效果。这一切都取决于这个功能的本质：如果它是一个更具功能性的东西，它可能会先被着手开发。如果它是用户会看到的，那么会先让Dan做它的原型。
当决定某个东西是否需要先做原型时，“时间”是另一个衡量纬度，要保证Dan有时间去做。
问：在设计前就做开发的好处是什么?
Rich: 有时，在你考虑过主要用例、边缘情况、工作流、页面还有哪些地方需要视觉处理以及和用户交互之后，你会更容易知道怎么去做视觉构建。
Dan：当我们把开发放在第一步，我们会弄清楚细节和边缘情况。因此，从我们讨论到编码这个过程中，实际的功能会有些细微的改变。你认为的数据建模的方法可能会影响到用户界面，但你可能争论说，反过来才对。那么如果你也先用HTML做原型你也会遇到相同的问题。
问：你是怎样筛选来自社区网站的功能需求的?
Dan：会员们经常把他们的需求以图样的形式发布到追波上，我们也确实采纳了一些。尽管并不是所有的需求都是天才的构想，但是看到这些仍然非常有趣，至少说明社区的人们是活跃的。他们不会去花时间做他们不关心的事。这里没有一个正式的方式供人们来提出需求。我们会通过我们自己的支持渠道获得，而且我们会把确实有用的逐步完善后记录到GitHub，确保我们不会忘记。
问：你们的整个团队典型的一天是怎样的?
Rich: Dan, Susanna和我在塞勒姆工作，团队中剩下的人进行远程工作: Patrick在明尼苏达州，Ian在加利福尼亚，Allison在德克萨斯的奥斯丁。
Slack(企业聊天工具)变成了我们的办公场地。它不仅是我们交流沟通的工具，它也是我们的公司文化。一个典型的早上包括从支持者那里获取反馈信息，关注所有开发者提出的公开问题。现在，我们有越来越多的电子邮件要回复。
在午前或者下午稍早点的某个时候，我们会有意的去做那天希望去做的事情，从埋头写代码到讨论功能，招聘，或者一个马上就来的聚会。我们每天做的工作其实是取决于我们专注于产品工作还是在社区中进行反馈。
Dan：所以也许压根就没有典型的一天。
问：你认为在你的设计过程中最有力的部分是什么?
Rich：优质高效的反馈。我们拥有强大的工作方法——我们能够把做的事情通过讨论立即在反应在工作中。精简的流程让事情变得简单容易。
事无巨细，认真规划——工作不留任何死角。我们有一个强大的推动力保证事情在正确轨道运行，但我们仍然能观察和评论整个工作。希望这能让事情和我们所见的产品保持一致。
如何考量确实是一个未知数，但是我所乐见的是我们当前的设置给了我们一个掌握事情进行情况并建立快速沟通的能力的意识。
问：哪些价值观是你想尝试去以之影响你的设计和产品改造的呢?
Dan: 简单!追波的UI界面设计应该是尽量的无形的和无设计的，这样追波的功能才能被摆在最重要的位置。这就是为什么单色的黑，灰，白偶尔的被放在像水粉色这种亮色的东西里的原因。
为追波设计是一件既有趣又有挑战性的事情，因为你必须时时刻刻记得要显示各种功能。无论是什么它都要好看。
Rich: 作为一个码农，比起解决问题我更喜欢通过避免问题。让问题保持简单是我们的美学，同时我们有个价值观就是无论怎样都要避免复杂，这样能让我们把精力集中在我们认为重要的事情上。
我们在工作中一定会包含的3个问题
1.这个东西是否应该在这里?
2.这个是否有用?
3.这是否是个重要?
如果这些问题的回答都是否，那就让它消失。
问：当知道有固执己见的人在你的对立面时，你们内部是如何做设计决定的?
Dan：我们都已经很厚脸皮了。因为我们也是团队的一员，所以我们也能够察觉出来。当一些功能或者UI变化很快的时候，我意识到这对成员来说是很不和谐的。
我们会很小心地对待我们所传达的内容以及造成的所有其他影响。有很多事情我们可能搞砸，但是我们没有，都是因为我们对于改变很保守。
团体就是设计灵感和固执己见，而且经常会有这种厚脸皮的事情发生。你开始明白有些人他就是要唱反调，你学着去忽视它们。当然也有人会给你很好的反馈。
问：为自己设计是什么感觉?给别人设计又是什么感觉?
Dan：这很有趣，就像是一个社区，而我在其中会忘记我就工作在这里。另一方面，在追波有太多的天才，门槛太高，你会觉得自己不配在这里。我们的目标就是变得简洁并且让网站更易用，希望我们在大多数时候都达到了这个目的。
问：你们关注哪些衡量标准?
Rich: 我们并非不相信数据，但我们也不会关注太多的衡量标准去做为我们设计决定。我们只是在这个网站建立我们想要的东西。有些产品只想得到注册，因为他们是为了在不正常的方式下影响人们的行为而设计的。我们尝试去做的符合我们的用户需求。这是这个网站的重点。
我们十分密切地关注我们的销售状况。因为我们没有任何的资金赞助，我们所能做的只是一种赚钱的方式。同时它也决定了我们能否雇用他人。收入决定了我们能够做什么。
我们不关注用户表面行为，取而代之的是行为下的性质 (举个例子，)我们通过用户购买会员知道用户喜欢他们
我们知道就业信息板是成功的是因为人们正在使用它。我们也在追踪这些销售业绩。
我们并没有让Dribbble的用户达到最优化——我们只想让它变得更出色。我们绝大多数的员工都是倚靠直觉去做事：我们添加内容，同时增加价值。
Dan: 我们通过面对面的交流从成员中得到反馈。如果我们在开会但是没有人对dribbble提意见，甚至没有人会出现，我们想那绝不是一个好兆头。
Rich: 我们在不断地改善产品以满足用户的需求。我们更加专注于为产品做一个正确的事情并获得跟多的收入这样的话我们就有了更好的资源来回报社会。
问：你们有没有正式的审查过程?
Rich: 我觉得没有，我们的审查过程大概是下面这个样子的：
1.记录问题
2.讨论问题
3.提出可能的解决方案
4.讨论解决方案
如果Dan和我都喜欢它，那就是它了。我们并不喜欢在小细节上过于纠结，但是如果他影响到了用户体验，我们会验证它。
问：你们使用什么协作工具?
Dan: 大多数时候用GitHub。我会先用HTML和CSS做好原型，然后把它们的截图发到GitHub上那样大家就可以对它进行评论。一旦把项目放到需求列表中，我们的团队就会知道有事要做了。
Rich: 几乎每一个与产品相关的讨论都会在Github 得到解答。如果这个项目是我们即将做的，它就已经在需求列表中并且有条不紊地推进。当然GitHub支持Markdown也是我们喜欢它的原因之一。
为了快速得到反馈时，我们会使用Slack。
问：对于远程团队合作你有什么建议呢?
Rich: 把东西写出来，让大家清楚知道现在团队的进度和自己将要做的事情。我们会公布谈话内容，电子表格以及一些文件来解释每个特征的方向。队员不用去猜测我们在想什么。因为，我们的想法就在那里。
我们每周会开会议检查进度，有时候变成了关于个人故事的环节，但是我认为这其中是有价值的。
我们尽量在一年里聚会几次，增进团队成员之间的感情。这些聚会都是一些短途的旅行，但是有会持续的影响---当你再次进入聊天室的时候，你会发现与其他成员的关系更加亲密。
问：在不成为失信机构的前提下你该如何权衡客服对自己的业务需求呢?
Rich: 对于我们来说，这不重要。我们是一个小众网站，而不是 一个大型的广告推销网站。所以我们不需要去发明一些愚蠢的方法来增加用户的负担。
工作台就是用来打广告的。但是这是设计师麽所想的。付费会员提供很多有有用的功能。客户会员能够帮助商业的运行，而设计师会更加关注于他们所做的事情。
我们有一个横幅广告，但是希望不会让人觉得讨厌。我们认为我们正在尝试做的东西是有价值的。当你有着想法时，你就不会妥协于腐朽的主张。
Dan: 我们不会与客户有争执—并不是所有的可会都会支付—但是我们一直努力着忠于我们最初的想法。作为一个社会性的网站，你必须保持正直，否则它将只是一群顾客。
问：你能告诉我你认为设计的成功对你的产品有多重要吗?
Dan: 设计即是一切。
