BC-0093 · CORE GUIDE
Editorial review 2026-09-26 · Official sources conflict
Prepare a Focused Roblox Build Feedback Session
Prepare private testing as a limited feedback session, and use the sharing flow only when the relevant controls are actually present. Choose the task, intended testers and information to share before sending anything; do not treat private feedback access as a publication or audience-approval shortcut.
Objective
Prepare a focused private feedback session without assuming sharing availability or bypassing account boundaries.
Before you start
- Identify the actual sharing control state.
- Choose a question that benefits from an unfamiliar tester.
- Prepare a limited invitation without private information or exaggerated access claims.
Steps
- Read the current sharing conflict before relying on the workflow.
- Choose the intended testers and a concrete task.
- Use only the sharing controls exposed by the intended account.
- Separate recipient entry errors from observations inside the game.
- Collect unaided behavior first, then clarify the tester's interpretation.
Verification
- The invitation states that the game is unfinished and names the task.
- No credentials or account workarounds are requested.
- The session record distinguishes access, behavior and opinion.
- Private feedback is not represented as public publication or approval.
Limitations
- The procedure does not grant missing sharing controls or recipient eligibility.
- The exact link action belongs to the dedicated Playtest-link guide.
- The invitation is a proposed template, not evidence that a session occurred.
Working notes
Decide why another person is needed. A fresh player can reveal whether the goal is understandable without coaching, while the creator can often inspect a reset defect alone. Write the uncertainty the session should resolve so the invitation asks for useful behavior rather than a vague opinion about the whole game.
Check the sharing state independently from the game's readiness. The current source conflict means an instruction elsewhere does not prove the control exists for the intended account. If it is absent, record that state and stop the sharing procedure. Do not ask a tester for account credentials or attempt to work around an eligibility restriction.
Limit the invitation to the intended people and task. Explain that the game is a work in progress, what action to try and what feedback would help. Avoid putting personal information in the game, invitation or screenshots. A private test should not be advertised as unrestricted public access.
Keep access problems out of the gameplay conclusion. If the tester cannot enter, record the visible error and the attempted route without claiming the game itself failed. When entry works, let the tester attempt the task before explaining its solution, then collect observed behavior and interpretation separately.
Examples
- Invitation draft: 'This is an unfinished delivery prototype. Please try to finish a delivery without my explaining the path, then tell me what showed that you were done. If entry does not work, send the visible error without sharing passwords or private account details.'
- Session preparation: task is finding the depot; expected feedback is an understandable completion message; observation is where the tester first goes and what they think the message means. Do not fill in the observation before the session.
- Access split: an unavailable sharing control belongs in the creator's access record; a recipient's entry error belongs in the invitation record; an unclear goal after entry belongs in the usability record. These should lead to different next actions.