VoteWant provides a feedback board that a product owner can put on a website, app, or game. A VoteWant property has a generated widget snippet. VoteWant presents one board for each product property. VoteWant's product page describes customer feature requests, bug reports, and votes as feedback inputs for an owner's product decisions. The board belongs to the product property named in VoteWant, while the widget supplies the feedback entry point on the product's own interface.
VoteWant renders public board visitors as anonymous until they authenticate, while public request submission and voting require a verified human identity; a verified human can vote once per request.
Separate the ability to read a public board from the ability to create participation evidence. Label each boundary clearly so visitors understand when identity is required.
Define what an anonymous page view means before reporting demand. Keep browsing activity separate from submissions, votes, comments, and owner decisions.
Record the source of each participation event without exposing private account details. Preserve enough provenance to distinguish external customers from internal testing.
Treat a verified account as identity evidence rather than proof that every request represents a customer need. Review the context attached to the request before prioritizing it.
Exclude founder, employee, agent, synthetic, and preview activity from external-demand totals. Keep those events available for testing without allowing them to satisfy adoption goals.
Explain the sign-in boundary at the moment a visitor attempts a protected action. State the action being protected and return the visitor to the same request after authentication.
Count one person's repeated interaction according to the product rule being measured. Avoid presenting refreshes or repeated clicks as independent people.
Review anonymous submissions separately when a product permits them. Apply moderation and rate controls without quietly reclassifying unverified activity as verified demand.
Use votes as participation evidence alongside severity, recurrence, customer fit, and owner judgment. Avoid turning a visible tally into an automatic roadmap commitment.
Document which personas may submit, vote, comment, review, merge, and publish. Test each less-privileged path independently from founder or administrator exceptions.
Preserve the distinction between authentication and authorization. Confirm both who the person is and whether that person may perform the requested action for this property.
Give the visitor a specific recovery path instead of exposing another property's data or accepting an unattributed write.
Measure conversion between board view, attempted participation, completed sign-in, and recorded participation. Use the drop-off to improve clarity without weakening ownership boundaries.
Keep public labels understandable to ordinary visitors. Replace internal verification terminology with concise explanations of what is counted and why sign-in is requested.
Test signed-out, ordinary customer, owner, and founder journeys as separate obligations. Never use privileged-path evidence to discharge a customer-path requirement.
Review identity rules when a new integration, app surface, or game client is added. Confirm that secrets remain server-side and that public clients receive only public data.
VoteWant is positioned as customer request tracking for product owners.
Without a data-target option, the VoteWant feedback button appears immediately after the widget script tag.
The VoteWant feedback button opens a modal that visitors can close with its Close button, the Escape key, or a click outside the modal.
A VoteWant property stays private while its owner prepares it, and its installed feedback button becomes available to visitors after public activation.
A verified VoteWant owner can merge duplicate requests on the same board; the merge records an audit and preserves distinct verified-human vote attribution on the surviving request.
A VoteWant property has a generated widget snippet that is installed immediately before a site's closing body tag.
A developer may choose an existing interface element for the VoteWant launcher with the widget's data-target option.
VoteWant documents data-theme, data-shape, and data-color options for the widget launcher while retaining VoteWant attribution and the standard modal behavior.
When a browser loads the installed VoteWant script, it sends a minimal installation observation to VoteWant; the setup evidence check reads that server record and does not mark installation complete merely because a button was clicked.