In the past weeks, we’ve been working on upgrading various features of the site and implementing upgrades based on feedback we’ve received from our users so far. In this blogpost I wanted to explain our process, take a look at how we go from feedback to feature, and give a few examples.
Feedback can come in many form, and it isn’t always clear what needs to be done, so the first step is extrapolating what the exact request actually is. Sometimes this is very clear, like someone reporting a bug or telling us they need to be able to do something specific for their campaign. But often it is less direct: a complaint that the sound the chat makes is too loud may mean we need to add volume controls, but maybe what users want instead is to disable it entirely, or maybe the sound needs to be replaced by a less intrusive one.
Some feature requests are even made entirely implicitly, that is, they are never actually requested by anyone. When we see users trying to accomplish a certain goal or working around something they perceive as a problem, that’s a good indication we can improve our platform there. We then try to provide tools to better support their solution, or offer an alternative if that could offer additional advantages.
Once it is clear what the feature request actually is, we do some filtering to determine if it matches something people have requested before, and if we need to make any adjustments for technical reasons. At this stage, we also assign priorities. While we don’t use a formal classification system for this, in general we try to separate emergency issues, necessary features, part-of features and nice-to-haves.
Emergency issues are things like pages not working or information not being saved — including the recent bug where people were unable to post in the community forum. These are usually bugs rather than feature requests and need to be dealt with immediately. Necessary features are features which are needed as soon as possible as they inhibit effective use of the site, even if not causing any technical problems. We generally try to resolve these as soon as reasonably possible as well.
Part-of features are improvements to systems we currently have on our development schedule. For example, adding additional features to the dice roller, when we have scheduled time to make the dice roller available in the chat. These features are often postponed slightly so that they can be implemented while we’re working on that part of the site anyway, thereby saving us development time overall.
Finally, the nice-to-have features are requests that we want to add but which aren’t needed right away. These will be picked up when time allows, and also help us to determine what larger part of the site needs to have some time scheduled later, effectively being promoted to a part-of feature if they aren’t resolved before we collect a few of them. Nice-to-have features can also be upgraded to necessary features when we see it being requested more than once.
It is our goal to always give at least some level of feedback to the people who reported the issue, be it a comment on the bug in the technical forum or a private message via the site or out of bounds — unfortunately, this isn’t always possible. However, we do always list any upgrades we make in the changelog at the end of the week and mark those which are made based on community feedback. So why not check out this week’s changelog to see if any of the features you requested are on there?
Even if it is not, please know that your feedback is very important to us and is a key part in making the site the best it can possibly be. So if there is something you like or dislike, some feature you’d like to see, or something you’d want to be available, be sure to let us know!