In one of my previous companies, we had a separate project on GitHub (think of it as a Jira epic) where we collected various feedback after every release. Not to say we weren't expecting feedback outside of that time frame, but after every release is just when we received the most feedback.
Once the bigger wave of feedback came in, that project went through triage (usually by the project managers, etc), where every single point of feedback was given some sort of resolution (whether it's a bug we need to fix, a good feature request for the future, or something to not be done at least for now). Every single task had to get a resolution. After that, we had a filter where each of the tasks moved into their respective projects (bugs, features, etc) and we went on from there.
The company Linear [1] has pretty good systems built for triaging [2] for example. In another company, I was in a team with two other designers, who basically dumped all the feedback they received (or had the feedback be dumped) into triage and they reviewed it every once in a while.
We collect feedback directly through our support system (getconnect.tech), which is tightly integrated with our product development tool — Teamcamp.app. Once it lands, our team picks it up and turns it into action. Simple, seamless, and nothing slips through the cracks.
we've tried a bunch of different approaches and honestly the best feedback comes from getting people in a room (or zoom) together
widgets are fine for quick "this button doesn't work" stuff but for real UI feedback you need context… what were they trying to do, where did they get confused, what did they expect to happen
we do weekly design reviews where everyone can see the same screen and talk through flows in real time. way more valuable than async comments scattered across different tools
the trick is making it feel collaborative instead of like a critique session. when people feel heard they give way better feedback
In one of my previous companies, we had a separate project on GitHub (think of it as a Jira epic) where we collected various feedback after every release. Not to say we weren't expecting feedback outside of that time frame, but after every release is just when we received the most feedback.
Once the bigger wave of feedback came in, that project went through triage (usually by the project managers, etc), where every single point of feedback was given some sort of resolution (whether it's a bug we need to fix, a good feature request for the future, or something to not be done at least for now). Every single task had to get a resolution. After that, we had a filter where each of the tasks moved into their respective projects (bugs, features, etc) and we went on from there.
The company Linear [1] has pretty good systems built for triaging [2] for example. In another company, I was in a team with two other designers, who basically dumped all the feedback they received (or had the feedback be dumped) into triage and they reviewed it every once in a while.
[1] https://linear.app/
[2] https://linear.app/docs/triage
We collect feedback directly through our support system (getconnect.tech), which is tightly integrated with our product development tool — Teamcamp.app. Once it lands, our team picks it up and turns it into action. Simple, seamless, and nothing slips through the cracks.
we've tried a bunch of different approaches and honestly the best feedback comes from getting people in a room (or zoom) together
widgets are fine for quick "this button doesn't work" stuff but for real UI feedback you need context… what were they trying to do, where did they get confused, what did they expect to happen
we do weekly design reviews where everyone can see the same screen and talk through flows in real time. way more valuable than async comments scattered across different tools
the trick is making it feel collaborative instead of like a critique session. when people feel heard they give way better feedback