无疑,当今软件构造最困难的一方面当属产品设计。与其比起来,技术、招聘、筹资、美学设计以及出版微不足道。当我在谈论产品设计的时候,我是指这样一种过程,在这一过程中你决定你的产品要做什么和不做什么。我有一次突然想到,我们在GitHub把产品设计做得非常好,不如让你们对我们的产品设计流程稍作了解并且为解释这个流程如此高效的原因提供一些启发。

我得提醒你,我并不是一个“产品设计师”。在GitHub,我们不提供头衔——我们让员工自己挑选自己的头衔。我喜欢称自己为~设计师,因为我大部分工作是集中精力瞧瞧和体验我们的产品。但话又说回来,我把过去一周的时间花在了构建一个可以追踪和分发二进制文件以及更新我们的一些化简函数以便可以支持更新版本的MongoDB的应用程序。所以,对,我是~设计师。不过也许这样说我便可以承上启下了。

人人都是产品设计师


在GitHub,人人都是产品设计师。为了把我们的产品做得更好,我们只雇用我们信任的聪明人。在这里没有产品经理指挥你的工作。开发新特性不需要通过行政上的签署。行政人员、系统管理员、开发人员以及设计师都一样参与构思、开发和移除产品特性。

让“产品设计师”或者首席行政官在那里嚷嚷他们将要“专注产品设计了”,对我来说这些没有多大意义。难道你们不正是在聘用使用过你们产品的聪明人吗?难道你们不相信你们的员工吗?难道在你们公司工作的每一个人不想让你们的产品变得更好?难道这没有让所有人在每时每刻都充当了产品设计师?

基于以上这些,我在面试时(或者对那些不知道他们正在面试的人)提的问题中,我最喜欢的两个是:

  1. 你想在GitHub里看到什么?
  2. 你认为哪些特性被我们搞砸了或者应该移除掉?

这可以显示出人们的激情以及立即凸显你们有的问题。有些人就是对于你们的产品有跟你们不一样的远见,这又有什么呢。

疯狂地记下想法


我们的内部百科充满了想法。旧想法。烂想法。好想法。半生不熟的想法。关键是我们有一个可以分享我们的奇思异想的圣堂。这一页百科讨论了比较视图,其最后成为了Pull Request 2.0——可以说是我用过的最好的代码审查工具了。

大部分时候,有些人增加的想法并不是原创的。而是我们私底下讨论过的,在其它产品看到过的,或者也许是对于我们自己的思考。但这无关紧要——看到其他人写下了跟你一样的想法会让你对那个想法倍感兴奋。随着其他人也跟着说他们乐于看到那个特性,对这个特性的兴奋感也会越来越强烈。最终,你们有4个工程师在晚上11点半的时候在捣鼓某样东西,因为你们急切地想要看到它的实现。

持续试验且重复


现在我们的主代码库有65个分支。这还不包括其它十几个合起来共同呈现什么是https://github.com的代码库或者139个在我们组织下面的代码库。不用说,在这些分支里有大量的特性、抗特性和半成熟想法。有时它们是真的很棒但不是功能化的特性,有时它们又是真的很丑但完全功能化的特性。

我们总是发送拉请求(pull request),把它们搬上舞台,询问别人的看法。在会上谈论某个特性和制定某个规范是一件事情,而编码实现一个可以工作的原型是一种更有效率的方式。我们总是不停地在仅提供给员工使用的产品里运行试验性特性。没有比真正地在使用某一特性这一方式能够更好地检验这个特性是否真正适用。

一旦某个特性推出了,准备好让用户使用了,那么会有100%的可能会有人想要改变此特性的某些方面。因此我们重复——修改、推广,在拉请求里讨论——不断重复直到好到可以给公众使用。

这样,我们的拉请求通常都是壮丽的史诗。事实显示拉请求能够完美地试验新特性,同团队讨论这些特性,以及让别人帮助你发布它们。看看这条拉请求,我们用它来发布我们组织的资料。(有趣的轶事:这条拉请求是在我们发布pull request 2.0之前就做出来了——我们持续不断地使用试验性特性)

摒弃特性


你不能够运营某件产品然后假装成你的所有想法都是完美的。你是会有烂想法,不适用的想法,以及该被丢掉的特性的。不要害怕摒弃想法。你花在某些东西上的是时间是毫无意义的。把作品丢掉并不会让你损失任何东西——你是在选择不让你的产品变得更烂。

我们做的第一版的https://jobs.github.com根本没有跟我们第一天发布的东西共享哪怕一个功能。这次我们没有重复——我们直接抛弃了这花了我们几个月的作品,因为我们意识到它很烂。我们开始发挥我们的创造力并且意识到我们无法找到不必惹恼我们的用户而能够赚到钱的方法。所以我们抛弃了那个想法然后重新开始——即使我们本可以发布它并且立即开始赚钱。

你发布某些特性,因为你为它们花了时间和金钱,这是懦夫的借口。摒弃特性要有种——长点吧。

时刻争论


我们的工作环境并不安静。我们有时在酒吧里争论,有时在篝火会上争论,有时在电邮上争论。不管是新雇员还是CEO们,都一样。这不是针对个人的——这都是为了使我们的产品更好。如果你不是被迫而合理化你为产品做的选择,那谁会说你正在做好的决策?

跟你的同事争辩并不是什么坏事情。这不是在创造一种消极的工作环境——而是帮助你做出好决策的工具。做一个无聊的拉拉队长,对所有人欢呼他们的想法棒极了,这是有害的、短视的。争辩然后做出好决策吧。

跟你的用户谈谈


我花了一天里好大一部分时间通读我们的支持站点,邮件列表,twitter上的反馈,以及关于git和GitHub的博文。聆听我们用户的声音极其重要——他们总是有很棒的想法。有时他们也有让人震惊的极好的想法。比如Tom写道的:

别给你的用户他们要求的,给他们想要的。

我们也花了大量实实在在的时间跟我们的用户在一起。我们在旧金山有每月一次的见面会,并且你可以很好地保证任何正在旅行的人会主持这种见面会,不管他们在哪座城市。线上的人会很疯狂。当你面对面地跟某些人交谈着的时候,你会很难形容那种疯狂。这不得不让人思考他们要说的且让他们想到在产品背后有鲜活的人。

“情人眼里出西施”


我们知道,产品设计不仅仅是增加和移除特性,它还是用户怎样感知这些特性。谁会在乎,如果某些分析师认为你的公司做得不错而用户不这么认为?

弄篇好博文解释一下新特性绝对是致命一击。这允许我们框出新特性以及解释我们的想法。这也可以展示出我们的发布记录——我们总是努力试图发布和向别人讲述这些东西。

如果你像Twitter一样两年一次重新设计你的整个产品,那就是一件大事情了。如果你的用户百分之百不喜欢它,你会让他们发疯的。但是如果你每两个月发布一些新东西,你的用户不喜欢其中的10%——那他们总的百分比还是正面的。

同时,我们还知道我们不做的跟我们正在做的一样重要。我们不发布路线图或者在时间表里承诺新特性——我们少承诺多兑现。我真的觉得这就是为什么总的来说我们的用户会对我们的产品设计感到满意。

别给你的用户他们要求的,给他们想要的。少承诺,多兑现。

原文:Product design at GitHub

欢迎参加iTran乐译4期!