用户反馈驱动的迭代

多数 game user feedback（玩家反馈）是以一句话的形式到达的：匹配太慢、手机上棋盘太小、想再来一局。在 YiBoard，它通常还带着一个复盘 ID，这意味着我们能打开对方当时看到的具体局面，而不是从措辞里猜。这一个差别决定了我们怎么读 feature requests board game（棋类功能需求），也决定了我们的更新说明为什么短而具体，而不是像在写广告。只想下棋的话，对战页一直开着。

三条渠道几乎承载了全部反馈，而每条渠道携带的证据类型都不同。它们彼此矛盾的次数也比想象中多：收件箱里声音最大的那条需求，很少和着法序列指向的是同一条。两者冲突时，我们先看重放。

玩家的建议从哪来

• 联系页：消息最长、上下文最多，通常来自已经下过十局以上的人。
• 被分享出去的复盘链接：一个字都没有，但着法序列能告诉我们，没人在看的时候大家实际在用哪种规则变体。
• 段位数据：完全不说话，而且常常最先发现问题。让胜率失衡的改动，会在这里比任何人写信来得更早出现。

棋类功能需求怎么排序

我们用三个问题，按这个顺序问。第一个过不了，就不会走到第二个。

• 它会不会动到规则或裁判？规则改动推进得慢，因为服务器端裁判是唯一一处出错就会同时对所有人不公平的地方。
• 它能不能帮一个新玩家下完第一局？这类排在最前面，因为整个产品的主张就是有人能在一分钟内开局。
• 它是不是只对每天都下的人有意义？这类排在最后，其中有相当一部分永远不会做。

社区驱动的开发在这里长什么样

社区驱动的开发听起来很慷慨，直到你得公开说一次不。我们跑的版本更窄一点：公开需求、公开决定、公开理由。一条建议被否掉，说明里会写清楚它卡在三个问题中的哪一个，以及什么情况会让我们改答案。

这有个值得说清楚的副作用：玩家不再重复发同一条建议了，因为他们看得见它停在哪。开始公开决定之后，收件箱变小了，也更有用了，这是开始时没预料到的。

从建议到上线的几个例子

举几个例子，好让上面的排序规则不只是一句口号。

• 键盘操作：提出的人不多，实现成本低，却替指针操作不精确的人移走了一道真实的门槛。
• 不用账号也能分享复盘：被反复要求，而且符合第二条，因为分享出来的一局是多数新玩家进来的入口。
• 十五路棋盘的移动端布局：三个人分别发来了同一处裁切问题的截图，这是最快的证据。

我们拒绝什么

两类需求是关着的，说在前面能替所有人省时间。任何会在棋盘上放广告的东西都不做，这个设计选择在免费不是营销里讲过。任何要求先注册才能落第一子的东西也不做，因为免注册承诺是产品其余部分的地基。平台下一步往哪走，写在开放 API 的设想里。

FAQ

在 YiBoard 免费下一局

YiBoard (yiboardgame.com) — 中华棋类，浏览器即玩，免费无注册。 去下一局 · 更多博客 · 玩法指南