Feedback Widget or Inline Board: Which Should Your App Use?
There are two ways to ask users for feedback. You can float a button over every screen that opens a small panel, or you can build feedback into your navigation as a screen of its own, with a list of requests people can browse and vote on. Both are reasonable, and they collect different kinds of feedback. Choosing between them is mostly a question of what you want to hear.
The short version
- A floating widget is always visible, so it collects more and quicker feedback, much of it short bug reports and reactions to the screen the user is on.
- An inline board is a screen or page in your navigation. It gets fewer visits, but the people who come are ready to read, vote and write a proper request.
- If you want votes, an inline board wins. A small panel has no room to show what others already asked for, so you get duplicates.
- In native apps, a floating button rarely feels at home. A row in Settings or a tab is the familiar pattern.
- The middle path works best: an inline board as the home for requests, plus a few small entry points in context that open it.
What each one is
The floating widget
A button pinned to a corner of the screen, usually with a speech-bubble icon. Tapping it opens a panel or modal with a short form, and sometimes a few recent ideas. It is on every page, so users never have to look for it.
The inline board
A screen that belongs to your app's structure, like any other. In a mobile app it is often a "Feature requests" row in Settings, or a tab. On a website it is a page such as /feedback, or a section of your help centre. It shows the list of requests with their vote counts and statuses, lets users open one to read and comment, and has a button to add a new one.
The trade-offs
| Floating widget | Inline board | |
|---|---|---|
| Discoverability | High. It is always on screen. | Lower. Users have to find it, so you have to link to it. |
| Context | Good. The user is on the screen they are reacting to. | Weaker. The user has left the moment they wanted to talk about. |
| Kind of feedback | Short, immediate, often bugs and complaints. | Considered requests, votes on existing ones and comments. |
| Duplicates | More. Users rarely see what others already wrote. | Fewer. The list is right there, so people vote instead. |
| Space | A small panel. Browsing and reading comments is cramped. | A full screen for the list, the detail and the conversation. |
| Layout conflicts | It can cover buttons, tab bars and content, and competes with chat bubbles and cookie banners. | None. It is part of the layout. |
| Accessibility | Needs care: focus order, screen reader announcements and a way to dismiss it. | Behaves like every other screen. |
| Cost on every page | Usually a script or overlay loaded everywhere. | Loaded when someone opens it. |
When a floating widget fits
- Beta and early-access builds. You want every rough edge reported in the moment, and testers expect to be asked.
- Web apps with long sessions, such as dashboards and editors, where a small corner button costs little and users spend hours on one screen.
- When most of what you want is bug reports and quick reactions, not a ranked list of feature ideas.
Even then, give it a way out. Let users hide it, keep it clear of your primary actions, and make sure it does not sit on top of a phone's home indicator or your own tab bar.
When an inline board fits
- You want votes. Ranking demand needs a list people can see and add to, which a small panel cannot show well.
- Native mobile apps. On iPhone and Android, people tend to look for settings, help and feedback in your navigation, not hovering over the content.
- Consumer apps with short sessions. A permanent button on a screen people use for thirty seconds is clutter.
- You want to close the loop in public. A board shows each request's status, so users can see that something they voted for moved to In Progress.
In your app and on the web
In a native app
The board is a screen you push from Settings or show in a tab. Users already know how to get there and back, and it inherits your navigation, dark mode and text size. The question is not whether to have a widget, but where to put entry points. Good places are an empty state ("Can't find a trail filter you need? Suggest one"), the end of a flow the user just completed, and the place where a feature they are missing would be.
On a website
On the web, a floating button is more common and less intrusive, because pages are wider and sessions are longer. But the same split applies. A /feedback page linked from your footer, help centre and account menu is where people browse and vote. A small button in the corner of a marketing site mostly collects pre-sales questions, which belong in your support inbox instead.
The middle path
Most teams end up here: one inline board as the home for every request, and a few small links in context that lead to it or straight to its submit form. You get the context of a widget at the moments that matter, and the votes and fewer duplicates of a board.
For Trailmate, a fictional hiking app, that looks like this:
- A "Feature requests" row in Settings opens the board, where Offline maps leads with 248 votes and the Trail difficulty filter follows with 131.
- The empty search state on the trail list has a "Suggest a filter" link that opens the submit form.
- On the website, a
/feedbackpage shows the same requests, linked from the footer and the help centre.
Nothing floats, and a user who is missing something is never more than one tap from saying so.
How FeedbackKit fits in
The screens in FeedbackKit's SDKs are inline. In Swift and SwiftUI, FeedbackListView is a full request list with its own navigation, sorting and filtering, and an add button that opens SubmitFeedbackView, and each row opens FeedbackDetailView with votes and comments. You put it where it belongs in your app: a sheet from a Settings row, a navigation link or a tab. SubmitFeedbackView also works on its own, so a contextual "Suggest a filter" link can open the form directly. The Kotlin, Flutter and React Native SDKs have the same three pieces: a feedback list, a submit view and a detail view.
Users vote and comment inside your app, a new request starts with its submitter's vote, and voting stops when a request reaches Completed or Rejected.
On the web, FeedbackKit can show a project's roadmap and its board of requests on your own website through an iframe, and it has a feedback form page you can embed the same way. The roadmap lists the feature requests you mark for it, grouped by target month, with requests that have no date under "On Our Radar". The board shows open requests in status columns with their vote counts, and visitors can vote on it when you turn voting on. A visitor is counted by an anonymous ID kept in their browser, with no sign-in. The form takes a title, a category, a description and an optional name and email. You turn embedding on per project in the web dashboard, which gives you the iframe code and a direct link for each page. Embeds are on every plan, in light or dark. There is no changelog for your users, and no roadmap site hosted on your own domain.
Those pages sit inside your layout, like the board on a /feedback page. If you want a corner button anyway, it can be your own link to the form's direct link. And if you would rather build the whole thing in your own markup, the JavaScript SDK is a headless client for exactly that. How to add a feedback widget to a JavaScript web app walks through it.
Here is the inline board in FeedbackKit, with sample data from a fictional hiking app:
An inline request board
A floating button tells users you are listening. A board shows them what everyone else asked for and what you did about it. Give requests one home, link to it from the moments that matter, and start free to put that board inside your own app. Plans are on the pricing page.