Skip to content
YiBoard
Play

2026-10-25

Iterating on user feedback

How we read player feedback: the three channels it arrives on, the three questions we sort it by, and the requests we decline outright. With real examples of what shipped.

#product#community

Most game user feedback arrives as a sentence: the matchmaker feels slow, the board is too small on my phone, I want a rematch button. On YiBoard it usually arrives with a replay id attached, which means we can open the exact position someone was looking at instead of guessing from the wording. That one difference shapes how we read feature requests for a board game, and it is why our release notes are short and specific instead of promotional. If you only came here to play, the play page is open.

Three channels carry nearly everything, and each one carries a different kind of evidence. They also disagree with each other more often than you would expect: the loudest request in the inbox is rarely the one the move lists point at. When the two disagree, we watch the replays first.

Where player suggestions come from

  • The contact page: the longest messages and the most context, usually from players who have finished more than ten games.
  • Shared replay links: no words at all, but the move list shows which rule variant people actually pick when nobody is watching.
  • Ratings data: silent, and often first. A change that makes win rates lopsided shows up here days before anyone writes in.

How feature requests for a board game get sorted

We ask three questions, in this order. A request that fails the first one does not reach the second.

  • Does it touch the rules or the referee? Rule changes move slowly, because the server-side referee is the one part where a mistake would be unfair to every player at once.
  • Does it help a new player reach a finished first game? Those go near the front, because the whole claim of the product is that someone can start a match in under a minute.
  • Does it only matter to people who already play daily? Those go last, and a fair number of them never ship.

What community driven development looks like here

Community driven development sounds generous until you have to say no in public. The version we run is narrower: we publish the request, we publish the decision, and we publish the reason. If a suggestion is declined, the note says which of the three questions it failed and what would change our answer.

That has a side effect worth naming. Players stop sending the same request twice, because they can see where it sits. The inbox got smaller and more useful after we started posting the decisions, which is not what we expected when we began.

Requests that became shipped changes

A few examples, so the sorting rule is more than a slogan.

  • Keyboard play. Asked for by a handful of people, cheap to build, and it removed a real barrier for anyone who cannot use a pointer precisely.
  • Replay links without an account. Requested constantly, and it passed question two, because a shared game is how most new players arrive.
  • Mobile layout for the fifteen-line board. Three separate people sent screenshots of the same clipping problem, which is the fastest kind of evidence there is.

What we say no to

Two categories are closed, and saying so up front saves everyone time. Anything that would put advertising on the board is out; that design choice is explained in free is a design choice. Anything that needs an account before the first move is out as well, because the no-signup promise is the ground the rest of the product stands on. Where the platform goes next is written up in our open api thinking.

FAQ

Will anyone read my suggestion?

Yes. Every request that reaches the contact page gets read, and it gets a decision: build it, queue it, or decline it. A decline comes with the question it failed.

Why do changes that look small sometimes take months?

Because anything that touches the rules or the server-side referee is not a front-end patch. A referee bug makes every match unfair at once, so those changes rerun the full rule test suite.

Where should I send a feature request?

The contact page is the most direct route. If you can include a replay link, we can look at the exact move you mean.

Play a free game on YiBoard

Related

Keep exploring

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