In-App Survey Widget for GitHub Issues

An in-app survey widget can ask a question at the moment a user finishes a task, then give the team an answer it can act on. BugDrop's custom flows support short questions, ratings, choices, and follow-up text inside a web app. Each completed flow creates a GitHub Issue, so this approach fits teams that already review product feedback alongside engineering work.

Use this guide when: you want a small, developer-configured pulse survey whose individual responses belong in GitHub. If you need audience targeting, campaign scheduling, aggregate charts, or a research workspace, evaluate a dedicated survey platform instead.

Explore the customer-pulse recipe, try the reporting demo, or inspect the sandbox before adding a flow to your app.

Ask at a useful moment

Start with a decision, not a questionnaire. After a user completes onboarding, you might ask, “How easy was it to get started?” A rating gives a quick signal; a second text question can ask what made a low score difficult. Keep the prompt close to the relevant task and leave room to dismiss it. A generic site-wide popup is less likely to produce feedback that your team can interpret.

Your application chooses when to open the flow and what context to pass, such as the product surface. BugDrop does not choose a survey audience, send invitations, or schedule a campaign for you. If those controls matter, the host application must implement them or use a survey product built for distribution.

Build a two-question pulse

Use a custom flow with one required rating field and one optional long-text field on a follow-up screen. The customer-pulse recipe demonstrates this released configuration: a 1–10 rating, a conditional follow-up, and an issue title that includes the score. At bugdrop.localhost:3000 in local development, the documentation gallery can launch the actual flow against its local feedback route. The deployed gallery shows the configuration without accepting submissions.

For a first pilot, ask the same two questions for a week on one screen. Choose whether the follow-up appears for every score or only for a low score. Avoid collecting names, account details, or screenshots unless the question requires them. The field guide covers ratings, text, and choice fields; flow design explains screens, branching, and issue output.

Review responses in GitHub

BugDrop writes each submitted response as a separate GitHub Issue. The example formats the rating in the issue title and the score and optional suggestion in the issue body. Add a label or repository triage convention so survey responses do not get confused with defect reports. Read a handful of issues before expanding the prompt: are the answers specific enough to inform a product change, and can the team actually close the loop?

This is individual response intake, not survey analysis. BugDrop does not provide response dashboards, aggregate trends, segmentation, or an exportable survey dataset. GitHub search and labels can organize a modest volume; once the question depends on measuring distributions across many respondents, use a research tool with analysis and targeting.

Decide whether this fit is enough

A short pulse fits when engineers and product owners already work from GitHub Issues and want to connect feedback to follow-up work. It also fits feature ideas and task-specific questions that benefit from the same issue workflow. The default BugDrop feedback widget remains the simpler route for screenshot-backed bug reports; a survey flow needs developer configuration and an explicit launch point.

Register a first custom flow, then use the GitHub Issues feedback guide to plan triage. For broader customer research, compare BugDrop with Usersnap and decide which team will own the response workspace.